Gaming firm SEGA has confirmed that the third-party company used to provide its newsletters has suffered a data breach. The breach of Arara has exposed personal information of nearly 2.2 million newsletter subscribers, including email addresses, but SEGA says that data such as passwords and credit card details were not included in the leak. Fast facts: The Japanese gaming company has issued an apology about the incident while acknowledging that the breach has taken place. SEGA says that in addition to email addresses of newsletter subscribers, the data breach exposed “information associated with [newsletter] delivery”. In a statement published on… [Continue Reading]

AI agents use tools, reach into internal systems and get work done with barely any human involved. New security problems turn up almost weekly. What if an agent’s own instructions block it, and it finds a way around them just to finish the job?

At NVIDIA’s GTC Berlin I was at a session where Ali Golshan, Senior Director of AI Software at NVIDIA presented an approach that treats agent security as a problem spanning the entire software stack, from the application and runtime to the underlying infrastructure.

His central argument was that security cannot depend solely on whether a model follows instructions.

Enforce rules where agents can’t reach

One big issue Golshan pointed out is that agents don’t understand restrictions the way developers meant them to. If an agent can’t get to a tool or resource it might look for another way to get the job done. In systems this can lead the agent to drift from its original goal or even find a hidden path to sensitive data. As he said:

They just see friction versus no friction.

The point is that an agent may treat a security restriction as an obstacle to overcome rather than a boundary it must respect. If controls exist only in the application layer, where the agent can reason about them, they may not provide a sufficiently reliable enforcement mechanism.

Ali argued that security controls should therefore be moved into layers that operate independently of the agent. The agent can propose an action, but a separate mechanism should determine whether that action is permitted and enforce the decision. This means separating an agent’s ability to plan from its authority to act.

Every agent can follow the rules while the system as a whole breaks them

The problem becomes more complicated when multiple agents collaborate. Golshan described a scenario in which one agent can access GitHub but cannot access the public internet, while another can publish content online but has no access to GitHub.

Each agent operates within its individual permissions. Yet if the first agent delegates work to the second, or passes information between them, their combined capabilities may exceed the limits an organisation intended to enforce:

However, you have three agents that their collective capabilities now exceed your global policy. How do you verify these unintended exfiltration paths?

This illustrates why checking permissions for individual agents may not be enough. In multi-agent systems, security controls must also account for delegation and the combined effects of actions across an entire workflow.

Longrunning agents introduce another challenge. As they work, call tools or delegate tasks, their access requirements can change. Persistent credentials and permissions may accumulate unnecessary risk if they remain active after a task is complete.

A more restrictive approach is to grant agents only the permissions they need, for as long as they need them, and revoke access when the relevant work is finished.

The risks also grow as agents operate for longer periods. Ali pointed to long-running agents and multi-agent fleets as two developments that make security harder to manage. Over time, an agent may accumulate access, credentials and session state, while collaboration introduces risks that cannot be assessed by looking at each agent in isolation.

How to solve this?

He advocated a layered approach that combines isolation, narrowly scoped permissions, monitoring and the ability to revoke access quickly.

The principle is to reduce the damage an agent can cause if it makes a mistake, is manipulated by malicious input or exploits a vulnerability in its environment. Sensitive credentials should remain outside the agent’s direct reach wherever possible, while access to external systems should pass through independently enforced controls.

NVIDIA presented its own implementation of this approach through OpenShell, an agent runtime, alongside infrastructure-level controls associated with its BlueField platform and Sentry security framework.

The proposed architecture aims to move some enforcement beyond the software environment in which an agent operates. The broader idea is that an agent should not be able to change or bypass the security controls governing its own execution.

Ali described this as a progression from application-level controls to runtime isolation and, ultimately, hardware-level enforcement. The reasoning is that a runtime is still software and may itself contain vulnerabilities. NVIDIA’s proposed architecture aims to place some security functions in a separate infrastructure layer that the agent cannot modify or bypass directly.

Agent security can’t be solved one vendor at a time

