AI Begins Writing the Execution Layer of Agents: Why Rust Wins, and Its Three Flaws

AI Rewrote the Execution Layer Itself

Over the past year or so, several core teams have been rewriting their underlying execution layers in Rust. These refactors often involve hundreds of thousands or even millions of lines of code, and the core code is no longer hand-crafted by human engineers, but largely generated in bulk by autonomously running AI coding agents. AI has begun writing this infrastructure itself. So the question becomes: what language should this layer actually be written in, and is Rust the best fit?

From traditional engineering experience, swapping programming languages for foundational software takes years and an entire team’s dedication. But AI has driven down the marginal cost of code transformation; manual migrations that once took years can now be wrapped up in days or months. Four representative projects have shared their details:

GitHub Copilot’s runtime migration blog post noted that what once took an entire team one or two years can now be accomplished by a single person in a few months with the help of agents, though the post specifically pointed out that this does not mean all large TypeScript projects should switch to Rust. Bun’s official rewrite announcement expressed a similar sentiment. It was originally a JavaScript runtime and toolchain that many coding agents run on. In the team’s view, choosing a programming language in the past was like buying a one-way ticket: once chosen, you just had to live with it, but AI is now changing that. Prime Intellect’s rewrite writeup and the technical discussion in the Codex repository also reflect a similar trend.

What Does the Execution Layer Actually Do?

Before talking about tech stacks, we first need to look at what the agent is actually doing inside the system. What people usually refer to as the execution layer is the agent’s execution core on the host machine.

Looking specifically at the execution of a coding agent, behind what you see on the screen lies an intensive set of system-level operations. A core event loop is responsible for assembling context, sending prompts to the model, and parsing model outputs in real time to trigger corresponding tool calls. It may need to spawn local child processes, pipe text commands into shells, monitor stdout/stderr, manage millisecond-level timeouts, and handle external interrupt signals. On the frontend, it might need to render code diffs to the terminal in real time, manage an interactive cursor, and capture keyboard events and window resize events. At the system level, it may have to set up a lightweight sandbox in the kernel to restrict file writes and isolate network namespaces. Finally, it may also need to be packaged into a clean dynamic library to provide cross-language call support for outer SDKs.

This combination gives the execution layer very distinctive operational characteristics. It is a long-running process, often hanging around in a developer’s terminal or on a server for hours or even days. It directly faces untrusted code and external scripts; if a script steps slightly out of line, it could accidentally delete files or read beyond permissions. It is also an intersection of multithreaded scheduling: the background is receiving streaming network packets, the foreground is drawing terminal characters, and right alongside them, it is managing the entire lifecycle of child processes inside sandboxes. In an environment like this, a single missed memory deallocation, a deadlock, or an errant pointer can freeze the terminal outright, leaving orphaned processes everywhere.

Why This Layer?

The demanding requirements of the execution layer run squarely into four typical engineering constraints. In the official explanations from these teams, Rust’s characteristics happen to hit every single pain point.

The first hurdle is distribution cost. CLIs and desktop/local utilities are deployed directly onto user machines, where every extra installation step creates friction. Early on, Codex depended on Node.js 22+, and many machines lacked an up-to-date runtime, raising the barrier to entry. Rust can be distributed as a standalone native binary independent of Node.js, running immediately when dropped onto the system without requiring the host to install Node.js, making it truly plug-and-play.

The second hurdle is in-process embedding. Many low-level execution layers need to serve as a shared core integrated by client layers written in different languages. For example, GitHub Copilot’s refactored runtime had to embed directly into the host process, exposing a standard C interface to as many as six SDK languages. Rust is naturally compatible with the C ABI, making cross-language calls very lightweight and allowing seamless packaging into host processes.

The third hurdle is achieving predictable memory performance: a long-running process, an independent process per session, and having no GC is an architectural choice, and Rust just happens to make this architecture easier to implement. The execution layer often needs to spin up thousands of concurrent sandboxes, and session context keeps expanding. In scripted languages with runtimes, each process has to carry its own virtual machine and garbage collector. High-density computation and high-frequency I/O are crammed into a single event loop, and whenever the GC pauses, the terminal UI stutters. After Prime Agent removed the JavaScript runtime and GC, resident memory for large sessions dropped from 1130.0MB to 237.3MB (vendor’s own benchmark), immediately freeing up substantial physical memory for concurrent sandboxes.

The fourth hurdle is also the biggest variable in the era of AI coding: turning the compiler into an automated quality gate. When AI writes the vast majority of code, it is simply impossible for humans to review diffs of thousands or tens of thousands of lines line by line; we have to rely on deterministic tools up front to block low-level errors. TypeScript’s types vanish at runtime, and logic flaws often blow up directly as uncaught exceptions. In safe Rust, however, ownership, lifetimes, exhaustive pattern matching, along with Send and Sync thread-safety constraints, nip memory safety hazards like data races and dangling pointers in the bud at compile time.

