Cursor and Microsoft Research Test Whether AI Agents Need Full Debugger Access

For an AI agent to fix bugs, simply reading code and collecting logs is no longer enough: when it gains access to a real debugger, it begins to act more like a human developer and understand much better where exactly the program breaks. At the end of 2025, Cursor released Debug Mode — a mode in which an agent can gather logs directly 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 during execution, which values pass through functions, and at what point the system behaves unexpectedly.

This approach proved intuitively understandable to developers as well: from the community's reaction, it became clear that the idea is perceived not as 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 sounds even more direct: if the agent already lives next to the IDE, why not give it the same tools that humans use?

We're talking about breakpoints, step-by-step execution, viewing program state, and evaluate expression at the right line. This is exactly what researchers at Microsoft Research tested in the experimental Debug2Fix framework. In their setup, a separate subagent was given tools to interact with the debugger and on tasks from GitBug-Java and SWE-Bench-Live dealt with bugs roughly 20% better than a regular agent without such access.

This is not a cosmetic improvement: for automatic code fixing tasks, this difference already changes the practical value of the tool. The idea is clear. Logs almost always help reveal symptoms, but a debugger allows you to get to the mechanics of the failure.

An agent can do more than simply read that a value turned out to be incorrect; it can trace the moment it became incorrect, which branch of the condition was triggered, what lies in the objects right now, and how the expression will behave when testing a hypothesis on the spot. In essence, the model receives not only observation but also a controlled experiment. For debugging complex states, race conditions, unexpected null values, or business logic errors, this can be critical, because here static analysis and even detailed logs are often insufficient.

Against this backdrop, it makes sense that full-fledged IDE assistants are beginning to go beyond simple file reading. If the agent is already embedded in the development environment, access to the debugger looks not exotic but a natural expansion of capabilities. That's why the fresh release of the assistant for IntelliJ includes a Debug Agent that can interact with the debugger directly in the IDE.

The scenario becomes almost human: the agent runs the program, stops at the right point, looks at the state, tests the hypothesis, and only then suggests a fix. This is an important difference from the approach where the model primarily relies on logging and indirect signs of a problem. What's most interesting about this story is not only the quality improvement on benchmarks, 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?

There is no complete answer in a single experiment yet, but it's already clear that the market is moving in two directions at once. One path bets on 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-world cases, AI coding assistants will quickly stop being just smart autocomplete and become full-fledged partners who know not only how to write code, but also how to methodically get to the root of a bug.