Debug with the AI, not by guessing: a hypothesis-first loop

Pasting a bug and asking 'why is this broken' invites a fluent, confident guess. Flip it: state a few hypotheses, instrument the code to tell them apart, and let the runtime decide.

The fastest way to get a confident wrong answer out of an AI is to paste a bug and ask why it is broken. It reads the code and guesses, fluently. But runtime bugs do not live in the code you can read, they live in what the values actually are while the thing runs, so a better loop starts from evidence instead of from staring.

Start with hypotheses, not fixes

Before touching anything, pin down the symptom: the exact error or wrong output, where it happens, and how to reproduce it. Then write two to four specific hypotheses. Each one names the file and function you suspect, what you think is wrong (a stale value, a missing await, an off-by-one, a race), and what evidence would prove or kill it. If you cannot name two concrete hypotheses, you do not understand the bug well enough yet.

Instrument to tell them apart

Now add logging, but with a purpose. Pick a short tag for the session, something like [DBG-AUTH], and start every log line with it so the whole run is one grep away. Place logs only at the points that would separate one hypothesis from another. Run it once, capture the output, and read what the program is actually doing instead of what you assumed it did.

• One tag per session, on every injected line, so cleanup is a single find-and-delete.
• Log the values that distinguish your hypotheses, not everything in sight.
• Run, read the real output, then narrow to the surviving hypothesis and go deeper.

Then clean up, every time

The step people skip is removing the instrumentation once the bug is caught. Tagged logs make that trivial, which is the other reason to tag them. Debug prints left behind are how a codebase slowly fills with noise nobody trusts.

Reading code to find a runtime bug is guessing with extra steps. State what you think is wrong, make the program tell you, then delete the scaffolding.

An AI is genuinely good inside this loop, because placing a dozen tagged logs and reading the output back is fast and a little boring, exactly the kind of work worth handing off. The hypotheses are what keep it from wandering off into plausible nonsense.