How to debug with AI coding agents without guessing

You paste the stack trace. Ninety seconds later the agent hands you a fix: a null check, wrapped in a try/catch, with a comment explaining that the value can sometimes be missing.

The error goes away. Nobody ever asks why the value was missing.

That's the shape of most AI-assisted debugging, and it's why bugs keep coming back wearing different clothes. Coding agents are extraordinary at making a symptom disappear and merely average at finding out what caused it, unless you run the session in a way that makes guessing harder than investigating.

Why agents default to patching

An agent optimises for the goal you gave it. "Fix this error" is a goal that a null check satisfies completely.

It also works under a real handicap: it can read your code, but it can't see your running system. No live values, no request that actually failed. Faced with a question it can't observe its way out of, a language model does the thing language models do: it produces the most plausible answer. Plausible isn't true, and a plausible fix is worse than none, because it looks finished.

So the whole job is converting the bug from something to be reasoned about into something that can be observed.

Step 1: make it reproduce before it edits

The single highest-leverage instruction in agent debugging is: don't fix anything yet: give me a command that fails.

A failing test, a script, a curl that returns the wrong body: anything repeatable and quick. It proves the agent understands the bug rather than the error text, gives you a definition of done that isn't the agent's opinion, and ends the edit-and-hope loop where each "fix" is validated by vibes.

If your agent can't produce a reproduction, you don't have a debugging task yet. You have a research task, and it should be scoped as one. This is the same instinct behind writing the test first: the artefact that proves the work is created before the work.

Step 2: give it evidence, not adjectives

"The checkout is broken sometimes" is a prompt that guarantees a guess.

Agents debug about as well as the evidence you hand them allows, so hand them a lot: the full stack trace rather than the last line, the failing input, the timestamp, what changed recently, and, critically, what you already ruled out. That last one saves entire rounds. Nothing burns a session faster than an agent carefully re-investigating the theory you disproved an hour ago.

Better still, let it gather evidence itself. Connect a read-only database, a browser it can load the page in, your logs: that's what MCP servers are for, and the agent stops asking you what the data looks like and goes and looks.

Step 3: demand a cause, not a diff

Before any edit, ask for the mechanism in two sentences: what value is wrong, where does it become wrong, and why does that path run?

If the explanation is vague ("there may be a race condition"), you've caught the guess before it became a commit. Send it back for evidence: a log line, a test that isolates it, a printed value. Real causes are specific and boring. Fabricated ones are hedged.

Watch for the tells that an agent has stopped debugging and started appeasing: adding a retry, widening a catch block, tweaking a timeout, or "defensively" checking for a state that should be impossible. Each of these hides a bug rather than removing it.

Step 4: run hypotheses in parallel

Hard bugs come with three or four plausible stories, and testing them one at a time is what makes debugging feel like a day disappearing.

You don't have to. Give each theory to its own agent, in its own checkout, with a narrow brief: test this hypothesis and report back with evidence: do not fix anything. Three come back with "ruled out, here's why." One comes back with the reproduction. Elimination parallelises even when the fix doesn't.

Step 5: check the blast radius

A confirmed cause and a passing test still isn't the end. Ask the closing question: where else does this pattern appear? Bugs travel in packs: the same unchecked assumption is usually sitting in four other call sites.

Then review the fix like any other agent output. A small, targeted diff with a test attached is easy to check; a sprawling one that "also cleaned up a few things" is where review discipline pays for itself.

Where the workflow gets easier

Steps 4 and 5 are the ones that quietly fall apart in a single terminal window. Parallel investigation means several sessions running at once, each needing its own context, and a way to keep track of which theory belonged to which tab.

That's the problem SanuDesk was built around. It's a desktop app that tiles your Claude Code, Codex and Gemini sessions into one grid, each workspace pointed at a project folder, with a Kanban board the agents pull work from. A bug becomes a card with its reproduction in the description; each hypothesis becomes its own deployed card in its own session; findings come back to the board instead of scrolling out of a terminal you closed. Loops handle the recurring end of it: a nightly pass over the flaky test list, say. It drives the agent subscriptions you already pay for, so nothing here is metered by us, and the free tier is a real one.

The habit worth keeping

Reproduce, then explain, then fix, then check the neighbours. It reads like ordinary debugging discipline because it is: the only change is that an agent does the legwork while you hold the standard.

Download SanuDesk free and point a workspace at the repo with the bug you've been avoiding, or see how the grid, the board and Loops fit together on the features page.