Debugging with AI: understand before you fix

Use AI to break down an error message and build a diagnostic method, instead of begging for a fix you won't understand.

8 min · 3 questions

When you hit a bug, the dominant reflex is to paste the stack trace into a chat with "fix this." It often works - and that's exactly the problem. You walk away with a fix you never understood, and the class of bug it belongs to will come back in another form next month. A bug is a rare learning opportunity: it reveals a gap between your mental model and how the system actually behaves. Asking for the fix throws that information away. The right approach: ask the AI to explain the error message and lay out a diagnostic method - then run the investigation yourself.

You're a senior developer helping me get better at debugging. Your job is to explain, not to fix things for me.

Context: [language + version, framework, what the code is supposed to do].
Full error message, including the call stack:
[paste the error message]
Relevant code snippet (10 to 30 lines):
[paste the code]

Your task:
1. Explain the error message part by part: what exactly is it saying, and what is it NOT saying?
2. List the 2 or 3 most likely causes in MY context, from most likely to least likely.
3. For each cause, suggest a concrete check I can run myself (targeted log, breakpoint, isolated test).

Hard constraint: do NOT give me the fix. If you identify the cause with certainty, just tell me where to look.

This prompt has three properties that make all the difference. First, minimal but complete context: versions, the code's intent, the full error message - an AI that guesses your context hallucinates causes. Second, the request for causes ranked by likelihood: you learn to reason in hypotheses, not certainties. Third, the explicit ban on the fix: without it, the model almost always slides toward the solution, because it was trained to be helpful. It's up to you to lock the frame.

You're my debugging coach. Strict Socratic method: you never provide the answer, you ask questions.

My bug: [observed symptom] when I expect [expected behavior].
What I've already checked: [list].

How it works:
- Ask me ONE question at a time to help me isolate the cause.
- Each question must either rule out a hypothesis or strengthen one.
- When I answer, explain which lead my answer eliminates before asking the next question.
- If I state a hypothesis, help me design the fastest test to confirm or refute it.

Prohibition: never name the cause directly, even if it seems obvious to you.

This second prompt covers the hardest case: the silent bug, no exception, where the program simply does something other than expected. The method the AI should have you practice is the one every experienced debugger uses: reproduce it reliably, isolate it by shrinking the scope (bisecting the code or the data), form a falsifiable hypothesis, test that hypothesis with the cheapest possible check. Here the AI plays the role of a rubber duck that talks back - one that stops you from skipping steps.

Knowledge check

Make sure you remember the key points of this lesson.

1. Faced with an error message, which request maximizes your learning?
   • "Fix this bug and send me back the full code"
   • "Explain this message, rank the likely causes and suggest checks - no fix"
   • "Rewrite this module so it's more robust"
2. Why must you EXPLICITLY ban the fix in the prompt?
   • Because the AI charges more for fixes
   • Because the model, trained to be helpful, spontaneously slides toward the solution
   • Because the AI is incapable of writing a valid fix
   • Because generated fixes are always wrong
3. The AI suggests a likely cause for your bug. What do you do?
   • You apply the suggested change directly
   • You ask for a second cause to compare
   • You verify the hypothesis yourself with a log, a breakpoint, or an isolated test