Debugging With AI: What Works and What Wastes an Hour

Excellent at decoding errors

Stack traces, cryptic compiler messages, obscure runtime errors from unfamiliar libraries — this is the strongest use case available, and it routinely saves twenty minutes of searching.

Paste the full trace rather than the last line. The frames below the top are where the useful information usually is.

Ask what conditions produce this error, not what fixes it. The list of conditions is checkable; the suggested fix is a guess about which condition applies.

Good at generating hypotheses

Given a clear symptom description, it will produce a list of plausible causes, including ones you would not have thought of. That list is genuinely valuable.

Treat it as a checklist to eliminate, in order of how cheap each is to test. Do not treat the first item as the answer.

The value drops sharply if your symptom description is vague, because then the hypotheses are about a different bug.

Poor at narrowing

Narrowing requires observing your actual system. The model cannot run your code, see your data, or check your configuration, so it substitutes plausibility for evidence.

This is where hours disappear: accepting a confident diagnosis and modifying code based on it without first confirming the diagnosis with an observation.

The discipline is simple. Before changing anything, make one observation that would distinguish the proposed cause from the alternatives.

Dangerous at suggesting fixes for unconfirmed causes

A suggested fix for the wrong cause frequently makes the symptom disappear without fixing anything — adding a retry, widening a timeout, catching an exception.

These changes are worse than no change, because the underlying fault remains and the signal is gone.

Any fix that suppresses a symptom rather than explaining it should be rejected until the mechanism is understood.

The description that gets good answers

What you expected, what happened, what you have already ruled out, and the smallest reproduction you have. The third element is the one people omit and the one that most improves the response.

Include versions and environment. A large share of confusing behaviour is version-specific and the model cannot know your versions.

State what changed recently. Most bugs are recent-change bugs, and this single line often produces the answer immediately.

Rubber-ducking, which is underrated

Writing the description well is itself frequently the fix. The discipline of stating expected versus actual precisely resolves a meaningful fraction of bugs before the message is sent.

This is not a joke about the tool being unnecessary; it is a reason to write the description even when you intend to debug alone.

Where it does not resolve the bug, you now have a description good enough to get a useful answer.

Worked example: a slow endpoint

Symptom: one endpoint intermittently taking eight seconds, usually 80ms. No pattern visible in the logs.

Hypothesis list from a good description: connection pool exhaustion, an N+1 query on a rarely-populated relation, a lock contention on a shared row, cold cache, and a slow downstream call without a timeout.

Narrowing was done with observation, not suggestion: query logging showed a consistent 60ms, ruling out two hypotheses immediately. Pool metrics showed saturation coinciding exactly with the slow requests.

The actual cause was a background job holding connections during a retry loop. The assistant's first suggested fix had been to add an index, which would have been harmless, useless, and would have consumed an afternoon.

Give it the evidence, not the conclusion

The common failure is pasting a stack trace and asking what is wrong. Better input is the trace, the relevant function, what you expected, what happened, what changed most recently, and what you have already ruled out.

That last item matters more than it sounds. Without it the model happily suggests the three things you tried an hour ago, and the session becomes a loop.

Ask for a ranked list of hypotheses with a cheap test for each, rather than a fix. You want the diagnostic step you can run in thirty seconds, not confident code for a cause nobody has confirmed.

Know when to stop asking

Three unsuccessful rounds is a signal that the model lacks context you have not supplied — an unusual runtime, a local configuration, or a dependency version that changes the behaviour. Add the missing context or switch to bisecting the change history.

Reach for deterministic tools when the model stalls: git bisect, a minimal reproduction, or logging around the boundary. These answer questions that no amount of rephrasing will.

Write the root cause down when you find it, in one sentence with the fix. Both the model and the next engineer benefit, and the note is what stops the same bug consuming another afternoon in six months.

Frequently asked questions

Tools mentioned in this article

More in Developer & Tech