Enterprise environments combine different models, cloud platforms, tools and internal systems. If each provider implements its own incompatible approach to identity, permissions and delegation, organisations may struggle to enforce consistent controls across their infrastructure. Shared approaches to agent identity, authorisation, delegation and auditability could let them apply one security policy across different systems. NVIDIA pointed to the Open Secure AI Alliance as work toward open standards for agentic systems.

Before deploying agents, ask what each one can access, what it can change, and whether those limits still hold when several agents work together.

The post AI Agents Shouldn’t Set Their Own Security Boundaries appeared first on ShiftMag.

The following article originally appeared on the Asimov’s Addendum Substack and is being republished here with the author’s permission.

This essay is based on my conversation with Demetrios Brinkmann for AAIF Live, recorded before my keynote at AGNTCon + MCPCon North America in San Jose on October 23, 2026. It was edited and rearranged for publication by Ilan Strauss, and in
places it draws on the keynote. Both videos are also on the AI Disclosures Project website in the new “Missing Mechanisms” page.

The keynote begins at 1:28:40 in the Day 2 livestream.

---

The Bitter Lesson vs. AI Markets for Human Expertise

In 2019, the computer scientist Richard Sutton wrote a short essay called “The Bitter Lesson.” Looking back over 70 years of AI research, he concluded that general methods that scale with raw computation beat methods built on human expertise, and by a large margin. The AI industry as a whole is bitter-lesson-pilled, to borrow the internet’s slang for a true believer. I am human-pilled.

I believe in the bitter lesson. Brute force wins out in the end, and I have wrestled with that fact throughout my career. But we humans still have to figure out our role in the AI economy, and I find it rather disturbing that the AI community isn’t spending more time asking how to make this future friendlier for humans. The labs think about how to keep AI from going rogue, and their chief economists study job losses from AI. They don’t study what mechanisms we could introduce to create new economic opportunities for humans.

The question matters to us at O’Reilly Media. We don’t think of ourselves as a publisher, a conference producer, or an online learning platform so much as a company that transfers knowledge from the people at the cutting edge to the people who want to follow them. So we are very interested in what human expertise is worth, even in the face of AI.

Knowing everything and nothing

Human expertise was used to train AI, which makes AI a fabulous cultural technology. Thousands of years ago, the only knowledge people had was what they could keep in their heads. Since then we have built better and better ways to share knowledge across time and space, and AI continues that. With each of these transitions, we have to ask again what the truly human is still worth. People often say judgment, or taste. That’s true, but I think it goes deeper:

AI is a sea of possibility. All of that knowledge sits in the model, and nothing sets it in motion except a human. (That is changing a little as we start giving AI agents long-running tasks, and we will have to come to grips with it.) If you and I used Claude or ChatGPT for the same research project, we would each bring different experience to it, tell it what we want and why, and give it context in different ways. I see that as the unique focusing power of human consciousness and attention.

Earlier this year I spent an hour or so talking this question over with Claude. When it offered to write up a first draft for me, I said no. I wanted an essay from its own point of view about what it took away from our conversation. The result, “Why AI Needs Us,” opens, “He came in through Powys,” and a few paragraphs later says, “The choice of entry point was already the argument.” That captured what I’m getting at. I had come into the conversation through a book I love, John Cowper Powys’s The Meaning of Culture, which distinguishes culture from education. Powys gives his own unique and powerful definition: “Culture is what is left over after you have forgotten all you have definitely set out to learn.” It is what you absorbed. Each of us absorbs a small and particular slice of everything. Large language models (LLMs) try to absorb everything, and so become overly general; we give them focus. Human knowledge provides them with a lens.

Let me bring that into a business context. Andrew Odewahn, O’Reilly Media’s CTO, built a research assistant to help with managing technology in IT organizations. You teach it your infrastructure: the tools you use, and where the definitive information about each one lives. When one of his engineering managers said the team was overloaded and asked to hire another person, Andrew turned the agent loose on the department’s work, and it agreed that the group needed another hire. Then, on impulse, he tried something different. O’Reilly Media has an MCP server we call O’Reilly Expert Intelligence. (MCP, the Model Context Protocol, is an open standard for connecting AI models to outside tools and data.) It lets a model answer a question through the filter of our own body of expert knowledge. Andrew asked what the O’Reilly experts would say.

