Cursor and Microsoft Research test whether an AI agent needs full debugger access

For an AI agent that fixes bugs, reading code and collecting logs is no longer enough: once it gets access to a real debugger, it behaves more like a human developer and understands much better where exactly a program breaks.

In late 2025, Cursor released Debug Mode, in which the agent can collect logs straight from the runtime and use them as an additional source of context. For practical debugging this is an important step: instead of guessing from stack traces, the model sees what happens at execution time, which values pass through functions and at which point the system deviates from what was expected.

Developers also found the approach intuitive: the community's reaction suggests the idea is seen not as yet another marketing mode but as a genuinely useful tool for everyday bug work.

But logging is not the only way to bring AI closer to normal engineering practice. The next question is even more direct: if the agent already lives next to the IDE, why not give it the same tools a human uses? That means breakpoints, step-through execution, inspecting program state and evaluate expression on a given line.

Microsoft Research tested exactly this in the experimental Debug2Fix framework. In their setup, a separate subagent received tools for interacting with the debugger, and on tasks from GitBug-Java and SWE-Bench-Live it handled bugs roughly 20% better than a regular agent without such access. This is not a cosmetic improvement: for automatic code repair, a difference like this changes the tool's practical value.

The idea is simple. Logs almost always help you see symptoms, but a debugger lets you get to the mechanics of the failure. The agent can do more than read that a value turned out wrong: it can trace the moment it became wrong, which branch of a condition fired, what the objects contain right now, and how an expression behaves when a hypothesis is tested on the spot. In effect, the model gets not only observation but a controlled experiment. For debugging complex state, race conditions, unexpected null values or business-logic errors, this can be critical, because this is where static analysis and even detailed logs often fall short.

Against this backdrop, it makes sense that full IDE assistants are starting to go beyond simply reading files. If the agent is already built into the development environment, debugger access looks less like an exotic feature and more like a natural extension of its capabilities. That is why the latest release of the IntelliJ assistant includes a Debug Agent that can interact with the debugger directly in the IDE. The workflow is almost human: the agent runs the program, stops at the right point, inspects the state, tests a hypothesis and only then proposes a fix. This is an important difference from an approach where the model mostly relies on logging and indirect signs of the problem.

The most interesting part of this story is not only the benchmark gain but the question itself: what is more useful for the AI developer of the future, good access to runtime logs or real "hands" inside the debugger? One experiment does not give a full answer yet, but it is already clear that the market is moving in two directions at once. One path bets on high-quality observation of program execution, the other on active intervention in the debugging process.

If the second approach confirms its advantage on a larger number of real cases, AI coding assistants will quickly stop being merely smart autocompleters and become full partners that can not only write code but also methodically dig down to the root of a bug.