Debugging Rust in 2026: From println! to AI Agents
More than half of Rust developers do not use a debugger at all. The Rust debugging survey 2026 found that 53.2 percent of Rust users debug without one, and 81.3 percent say that print statements are simply easier and faster. When debuggers are used, stepping features break most of the time around async code and macros, which trip up 28.1 percent and 23.0 percent of users respectively. Debugging Rust remains the language's weakest tooling story, and the survey puts numbers on it.
Those numbers come from the fourth year of JetBrains' survey, and they carry a paradox worth unpacking. Rust is famous for its tooling. It is also, by its own community's measurement, the language where the debugger is least used. A new walkthrough by Orhun Parmaksiz on the JetBrains Rust blog, titled Debugging Rust in 2026, works through the entire toolkit on one real bug: from println! and dbg! through rust-lldb in the terminal, into RustRover's graphical debugger, and finally to an AI agent driving the debugger through the Model Context Protocol.
The result is the clearest map yet of debugging Rust in 2026, and the conclusion is not that one tool wins. It is that each technique has a distinct trade-off, and most developers are stuck in the lowest one. This article walks the same ladder, adds the context the survey data begs for, and looks at what debugging Rust could look like once agents are in the loop.
The scenario: a convex hull bug worth chasing
The walkthrough uses the Graham scan algorithm, which computes the convex hull of a set of points: the smallest convex shape enclosing every point, or as the author describes it, stretching a rubber band around a collection of nails.
The example ships with a failing unit test and a terminal UI built with Ratatui that visualises the algorithm live. The bug is visible in the visualisation: the computed hull, drawn in red, fails to enclose a point called P2, while the expected hull in green encloses everything. The source is public on GitHub.
That setup matters, because it makes the walkthrough comparable. Debugging Rust in 2026 can now be shown rather than described, and the same bug is chased four ways with each method's speed, friction and cost on display.
Method one: println!, dbg! and tracing
The first approach is the one most Rust developers already use. A failing test becomes the debugging loop: add println! or dbg! statements, rerun the test, read the output, repeat. In the experience of most of the community, this is what debugging Rust means.
In the walkthrough, printing the intermediate ordering of points reveals the problem. Points with the same polar angle are being ordered farthest-first, and reversing the distance comparison fixes the ordering. The next test run passes.
This method works well for small programs, and its popularity is rational. There is no setup, no new tool to learn, and the output is in the same terminal as everything else. The costs appear with scale. Every question requires a recompile and a rerun, which is an iterative and tedious process, and in large projects the edit-compile-print cycle dominates the debugging time. Print debugging also only shows the values you thought to print, which is a subtle limitation: you cannot inspect what you did not anticipate. It is the foundation of debugging Rust, and it is worth mastering before anything else.
For the survey's majority, this is debugging Rust: fast, familiar and good enough for small crates. The numbers say the friction of everything above it has never seemed worth paying.
Method two: rust-lldb and rust-gdb in the terminal
The second approach inspects the same failing test without changing the source at all. Rust ships wrappers around the standard debuggers, rust-gdb and rust-lldb, which handle Rust-specific symbol details and are the classic next step after prints for debugging Rust programs.
The workflow is manual. Set a breakpoint on the comparator, run only the failing test, and inspect the current frame. At the breakpoint in the walkthrough, one value is 36 units squared from the pivot while the other is only 4. The comparator uses b.cmp(a), so points with the same polar angle are sorted in reverse distance order. That is the bug: the farther point is processed first and later removed from the hull. The fix is one comparison reversal.
The advantage over printing is inspecting any state at any moment without editing and recompiling after every question. The trade-off is the workflow itself: you need to know which debugger commands to run, how to set useful breakpoints, and how to navigate frames from a terminal. That knowledge requirement is exactly what the survey numbers reflect. Debugging Rust with the native tools is powerful, and it is not beginner-friendly. It is also the step where most developers who try a debugger for the first time either stay or bounce back to prints.
Method three: RustRover's graphical debugger
The third approach puts a graphical interface on top of the same GDB and LLDB machinery. RustRover is JetBrains' cross-platform IDE built specifically for Rust, integrating Cargo projects, tests, code analysis and debugging in one place, and it is free for non-commercial use. The recommended installation path is the JetBrains Toolbox App, which handles updates and switching between stable and early-access builds.
In practice, the workflow collapses to clicking the gutter to set a breakpoint and clicking the debug icon next to the failing test. Variables, watches, stepping and expression evaluation happen in panels rather than commands, which removes the command-knowledge barrier that keeps half the community in print statements. For developers who have found debugging Rust in the terminal intimidating, this is the intended entry point. Debugging Rust in RustRover also integrates with the rest of the IDE, so tests, build output and breakpoints live in one window rather than three.
The interesting part is what happens under the hood, because a graphical debugger for Rust is not a trivial port of a Java debugger.
In an episode of the Rust in Production podcast with Matthias Endler, the JetBrains team explained the mechanism. RustRover turns the source into its own PSI representation, then a typed high-level representation, and finally MIR, Rust's mid-level intermediate representation.
When you evaluate an expression or call a function during a debug session, the IDE lowers that expression to MIR and sends it to the debugger to execute against the paused process. The debugger, in other words, actually understands the Rust expression you are asking about, including the borrow and type semantics that make Rust symbols opaque to generic debuggers.
That machinery is why debugging Rust has lagged debugging C or Java, and why it is catching up. Generic debuggers see Rust's memory layout as an unreadable soup of types, while an IDE that compiles your expressions through its own analysis can present variables the way the source code defines them. The gap between the two experiences is the gap the survey is measuring.
The bonus method: an AI agent running the debugger
The final section is the one that points forward. Starting with RustRover 2026.3, the IDE's integrated MCP server, the Model Context Protocol, can expose the debugger to agents such as Codex and Claude Code.
Setup is two clicks: enable the server under Settings, Tools, MCP Server, and click Auto-Configure next to your agent, then restart it. After that, the agent can start a debug session, set breakpoints, step through the program, read variables and evaluate expressions, the full debugging workflow, without a human clicking anything. Debugging Rust becomes something an agent can do while you watch, which is a sentence that would not have made sense in 2021.
The walkthrough demonstrates the mode with a simple goal: debug and fix this problem with the RustRover MCP. The recording shows Codex, running inside RustRover through the new Air plugin, executing the failing test, setting breakpoints, inspecting runtime values and applying the fix while a human watches.
The author's framing is the right one. The agent is not a replacement for the debugger. It is a consumer of it. This distinction matters and is easy to miss: an AI assistant that only reads code is guessing about runtime behaviour, while an agent driving a real debugger can verify its hypotheses against the running process. The MCP exposure turns the debugger from a human interface into an agent capability, which is a genuinely new development in tooling, and it is the piece that could move the adoption numbers the survey has tracked for years. Debugging Rust has never had an automation path before.
For teams already using agents elsewhere, the workflow is familiar. Our coverage of programmatic tool calling for agents and how developers supercharge Codex alongside other agents shows the same pattern of agents gaining access to specialised tools rather than replacing them. A debugger is simply the newest and most interesting tool on that list. And for teams weighing workspace tools, our look at Orca's coding-agent workspace covers the orchestration side of the same trend.
What the survey numbers tell us about debugging Rust
The survey data deserves its own reading, because it explains why all four methods coexist in 2026.
The rise from 36 percent to 46.8 percent debugger adoption since 2021 is real progress, and it tracks with the maturation of tooling like RustRover and the rust-gdb and rust-lldb wrappers. But the majority is still outside the debugger, and the stated reasons are honest: prints are faster for small problems, setup is difficult, and stepping breaks on async and macros.
Async deserves specific attention. Rust's async executor model means a single logical task can hop between threads, and a debugger's thread-centric stepping model does not map onto it cleanly. Macros expand into code the developer never wrote, so stepping through them is stepping through generated noise. Those are structural problems, not polish problems, and they explain why the adoption curve flattens even as the tools improve. Debugging Rust async programs remains the language's hardest debugging problem, and no tool in the walkthrough claims to have solved it.
The survey also explains the ecosystem's culture. Rust developers value control and explicitness, and print debugging is the most explicit tool there is: you decide exactly what to observe and where. The debugger adoption gap is not ignorance. It is a preference that only better tooling, better async support and easier setup will shift.
For teams, the practical implication is that debugging Rust in 2026 is a skills question. The tools exist. The walkthrough proves they work on a real bug. The gap is that most developers have never crossed the setup barrier, and the survey suggests the fastest bridge is a graphical debugger that removes the command-line knowledge requirement entirely.
What the ecosystem should do next for debugging Rust
The survey and the walkthrough together point at three improvements that would move the numbers more than any single feature.
Setup should disappear. The complaint about difficulty is not about concepts, it is about configuration: picking a debugger, wiring environment variables, configuring symbols. One-click debugger setup in every Rust IDE, with the toolchain detection that the ModRetro plugin demonstrated elsewhere in this same news cycle, would convert a meaningful share of the print-debugging majority overnight.
Async stepping needs a model, not a patch. Debugging Rust async programs requires the debugger to understand tasks, not threads, and no mainstream tool presents an async-aware stepping view. Whoever solves that, JetBrains, the Rust project or a new entrant, changes the survey's 28.1 percent figure at its root.
And education should follow the walkthrough's format rather than documentation's. The reason the four-method ladder is easy to grasp from this post is that it runs one bug through every tool. Debugging Rust tutorials that do the same, one bug, four tools, honest trade-offs, teach more than reference pages, and they give beginners a decision procedure instead of a menu.
The MCP development belongs on that list too, because an agent that configures and drives the debugger is functionally a setup eliminator. The survey has measured a gap for four years. The pieces to close it are now on the table.
The escalation ladder in practice
The four methods form a ladder, and the walkthrough's own progression shows when to climb it. Debugging Rust rewards matching the tool to the moment.
Print debugging is the right tool for a failing test in a small crate, or for a quick hypothesis about a value. The terminal debugger is right when you need to inspect state you did not anticipate, or when recompiling is expensive. RustRover's graphical debugger is right when debugging is a daily activity and the command knowledge barrier is worth paying down once. The AI-assisted mode is right when the problem is well-scoped enough to delegate and the developer wants to watch the reasoning happen in real time.
The order also matters for correctness. The walkthrough's bug was findable by printing, but the terminal debugger found it without any edit-recompile cycle, and the agent found it without any human interaction at all. Teams that debug exclusively with prints are paying the recompile cost on every question, and the survey's 81.3 percent ease figure measures familiarity more than total cost.
There is also a team-level benefit to standardising upward. When one developer debugs in RustRover and another in prints, their shared mental model of the code's runtime behaviour diverges. A common debugger workflow, with shared breakpoint configurations and watch expressions, makes runtime conversations concrete, and the MCP exposure now lets teams write playbooks an agent can execute.
The sources for this article are the JetBrains Rust blog walkthrough and the community discussion on Reddit, both of which are worth reading in full.
Debugging Rust with an agent: what to watch out for
Delegating a debug session to an agent is new, and the walkthrough is candid about the appropriate division of labour.
The agent works best on well-scoped problems: a failing test, a reproducible crash, a wrong value with a known expected output. Those give the agent a verification signal, which is what turns tool use into evidence. Open-ended performance mysteries, concurrency bugs and anything requiring domain judgement remain human work, because the agent can set breakpoints but cannot yet decide which questions are worth asking. Debugging Rust in production still depends on human judgement about what matters.
Verification also matters for trust. Watching the agent run the failing test, set breakpoints and inspect values, as the walkthrough records, turns a black-box fix into an observed argument. If the agent's hypothesis is wrong, you see it in the debugger before it lands in a commit. That observability is the difference between delegation and abdication, and RustRover's decision to expose the debugger rather than a summary is what makes the difference possible. Delegating debugging Rust to an agent without watching is how subtle regressions slip in.
Questions readers are asking
Why do most Rust developers avoid debuggers?
The survey says it directly: 81.3 percent find print statements easier and faster, and setup is difficult and not beginner-friendly. Stepping also breaks frequently around async code and macros, which affects 28.1 percent and 23.0 percent of users. The tools have improved since 2021, when only 36 percent used a debugger, but the majority has not crossed over.
Do I need RustRover for debugging Rust?
No. rust-gdb and rust-lldb ship with the toolchain and work in any terminal, and print debugging remains a legitimate technique. RustRover adds a graphical interface over the same underlying debuggers, plus the MIR-based expression evaluation and the MCP server for agent integration. It is free for non-commercial use and installs through the JetBrains Toolbox App.
How does the AI-assisted debugging actually work?
Starting with RustRover 2026.3, the IDE's integrated MCP server exposes debugger controls, sessions, breakpoints, stepping, variable reads and expression evaluation, to agents such as Codex and Claude Code. Enable it under Settings, Tools, MCP Server, click Auto-Configure for your agent, restart the agent, and it can run the full debugging workflow against your program.
Is the MCP debugger access specific to Codex?
No. The MCP server exposes the debugger to any agent that speaks the protocol, and the walkthrough demonstrates Codex and names Claude Code. Debugging Rust through an agent is therefore not tied to one vendor, and the Auto-Configure step handles the connection details for supported agents.
Can an AI agent replace the debugger?
The walkthrough's answer, which matches the evidence, is no. The agent drives the debugger rather than replacing it, because reading code is not the same as observing a running process. The combination, an agent setting breakpoints and inspecting live values, is more capable than either the agent alone or the debugger alone. That combination is the newest chapter in debugging Rust, and the most promising one for the survey's silent majority.
The bottom line
Debugging Rust in 2026 is not one workflow, and the honest conclusion of the JetBrains walkthrough is that you should pick the tool that fits the problem: println! for small loops, rust-lldb when you need live state without recompiles, RustRover when the graphical workflow pays for itself, and an MCP-connected agent when the problem is scoped enough to delegate. Debugging Rust rewards matching the tool to the moment, and it penalises the habit of using one tool for every problem.
The survey number that should bother the community is not the 46.8 percent who debug with tools. It is the majority who do not, in a language whose safety guarantees are only half the story once code runs. The walkthrough makes the case that the barrier is setup and familiarity rather than capability, and the MCP development points at a future where the debugger knowledge barrier is paid down once, by an agent, on everyone's behalf. Debugging Rust in 2026 has a tool for every developer. The remaining work is making sure every developer knows it.