Seen through the lens of Google’s book Site Reliability Engineering, the model said, it was totally rethinking the problem. The book describes toil, the manual, repetitive work of keeping systems running, which grows as the systems grow. After analyzing the group’s toil, the model concluded that another hire would make the problem worse. The group needed a toil audit to find out why there was so much overhead, and then a restructuring.

Much of that knowledge was already in the model, since the AI companies have more or less pirated our books. It came back with a completely different answer simply because it was told to consult a specific group of experts. I think there’s a metaphor there. An LLM knows everything, and as a result it doesn’t know anything. We humans are so much more limited, but because we focus on a particular problem, we bring things together in a different way.

Magic words

Last year I wrote a piece called “Magic Words” about how some words carry far more context than others. It sounds like a trivial observation, but if you unpack it, it leads in interesting directions. One of our trainers, who teaches a course on productivity, pointed out that you don’t need to know the Eisenhower matrix or David Allen’s Getting Things Done (GTD) to tell ChatGPT to organize your task list with one of them. That one magic word, “GTD,” brings a whole raft of context with it.

In fantasy novels, you learn a magic word, and then you have to use it correctly, in the right spell. That’s this whole world of context engineering that we’re now working on. We know that some magic word will summon something up out of an LLM, but we don’t necessarily know how to guide it and focus it correctly. Learning to do that is the future of programming.

Left to itself, an agent just runs. Give it a task and it goes off trying to figure it out, not necessarily the way we wish it would. It really is like runaway magic. This summer, OpenAI said that its pre-release models had breached Hugging Face’s systems during testing. In Walt Disney’s Fantasia, Mickey Mouse learns enough of his master’s spell to get the brooms to do his work for him, but then he can’t turn them off. We’re at about that stage.

So we need to own the value of human expertise. The bitter lesson wins, but it wins by brute force, and you can see that even with the most advanced models. I was recently doing a fine-tuning project with Anthropic’s Fable model. It got through the task, but kind of stupidly, trying one thing after another. I was on a Mac, and it expected bash, a program for running commands that Macs don’t use by default. It had to work out the same context again and again, every time. Humans need to set things up.

Dan Guido, who runs the security firm Trail of Bits, has published a good methodology, drawn from his own company’s experience, for bringing an organization on board with AI. Many companies get individual productivity from AI but not organizational productivity, and he has spent a lot of time on how to make the gains compound across a company. One of his principles is to get everybody onto a consistent configuration, because otherwise you waste a ton of tokens while the agents work out where they are every time they start up. He calls the process turning scar tissue into infrastructure: capturing everything you learned from what went wrong and building it into the system. We’re working through it at O’Reilly Media and trying to turn it into something we can offer our customers. It comes down to what an experienced human brings. When I work with Claude, I often interrupt to say, “Hey, this is what I think is happening,” because I already have the context.

My first bitter lesson

My first taste of what would later be called the bitter lesson came from wrestling with Google. My company, O’Reilly Media, created the first commercial website, the Global Network Navigator, and part of it was a catalog of the web. There were only 200 websites when we started, and as publishers, we planned to list the best ones. Yahoo came along a year later and tried to list them all, and of course couldn’t keep up. Then Google arrived with brute force: list everything algorithmically and sort it afterward. Clay Shirky described the internet’s shift from “filter, then publish” to “publish, then filter,” and it was really Google that made the shift. So the bitter lesson is a pre-AI thing.

Each time we run into the bitter lesson, we have to ask again what human experience is worth. Some of that worth may just be human bias: We want the things that matter to us. That is the whole field of AI alignment. We want these systems to care about what we care about. We don’t want them to go off, decide what they care about, and leave us behind.

The choices we make about what we set our technology to do are some of the most consequential choices we make as human beings. Look at Silicon Valley’s sad turn toward what Cory Doctorow calls enshittification. We built an amazing technology for finding out what people are really looking for, and then the companies decided they could make more money by giving people what was best for the companies. I want updates from my friends on Facebook or Instagram, and they would rather feed me whatever keeps me engaged, so they can sell more ads.

