Why AI Agents Skip the Debugger – and How a Harness Can Beat a Stronger Model

Noticed

I recently noticed that my agents almost never use a debugger. Most of the time, the pattern looks like this: read the error → form a hypothesis → rewrite a chunk of code → rerun the test. Repeat until it’s fixed.

Where’s the debugger?

Checked

I spot-checked some of my Claude and Codex sessions involving Python and JavaScript. Sure enough, the debugger never appeared in the episodes I reviewed.

The agents did read source code, write diagnostic scripts, inspect processes, and run experiments to find the bugs. They just did it without a debugger.

But why?

A debugger is a basic programming tool. Why do agents use it so rarely? Or is this something specific to my tasks?

Looked into it

debug-gym and other papers offered some explanations:

The interface is designed for humans. A debugger needs step-by-step control, and its responses can be verbose. The agent has to call the model much more often, while commands and debugger output fill up its context.
Agents are reluctant to use the tool. The debug-gym authors suggest that the training data may be the reason: plenty of completed code fixes, but few records of debugger sessions. Perhaps that makes models more inclined to rewrite code than to investigate its execution.
Direct access doesn’t always help. In Microsoft’s Debug2Fix experiment, Sonnet had direct access to a debugger but invoked it on just 9% of tasks. Its overall score was worse than without the debugger. The agent has to control the debugger and find the bug at the same time. Presumably, the weaker the model, the harder it is to juggle those responsibilities.

Researchers are trying three different answers to this problem.

Can’t? Teach it

In SWE-PDB, the model was first shown examples of finding bugs with a debugger, then given practice with rewards for successful fixes. After training, Qwen3-14B solved 38% of tasks, up from about 10%. Admittedly, that reinforcement-learning process also made it better at fixing code without a debugger: it scored 33.4% with the tool switched off. So training improved the model itself, and using the debugger added a further boost.

Awkward? Redesign it

A conventional debugger requires lots of small actions: execute the next line, show a variable, step into a function. In FramePilot, the agent can request the full execution history of a particular function call: the inputs it received, how its variables changed, and what it returned. If another function looks suspicious, the agent can move to the history of that call. Less fiddling with debugger controls, more attention to the bug itself.

Won’t? Make it

The Debug2Fix researchers made two changes:

Put the debugger behind a subagent. Instead of pdb or jdb commands, the main agent gets a single tool: “ask the debugging subagent.” It asks a natural-language question, such as “What value does method X return in this test?” The subagent controls the debugger in its own isolated context, finds the answer, and returns the facts: variables, stack frames, and observations. This keeps the main model’s context clean.
Tied its hands (tool-limit). To stop the model from “being lazy,” the harness blocks file edits until it has consulted the debugging subagent at least once. Want to fix the code? First find out what’s actually broken at runtime, then touch the files.

On the GitBug-Java benchmark, this made a substantial difference:

The baseline Claude Sonnet 4.5, without the special harness, solved 75.7% of tasks.
The smaller Claude Haiku 4.5, with the debugging subagent and a mandatory consultation, solved 82.3%.

The smaller model beat the stronger model from the same generation because of how the work was organized. Incidentally, giving Sonnet the same harness raised its score to 85.5%.

Takeaway

Another reminder that results depend on more than the model alone: they depend on the combination of the model and its environment.