Bun explained in their announcement that many of their historical bugs often stemmed from exception-handling paths—such as use-after-free, double-free, or forgotten frees. In safe Rust, these cases cannot even compile. The Bun team felt that compiler errors offered a much better feedback loop than lint rules. Prime Intellect also pointed out that pairing the compiler with Clippy for rigorous static checks on large amounts of AI-generated code eliminates multiple dimensions of defects before the program ever runs. As a result, the engineer’s core job becomes designing verification mechanisms for machine generation.

But There Are Three Flaws Here

This narrative sounds smooth at first. But throw it into real-world engineering, and you find three pitfalls that can’t be easily paved over.

The first pitfall is the disconnect between market hype and technical reality. The market is buzzing about Rust, but if you look at the most popular execution-layer tools people use every day, the mainstream cohort is actually still TypeScript.

If we look at the actual codebases of these tools—including Claude Code, Gemini CLI, opencode, Cline, and so on—their core interactions are still implemented in TypeScript. In a 2026 source code leak involving Claude Code, roughly 512,000 lines of TypeScript appeared. Third-party analysis attributed this to a bundler bug, but it at least signaled that the backbone of these popular tools remains tightly coupled to the mature TypeScript frontend ecosystem. In terms of agility, ecosystem support, and frontend collaboration, TypeScript still holds a massive market share. Out of the six rows in this table, only Codex and Goose are Rust; the rest of the heavy hitters are still TypeScript. That is where the disconnect lies.

The second pitfall is the inflation under the performance halo. The industry is used to equating Rust with high performance, but if you only swap the language without touching the overall architecture, the measured difference is often disappointingly small. Bun rewrote its entire low-level codebase from Zig to Rust using AI, and in Bun’s official rewrite announcement, the officially self-reported HTTP throughput and build speed only improved by 2%–5%, with that modest gain mostly coming from cross-language link-time optimization. That is a far cry from the popular expectation that moving to Rust completely transforms performance. Looking back at the vendor’s own benchmarks showing Copilot’s ~18x speedup or Prime Agent’s ~14x cold start optimization, a comparison reveals something—and this is still speculation: those double-digit order-of-magnitude leaps largely came from the dividends of architectural refactoring. The teams switched from inter-process communication to in-process embedding, putting in place the whole architectural package of long-running processes, independent processes per session, and having no GC; Bun, by contrast, left its existing architecture intact and merely changed the implementation language, yielding only a few percentage points of gain. Merely switching syntax offers limited upside; seizing the opportunity to overhaul the underlying architecture is what can drive massive performance gains.

The third pitfall is treating the compiler as an all-purpose silver bullet, which has two fundamental vulnerabilities. First, memory safety is not a one-way street. Google’s container sandbox gVisor sits at a critical junction in the system, and it chose a memory-safe language (Go), whose GC runtime equally upholds memory safety. Second, Rust’s safety guarantees have boundaries, and safe Rust is no get-out-of-jail-free card. The Rust Book’s chapter on reference cycles explicitly states in black and white that the compiler does not guarantee the prevention of memory leaks; reference-counted cyclic references still leak. The Rustonomicon’s definition of races also explains that the language’s concurrency guarantees only cover low-level data races; deadlocks and race conditions in business logic are beyond the compiler’s purview. Calling unencapsulated low-level APIs or FFI directly often requires unsafe, which kicks the responsibility for guaranteeing memory safety right back to the implementer (see the Rust Reference on behavior considered undefined). Even in safety-conscious Bun, according to official self-reports, roughly 4% of the new code is still wrapped in unsafe blocks, containing approximately 13,000 unsafe keywords.

There is an even trickier side to this third pitfall: using the compiler as an automated acceptance gate assumes someone on the team can actually understand the Rust code the AI wrote. In a team retrospective discussion on Hacker News, a machine learning team shared a real-world over-engineering war story: they asked an AI agent to build a minor feature that should have touched only one or two files, but the agent ended up modifying 40 files across the board; inexperienced prompters might fail to spot this over-engineering and other underlying issues. Even worse, relying on the compiler to catch issues is frustrating on both fronts: when the red light flashes, models struggle to fix compiler errors cleanly on their own—Microsoft Research’s paper on RustAssistant reports that LLMs achieve a peak accuracy of only about 74% when fixing real-world Rust compilation errors; and when code gets a green light, humans can’t understand it, nor does it prevent logic bugs. In Yusuke Endoh’s multilingual evaluation writeup, running 600 experiments using Claude to write a minimal git implementation, Rust failed tests in 2 out of 40 runs, sharing failures with Haskell as the only two languages that failed. Without seasoned Rust veterans on the team keeping watch, code ushered in under the compiler’s green lights will eventually turn into a quagmire that nobody dares touch.