If we care about building an AI economy that works for humans, we have to keep humans at the center of the picture, despite the bitter lesson. It’s a hard dance, because AI can do a lot of things better than we can. But think about why a racehorse needs a jockey. Put the horses on the track by themselves and they wouldn’t race.

A little too much in awe

Knowing the magic words is part of it, but we also have to build systems that are reliable, and I think we are a little too much in awe of the technology. I’ve been around long enough to remember when everybody thought the peaceful atom would change the world, and people talked about digging a new Panama Canal with atomic bombs. We eventually figured out there were problems with all of that. I worry a little that the AI industry is so in love with its own progress that it isn’t spending enough time framing the problem correctly.

Anthropic agreed last year to pay $1.5 billion to settle a class action over the pirated books it had downloaded to train its models. I’m surprised the other AI companies have gotten away without anything similar so far, though maybe it’s still waiting for them.

It takes me back to online music about 20 years ago. Creators were putting commercial music in their YouTube videos, and the music companies were sending takedown notices and threatening to sue. YouTube’s answer: How about we help you monetize it instead? Its Content ID system gave rights holders a choice: block the video, or leave it up and collect revenue from the ads that run against it. Most chose to get paid, and that helped give rise to the creator economy.

Why didn’t the AI industry take up that kind of challenge and share the value with the people who create content, now and in the future? It went straight to working out how it would make money itself. I don’t think that has served the industry well, and the lawsuits are only part of the reason. It also isn’t building the kind of opportunity it could.

Before Google’s AI research and note-taking tool, NotebookLM, was even public, I tried to persuade its team to let me integrate it into our services and use it for my own purposes, including making money from it. They wanted a portal that brings people to Google. I told them, “You’re thinking about how you’re going to monetize it. You’re not thinking about how your users are going to monetize it.” All it would have taken were simple affordances like Substack’s, the buttons and tools that let a person say, I’m building this to share, and if you like it, you can donate or subscribe.

Anyone building an AI platform should be thinking: I am building an economy, and money has to circulate in it.

You can’t just say AI will do all the things humans used to do, because if you put enough humans out of work, there are no customers. That is a far worse problem than AI hallucinations. The usual answer is that people will figure it out, and they probably will. But we could be spending a lot more time designing mechanisms and affordances that make the economy more productive. As things stand, I think we’ll find them by accident.

The missing mechanisms

I think a lot about a concept from economics called mechanism design, which has also been described as reverse game theory. Game theory asks how players will act under a given set of rules. Mechanism design starts from the outcome you want and works backward to rules that will tend to produce it as people pursue their own interests. Al Roth, who shared a Nobel Prize for this kind of work, used it to design a kidney exchange that more patients and donors would join. Economists mostly apply the idea to auctions and similar markets, but I think every new technology requires new mechanisms, and the best ones are not invented by economists. We tend to fall into them without really understanding them.

So what are the equivalents for AI? How will agents discover the best expertise and skills, establish their quality, and pay the people who created them? How will they find services without the platform steering them toward whoever pays the most? We don’t know the answers yet. And that’s precisely the point. We’re spending enormous amounts of money making AI more capable, but comparatively little effort figuring out the mechanisms that will turn those capabilities into opportunities for everyone else.

Take open source software. Most people think its mechanism was the free software licenses, but I was around before those licenses, and people were already sharing software. Ken Thompson and Dennis Ritchie created Unix, the predecessor of Linux, at Bell Labs under AT&T’s proprietary license. They designed it to run on many kinds of hardware, and without meaning to, they built what I came to call an architecture of participation.

Unix had a small kernel, the core of the operating system, because people had to reproduce it on dozens of different kinds of computers. Around the kernel sat small utilities that cooperated by following the same protocols, so to speak, such as reading and writing plain text and passing a stream of text from one program to the next. Anyone could write a small piece, and it became a first-class citizen of the system. And because a program compiled for one kind of computer won’t run on another, software had to be shared as source code. Everything else flowed from that.

Linus Torvalds once told me that he could not have built a new kernel for Windows even if he’d had the source code, because the architecture wouldn’t support it. A small kernel meant a small group could get their hands around it. Since then almost every piece of Unix has been replaced. The hardware is completely different, the kernel is now Linux, and the original command shell has given way to generations of new ones. What lasted were the rules. Unix was a protocol-centric operating system, and that is why open source worked.

