Debugging with AI

An error message is a communication from the program to you. Most of the time it contains everything you need to diagnose the problem — but reading it fluently takes practice. AI can accelerate that process significantly, but only if you give it the same information you'd give a knowledgeable colleague who can't see your screen.

"Why doesn't my code work?" is not a debugging request. It's a signal that you haven't yet read what the program is telling you.

What to include in a debugging request

A good debugging prompt contains four things:

1. The full error message and stack trace. Not a summary. Not "it says something about a TypeError." The complete text, copied verbatim. The stack trace tells the model where in the execution path the failure occurred — information that "I got a TypeError" does not.

2. The code that's failing. The relevant function or snippet, not a description of what it does. The model can't read code it hasn't seen. When you describe code in words, you introduce your own interpretation of it — which may omit exactly the bug you haven't found yet.

3. What you expected vs. what actually happened. "I expected the function to return a sorted list; it returns an empty list instead." This tells the model what the contract violation is. Without it, the model is looking for any plausible bug rather than the one that explains your specific symptom.

4. What you've already tried. This prevents the model from suggesting approaches you've already ruled out, and it provides useful diagnostic information. If you've confirmed the input data is correct and the error still occurs, the model can skip the "check your input" hypotheses.

A debugging prompt with all four components looks like this:

"I'm getting a KeyError in the function below. The full traceback is: [paste]. The code is: [paste]. I expected it to look up the user's score and return it; instead it raises a KeyError on the line marked. I've already confirmed the dictionary is not empty before the call."

That prompt has a single reasonable interpretation. The model can engage with it as a diagnostic partner.

The diagnostic conversation

Debugging with AI works best as a conversation, not a single request. A useful pattern:

Start with the symptoms. Give the model the error, the code, and the expected vs. actual behaviour. Ask: "What could cause this?" not "Fix this."

Evaluate the hypotheses. The model will typically generate several plausible causes. Work through them. Which ones could you rule out based on what you already know? Which ones deserve investigation?

Investigate, then report back. Check one hypothesis, report what you found, and ask for the next step. This keeps the diagnostic reasoning visible and keeps you in the loop rather than outsourcing thinking entirely.

Ask for an explanation before accepting a fix. When the model suggests a fix, ask it to explain why the fix works — what specifically was wrong with the original code. A fix you don't understand is a liability: you can't verify it's correct, and you can't apply the same insight next time.

The symptom vs. root cause trap

The most common failure mode when debugging with AI is accepting a fix that makes the error go away without understanding why it happened. These fixes often:

• Add a conditional that catches the error case without fixing the underlying logic
• Change the input so the error path is never hit
• Catch an exception broadly and return a default value

These are sometimes the right answer. But they're also the first thing a model reaches for when asked to "make the error stop" — because they reliably stop the error regardless of what actually caused it.

The distinction matters in practice:

Symptom fix: if key in dictionary: return dictionary[key] — the error disappears, but the calling code might silently get wrong results now.

Root cause fix: "The key is missing because the dictionary is built from an API response that sometimes omits the field. Add a fallback default when the API response doesn't include it, and add a log line so we know when it happens."

Ask the model: "Is this a root cause fix or a workaround?" It will usually tell you honestly. If it's a workaround, ask what the actual cause is.

Bringing context without noise

The inverse problem also exists: giving the model too much context. Pasting 500 lines of code when the error occurs on line 12 of a 20-line function buries the relevant signal. The model has to infer what matters rather than being able to focus on it directly.

The relevant context for most bugs is:

• The function where the error occurs
• The function(s) that call it (for input shape context)
• The data structure definitions (type definitions, schema, data class) that the function operates on

Everything else is usually noise.

Where to go next

Debugging skills tell you how to diagnose what AI produces. The next lesson steps back further: validating AI solutions — the systematic approach to confirming that working code is actually correct, not just that it runs without errors.