Debugging With AI

There is a specific way this goes wrong. You paste an error, the AI hands back a fix that sounds right, you apply it, and a different error appears one line downstream. You paste that one too. Three exchanges later you are patching symptoms in a file the original bug never touched, and nobody — you or the model — remembers what the actual problem was.

It happens because each new error looks, to the model, like a fresh and separate puzzle. It reasons about what is in front of it, which is often locally correct and globally wrong: the fix removes the crash without touching the reason the value was wrong in the first place. The cause does not get fixed. It moves.

After two fixes in a row miss, switch modes. Feeding the model another error keeps you moving forward through symptoms; narrowing works backward toward the cause.

1. 1

   Shrink it to the smallest failing case

   Strip the app down to the least code that still reproduces the bug. Understanding every line you keep is usually enough on its own to find it.

2. 2

   Separate what you know from what you were told

   “Cannot read properties of undefined” is a fact. “It's probably the state initialisation” was a guess two fixes ago that turned out to be wrong.

3. 3

   Check the value directly

   A log statement or a debugger breakpoint at the point of failure answers the question instead of theorising about it again.

   One printed value ends more of these loops than another prompt does.

4. 4

   Start a fresh conversation with what you found

   Paste the minimal repro and the logged value, not the accumulated thread. A clean context reasons about the real cause instead of defending its last three guesses.