Most “AI, debug this for me” sessions fail the same way: you paste an error, the model guesses a cause, writes a fix, you run it, it breaks differently, and 40 minutes later you have three new bugs and no idea which change did what. The model never had enough information to reason, so it pattern-matched. The workflow below fixes that by forcing diagnosis before repair.
TL;DR
- Reproduce first. AI cannot debug what you cannot trigger on demand.
- Capture three things: the exact stack trace, the input that triggers it, expected vs actual output.
- Ask for ranked hypotheses, not fixes. “List the 3 most likely causes with one diagnostic check each.”
- Run the checks, report results. This step catches the model’s wrong guesses before they cost you anything.
- Only then request the minimal fix for the confirmed cause, apply it, and re-run your reproduction.
- Write a regression test so the same bug can’t return silently.
The whole point is to spend the model’s reasoning on evidence you supply, not on guessing at hidden context.
Who this is for
Developers who reach for ChatGPT, Claude Code, or Cursor when a bug has them stuck, and who keep getting plausible-sounding fixes that don’t hold. If you have ever applied an AI fix that “looked right” and broke something else, this is for you.
When to use it
You have a specific, reproducible failure: a stack trace, a wrong return value, an HTTP 500, an intermittent crash you can trigger more than once. The more deterministic the repro, the faster this converges.
When this is NOT the right tool
- Performance regressions that need a profiler or flame graph, not a stack trace.
- Flaky tests caused by environment, ordering, or shared state rather than a single logic bug.
- Design problems disguised as bugs where the “fix” is really a refactor decision.
For platform-wide hunts (re-renders, navigation loops, native module crashes), use auditing a React Native project with AI instead, which is a survey workflow rather than a single-bug one.
The 7-step workflow
- Reproduce the bug deterministically. Find the exact input or sequence of steps that triggers it every time. If it only fails 1 in 10 runs, note that explicitly in step 3.
- Capture the evidence. The full stack trace (not just the last line), the triggering input, and a clear “expected X, got Y.”
- Put all three in one message. One message with complete context beats five messages of dribbled-out detail. Include the function around the error plus any data the bug depends on.
- Ask for ranked hypotheses with checks, not a fix. Use the prompt below. Forcing the model to propose diagnostic checks surfaces its reasoning so you can test it.
- Run the suggested checks and report back. “Check 1 passes. Check 2 reveals the env var is undefined in the test runner.” This is the single most valuable step: it catches hallucinated causes before they waste your time. Surveys in 2026 found only about 27% of users consistently verify AI output (All About AI) — the check step makes verification the default.
- Request the minimal fix for the confirmed cause. Apply it, re-run your reproduction from step 1, and confirm the failure is gone and nothing else broke.
- Write a regression test. Ask the model to write a test that fails on the old code and passes on the fixed code, targeting this exact bug.
Worked example: an HTTP 500 that only fails in CI
A handler returns 500 in CI but works locally. You capture the trace, the request body, and “expected 200, got 500,” then ask for three ranked causes. The model proposes: (1) a missing environment variable in the CI runner, (2) a different Node version, (3) a database migration not applied in CI. You run the checks: the env var read returns undefined only in CI. That confirms hypothesis 1. The minimal fix is adding the variable to the CI secrets, plus a startup assertion so a missing var fails loud instead of returning 500. You add a test asserting the handler throws a clear config error when the var is absent. Total time: about 15 minutes, versus an hour of swapping fixes at random.
When a bug only appears in production on Firebase Hosting, pair this with the AI Firebase deploy checks workflow — most “works locally, breaks deployed” cases trace back to firebase.json rewrites or a Cloud Function region mismatch.
Which AI tool for which debugging job (June 2026)
Different tools fit different stages. The biggest practical split: a chat model debugs from what you paste, while an agentic tool can read your repo, run commands, and add its own logging.
| Tool | Best for | Notes (as of June 2026) |
|---|---|---|
| ChatGPT (GPT-5.5) | Pasting a trace + code for ranked hypotheses | Free tier has tight limits; Plus is $20/mo. Strong agentic reasoning; topped Terminal-Bench 2.0 at 82.7%. |
| Claude Code (Opus 4.7 / Sonnet 4.6) | Multi-file bugs where it reads imports and runs commands itself | Bundled with Claude Pro ($20/mo). Opus 4.7 leads SWE-bench Verified at 87.6%. Runs Anthropic models only. |
| Cursor (Sonnet 4.6, Opus 4.7, GPT-5.5) | In-editor debugging with the bug right next to your code | Hobby free; Pro $20/mo. Background agents can fan out parallel diagnostic runs. |
For agentic debugging, the effective loop is different: ask the tool to add detailed logging around the suspect path, run the repro, and feed the output back. It narrows in on the core issue by accumulating evidence, which Anthropic documents in its Claude Code best practices. The hypothesis-ranking prompt below still applies; you are just letting the agent run the checks for you.
Common mistakes
- Pasting only the error message. Without the trigger and the expected behavior, the model has nothing to reason from and guesses wildly.
- Letting AI write a fix before the cause is confirmed. The most dangerous AI output is the plausible-but-wrong one; a confident fix for the wrong cause often introduces a second bug.
- Trying five fixes in a row when none work. Stop. Re-read the full trace from the top. The actual fault is usually a frame or two above where you’ve been looking.
- Skipping the regression test. An untested fix means the same bug returns silently on the next refactor.
- Truncating the stack trace. The last line is the symptom; the cause is often higher up. Paste the whole thing.
Advanced tips
- Intermittent bugs: ask “What ordering or timing assumption could make this fail only sometimes?” Race conditions and shared mutable state hide here.
- “Works on my machine”: state the environment delta explicitly — Node/Python version, OS, and the specific env vars that differ between machines.
- When the model keeps proposing wrong causes: feed it negative evidence. “It is NOT a network issue and NOT a permissions issue; check 2 confirmed the DB connection is healthy.” This prunes the search space fast.
- Long or multi-file traces: paste the trace plus the relevant function bodies it references, not your whole repo. Targeted context beats a dump.
Copy-ready diagnostic prompt
Error / trace (full, top to bottom):
[paste exact trace]
Trigger: [the input or steps that reproduce it]
Expected: [what should happen]
Actual: [what happens]
Reproducibility: [every time / 1 in N runs]
List the 3 most likely root causes, ranked by likelihood.
For each, give ONE specific diagnostic check I can run.
Do not write a fix yet — I will report the check results first.FAQ
Should I include code, or just the error? Include the function around the error plus any data the bug depends on. The model cannot guess the body of a function it has never seen, and most “wrong cause” answers come from missing context.
What if the AI hallucinates a cause? It will, sometimes. The diagnostic-check step is your safeguard: never accept a cause until a check confirms it. Treat every ranked hypothesis as unverified until you’ve run its check.
Which model is best for debugging in June 2026? For pasting traces and getting ranked hypotheses, GPT-5.5 and Claude Opus 4.7 are both strong. For multi-file bugs where the tool should read your repo and run commands, Claude Code (Opus 4.7, 87.6% on SWE-bench Verified) or Cursor’s agent are the better fit. Pick based on whether you want chat-only reasoning or an agent that can act.
How is this different from just asking “fix my bug”? “Fix my bug” jumps straight to a patch with no evidence. This workflow forces a diagnosis step so the fix targets a confirmed cause, which is what stops the guess-and-break spiral.
Do I really need a regression test every time? For any bug that reached a branch others share, yes. The test costs a minute and is the only thing that prevents the same bug returning silently on the next change.
Related
Tags: #AI coding #Tutorial #Workflow