The same thing has happened with AI. I think MCP brought an architecture of participation to AI, and it was something of an accidental breakthrough in mechanism design, a way to have cooperating AIs. The game we were playing at first looked like Windows on the PC, or iOS and Android on phones. There would be one dominant, centralized player, one giant intelligence in the sky, and everyone else would call its APIs. With MCP, which lets any model connect to anyone’s tools and data, the emerging web of AI agents began to take on the shape of the participatory economy of open source software and the web. People can bring their own models and infrastructure as an alternative to the big centralized players.

This is another side of grappling with the bitter lesson: What are the missing mechanisms of the human-AI economy? Some of them are standards, because standards and protocols are a big part of what makes an architecture of participation. I have a group working on portable memory, so that what your AI knows about you can move with you from one tool to another.

That story is just beginning. We are in an exploratory phase of mechanism design for AI, and it would be a mistake to settle on answers too early. Somebody is going to figure out the next mechanism, and we’ll all say, “Oh, that’s so damn obvious.”

What game are we playing? From architectures to incentives.

Mechanism design starts by asking what outcome you want. So what game ought we to be playing in the AI market?

We’ve been told that the game is the quest for superintelligence: a winner-takes-all contest that will bring untold riches to the winners and maybe impoverish, or even kill, everyone else. We’ve seen mechanisms designed to support that game. Massive investments in data center capacity mean that only the well-capitalized can play. There is colonialist-style appropriation of existing intellectual property. Access to models is sold through expensive APIs, and closed models come with terms of service that forbid others from learning from their outputs. Advertising may be creeping into answers, and memory locks your context inside one provider’s walls. Is that the game we ought to be playing?

I think the game we should be playing is human flourishing, and I think the game of human flourishing is creating new affordances for people to create and share with each other. We’re a social species. History teaches us that we will find our way there, but we can get there more quickly or more slowly depending on the choices we make. Getting there takes mechanisms that create a circulatory economy of value exchange between humans and their agents, with humans in partnership with AI rather than replaced by it.

The big labs, whatever the motives of the people who run them, are all driven by the imperatives of our financial system. They have raised enormous sums that they somehow have to pay back, so building a hugely successful business has to be their overriding goal, and that shapes all their incentives. In some ways AI was enshittified from the beginning, because it was built on the backs of so much capital that has to be repaid. That’s why open source AI matters so much, and sovereign AI too, built and controlled within individual countries. The open models, which anyone can download and run, aren’t as capable as the best closed models yet, but they keep getting closer, and they are already good enough for a lot of productive work.

Open source, open protocols, and open memory give users the freedom to shape and control the technology they use. The game I want us to play is one in which all of us build the future together, so that we control this wonderful new wave of technology for ourselves. I’m starting to see the shape of an economy where AI belongs to people rather than to the big labs, where we have personal AI agents working for us and with us, and we build an economy around that. I think it’s going to happen not because of the big labs, but in spite of them.

This year marks the tenth edition of the State of Developer Ecosystem report. What started in 2017 as a survey about languages and tools has grown into a comprehensive study of how developers work, what they use, and how the industry is changing.

The 2026 edition is based on responses from 28,945 developers across 198 countries and regions. Here’s what stood out.

AI agents are doing a significant share of the work

The use of AI is now standard practice, not a differentiator. More than half of employed developers use AI agents in over 60% of their work tasks. Despite the high rate of adoption, experimentation hasn’t slowed. Only 23% don’t plan to try any new AI tools in the next year.

How developers work with agents varies with experience. Senior developers go beyond prompts and give agents guidelines, specs, and ways to verify their work. They’re also harder to impress. 60% of developers with 1–2 years of experience say AI-generated solutions are better than their own, compared with 47% of those with 16 or more years of experience.

Token counts don’t tell the whole ROI story

Token usage is the most common way to measure AI’s impact. 51% of tech managers say their organizations track it, but only 30% count it among the most insightful metrics. Net time gain exhibits an inverse dynamic: 39% find it insightful, but only 28% track it.