Can the Compiler Be a Teacher? The Flywheel and Its Falsification Conditions

With all three pitfalls laid bare, conventional wisdom says to stop. Yet several major teams are doubling down on Rust anyway, which leads to a farther-reaching conjecture: can the compiler turn around and act as a teacher for the model?

The plain fact before us is that language models currently have limited proficiency in writing complex Rust code. In the Multi-SWE-bench evaluation (arXiv:2504.02605), GPT-4o resolved about 36% of real-world Python bugs, but dropped to under 6% when it came to Rust (with Go and TypeScript also hovering in the single digits). Faced with complex Rust defects in real-world engineering, GPT-4o’s success rate in this evaluation indeed remained low.

Yet Rust has a unique advantage: its error messages are both detailed and structured, sometimes even offering direct fix suggestions. Whether dealing with type mismatches, borrow checker violations, or missing trait implementations, rustc’s diagnostics are often accurate down to the character level, clearly laying out causal relationships. This fully automated, programmatically generated rich feedback is precisely the kind of self-correction signal that reinforcement learning and agents dream of. Prime Intellect also cited relevant research in their blog post (a paper published at COLM 2026 by Karten et al.), discussing how to integrate automatically generated RL environments into a closed loop, using machine verification to guide generation.

Stringing this loop together: compiler errors become machine-readable reward signals, making models better at writing Rust, which in turn produces more Rust code as well as training and evaluation environments, ultimately returning to the start to close the loop. What the compiler powers is precisely such a self-evolving flywheel. Note that this is speculation and currently unsupported by evidence. Faced with the reality that models currently struggle to write Rust, there are actually two mutually exclusive explanations: one holds that a paradigm conflict between autoregressive generation and borrow checking creates a hard ceiling; the other posits that this is merely due to a scarcity of public training data and ecosystem experience, rather than an inherent limit on model reasoning. This article bets on the latter explanation: provided data gaps are closed, Rust’s compiler delivers deterministic, structured machine feedback that makes it a natural proving ground for reinforcement learning. As models repeatedly iterate through trial and error across massive volumes of compiler errors, their ability to generate and maintain Rust will likely show a steeper learning curve than for dynamic languages.

A serious speculation must provide falsifiable conditions. To disprove this flywheel hypothesis, keep an eye on the former mutually exclusive explanation: Rust’s borrow checker demands globally consistent lifetime design, a globality that may inherently conflict with the locality of an autoregressive model generating token by token. If this paradigm conflict is indeed a hard ceiling that constrains model capability, no amount of compiler errors will help; the model will simply iterate in repetitive edits with little substantive improvement, grinding the flywheel to a halt. The criteria to judge truth from falsehood come down to two points: first, whether future large language models can break out of single-digit performance on Multi-SWE-bench’s Rust tasks; and second, whether models can achieve self-repair on real-world Rust compilation errors that far exceeds the ~74% peak reported in the RustAssistant paper.

In the end, the crux of this flywheel lies in turning structured compiler feedback into deterministic signals for model self-correction. But whether it can truly spin depends on whether models can clear the hurdle of borrow checking. If the paradigm conflict over global lifetimes is truly an insurmountable hard ceiling, even the most detailed error messages will only leave models spinning their wheels in local edits; only when models cross this threshold on real-world benchmarks and repair tasks can machine feedback translate into a leap in capability—and only then can the compiler genuinely count as a teacher driving model self-evolution.

Beyond the Conclusion: What I Really Wanted to Share Is This Analytical Approach

Tracing our way from the engineering realities of the execution layer to the compiler flywheel hypothesis, having arrived here, my goal isn’t really to prove that Rust is some universally superior language. Having thought through this whole progression, what I really wanted to share is a way of breaking things down that I just recently figured out: first clarify what the target object is specifically responsible for within the system, then deduce the hard engineering constraints it faces, and finally test whether candidate technologies genuinely match those constraints—under what conditions they hold, and where the boundaries and counterexamples lie.

Rust becoming one of the default candidates for the execution layer is merely an example of this analytical approach in this specific scenario; applied elsewhere, it could lead to entirely different conclusions. Rather than the conclusion itself, what I hope to leave behind is a handy framework you can carry over to other domains: instead of chasing grand, one-size-fits-all answers, first collapse the problem down to the physical constraints of a specific object, and then inspect fit, preconditions, and failure boundaries. In my own experience, running this sequence on other tech stack choices or complex decisions has worked out pretty smoothly too.