Debug a Real Bug With AI
Practise the debugging loop that works — evidence first, hypothesis second, fix last — on a bug you actually have. The habit this builds is refusing to accept a fix you cannot explain.
Why this one
The common failure is pasting an error and applying whatever comes back. Sometimes it works, and you have learned nothing and possibly hidden the real bug. This project enforces a loop where you understand the cause before touching the code.
Steps
Write the reproduction before you ask anything
State in writing: what you expected, what happened, the exact error, and the smallest sequence that triggers it. Doing this by hand solves a surprising share of bugs outright, and when it does not, it is the input the model needs anyway.
Ask for hypotheses, not a fix
Requesting causes ranked by likelihood, with a way to test each, keeps you in control of the diagnosis. A fix offered before diagnosis is a guess with syntax highlighting.
PromptHere is a bug. Do NOT give me a fix yet. List the 3-5 most likely causes, ranked, and for each: why it would produce exactly this symptom, and the single cheapest check that would confirm or eliminate it. EXPECTED: [what should happen] ACTUAL: [what happens] ERROR: [exact text] REPRODUCTION: [steps] RELEVANT CODE: [paste]
Run the cheapest check first
Work down the list. Each check should eliminate a hypothesis or confirm one. Resist skipping to the interesting theory — the cheap checks are cheap precisely because they rule out the boring causes that turn out to be right most of the time.
Ask for the fix, then interrogate it
Once you know the cause, ask for a fix — and then ask what it would break. The question "what else calls this, and what assumption does my change violate?" catches the fixes that trade one bug for two.
Write the one-line explanation
In your own words, in one sentence: what was wrong and why the fix works. If you cannot write that sentence, you have not fixed the bug, you have moved it. This is the whole point of the project.
You should end up with
A fixed bug and a one-sentence explanation of the root cause.
Done when
- You eliminated at least two hypotheses with evidence before fixing anything
- You can explain the root cause without referring back to the conversation
- You checked what else the fix might affect
If you want to go further
- Add a regression test that fails before your fix and passes after
- Do the same exercise on a bug in an unfamiliar codebase
Try next
Topics
Related across the site
Chunking: Why Split Size Matters
Documents are split into chunks before embedding.
Code Review Pass
Pre-review pass before submitting a pull request
Custom GPTs & Claude Projects
Both ChatGPT (Custom GPTs) and Claude (Projects) let you upload documents and set standing instructions — a no-code RAG setup.
Function calling
Function calling lets a model request that your code run a specific function with specific arguments. You expose tool definitions; the model returns a structured call, your code executes it, and the result goes back into the conversation.
GPT vs Claude vs Gemini: An Honest Comparison
A practical comparison of the three leading AI models across writing, coding, reasoning, long documents and cost — including which one to reach for on which task, and where each genuinely falls short.
Model drift
Model drift is when a hosted model's behaviour changes over time as the provider updates it, causing prompts that worked reliably to degrade without any change on your side.