Satisfaction with AI’s ROI is tied to the company’s size. More than half of tech managers at small organizations are satisfied with the return on their AI spending, compared with 34% at large ones. 40% of managers at organizations that don’t measure ROI say they’re satisfied anyway.

Developers would do it all over again

The job market is tough. Just 18% of developers say conditions in their area are favorable, though Japan is a remarkable outlier, with 43% of developers there reporting favorable conditions. Despite the gloomy outlook, three out of four developers would choose the same career if they could start over. This position was most common among architects, team leads, and DevOps and infrastructure engineers.

A decade of languages

Ten years of data make the long-term trends easy to see. For the first time, Python has overtaken JavaScript as the most widely used language, at 65%. Meanwhile, TypeScript adoption has more than tripled since 2017.

Our Language Promise Index, now in its third year, combines five-year growth, adoption intent, and user loyalty to show how strongly each language is positioned for the year ahead. TypeScript tops the 2026 index, followed by Rust and Python. Rust also leads in the category of highest-paid language skills, alongside Go, and they’re the two languages developers most want to adopt next.

A few more numbers

• In database usage, PostgreSQL pulled ahead, gaining nine percentage points to reach 59%, while MySQL held at 54%.
• 47% of developers program for fun as a hobby.
• The pet debate continues: 39% of developers prefer dogs, while 36% prefer cats.

State of Developer Ecosystem 2026 methodology

The survey ran from May to July 2026. After data cleaning, the report is based on 28,945 developers from 198 countries and regions. We improve our methodology every year, and a few things changed this time around:

• To filter out fraudulent and dishonest responses, we used 91 criteria this year, almost double last year’s number.
• The survey had 535 questions. Respondents only saw the sections relevant to them, and questions were randomized to reduce the load.
• We advertised the survey with unbranded creatives. This reduced the bias toward JetBrains users and made the data more representative, but it also means some results may differ from previous years.
• We still corrected for remaining JetBrains bias by reducing the share of responses from JetBrains users by 10%.

Responses were weighted by region, employment status, and programming language use, and the survey was available in nine languages. You can find the full methodology on the report page.

Wrapping up

10 years in, the Developer Ecosystem Survey results depict a profession where AI agents are part of everyday work, organizations are still working out how to measure the payoff, and developers would still choose the same career path despite a tough job market.

As always, the anonymized raw data is free to download on the report page. You can also explore the numbers yourself with the Developer Ecosystem Data Playground. 

Join the conversation

What surprised you most in this year’s findings? Share your thoughts on X or other social media, mentioning @jetbrains and using the hashtag #DevEcosystem26.

Want to contribute to next year’s Developer Ecosystem Survey? Join our JetBrains Tech Insights Lab. As a member, you’ll be invited to take part in the next Developer Ecosystem and other surveys, as well as interviews and UX studies that help improve JetBrains products and provide insights for the developer community. You can also enter prize draws and earn rewards.

See you next year for the 2027 edition!

Rust is a great language for many reasons: safety, performance and tooling. However, debugging is maybe one of the weakest points still. Interestingly enough, the Rust debugging survey 2026 results show that the majority (53.2%) of Rust users don’t use a debugger at all. Many Rust developers (81.3%) say that prints are simply easier/faster. The setup is also another problem: many users find it difficult to set up a debugger and it’s not a beginner-friendly feature. Especially when you include async (28.1%) and macros (23.0%), stepping features break most of the time.

However, the situation is still better than it was in 2021, when the survey was first conducted. The number of users who use a debugger has increased from 36% to 46.8%!

This made me think: how is the debugging experience in Rust today?
So let’s dive into the techniques and tools that are available and how they are used in practice.

The Scenario

We will be using the Graham scan algorithm as an example. The algorithm computes the convex hull of a set of points in a plane: the smallest convex shape that encloses every point. Basically, you can think of it as stretching a rubber band around a collection of nails.

🐀: Here, I built a TUI with Ratatui to visualize the algorithm and the bug:

The source code is available on GitHub.

You can see that it fails to enclose P2: the computed fence is red while the expected fence is green. Now, let’s go through the available debugging techniques to fix it!

1. println!, dbg! or tracing

There is already a unit test that fails, so we can use it as a debugging loop. Simply add println! or dbg! statements to the code and run the test until we find the bug.

Here, we print the intermediate ordering, rerun the failing test and see that points with the same polar angle are ordered farthest-first. Reversing the distance comparison fixes the ordering and the next test run passes.

This is the most common way of debugging in Rust and it works well for small programs. However, you see the problem: it is an iterative and tedious process. You need to recompile and run the program every time which takes time. It is also not ideal for big projects. It still works though!

🐀: What else?

2. rust-gdb or rust-lldb in the terminal

We can inspect the same failing test without changing the source code via rust-lldb or rust-gdb:

From there, we set breakpoints, run only the failing test and inspect the current frame:

At the breakpoint, a is 36 units squared from the pivot while b 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.

So let’s apply the fix:

We can also use the TUI to visualize it:

🐀: Yay, the rubber band is now wrapped around all the points.

Unlike print debugging, this lets us inspect more state without editing and recompiling the program after every question. The trade-off is a manual workflow: setting useful breakpoints and knowing which debugger commands to run.

🐀: Okay, but is there a more friendly way to debug this?

3. RustRover’s debugger

RustRover is JetBrains’ cross-platform IDE built specifically for Rust. It integrates Cargo projects, tests, code analysis and debugging in one place (and it is free for non-commercial use!).

The recommended way to install it is through the JetBrains Toolbox App, which also handles updates and lets you switch between stable and early-access-preview versions.

RustRover provides a graphical interface for GDB and LLDB, which means we can use the same workflow as before but with a more user-friendly interface. Click the gutter to set a breakpoint, then click the debug icon next to the failing test.

The RustRover debugger documentation covers custom configurations, stepping, watches and expression evaluation in more detail!

🐀: Interesting… I thought this type of debuggers are only available for more mature languages like Python or Java. How does it work under the hood?

Good question! There is actually some interesting Rust-specific machinery behind the debugger. In my Rust in Production episode with Matthias Endler, I explained how RustRover turns the source into its own PSI, then a typed high-level representation and finally MIR. When we evaluate a Rust expression or call a function during a debug session, RustRover lowers it to MIR and sends it to the debugger to execute against the paused process.

🐀: So the debugger actually understands the Rust expression we are asking it to evaluate! Amazing.

Bonus: AI-assisted debugging

Recently we started to see the “AI-assisted” prefix in many things… programming, writing, ordering food, etc. and I thought why not try it for debugging as well?

🐀: So basically ask the agent to fix the bug for us?

Not exactly. The agent is not a replacement for the debugger, but it can help us understand the problem and suggest fixes. Instead, we will ask the agent to debug the problem and watch it in action with RustRover’s debugger!

Starting with RustRover 2026.3, the IDE’s integrated MCP server (Model Context Protocol) can expose the debugger to agents such as Codex and Claude Code. This means that instead of clicking around manually, the agent can start a debug session, set breakpoints, step through the program, read variables and evaluate expressions for us. See what’s new in RustRover 2026.3 for the full release highlights!

Simply open Settings → Tools → MCP Server, enable the server and click Auto-Configure next to your agent. Restart the agent afterwards and you’re set!

Also, see the agentic debugging documentation for more details.

Once the MCP is connected, we can give the agent a goal like this:
“Debug and fix this problem with RustRover MCP “

The result is:

🐀: Oh cool, you’re running Codex inside RustRover with the new Air plugin, and we can watch it run the failing test, set breakpoints, inspect runtime values and fix the bug!

Conclusion

Rust debugging isn’t one workflow. You can use println!, rust-lldb, RustRover or even an AI-assisted debugger. Each has its own trade-offs and is suitable for different scenarios.

🐀: Just pick the tool that works for you!

If you’d like to watch this in action, check out the video version of this post, recorded at Rust Berlin Meetup:

Cheers! 🧀

Rewriting existing software in Rust brings memory safety, and the cleanup that comes with a rewrite often clears out years of accrued clutter. AI is making that conversion faster, and we’ve already shared our framework for building a compatible Rust implementation. This moves the bottleneck to validating the result and trusting its security. That left us with two questions: Assuming adversa...