When a model writes most of the code, the bottleneck moves to checking it. Rust puts a large part of that checking into the compiler, which reads every line the model writes and refuses to build whole classes of mistakes.
That's why we think Rust is one of the best target languages for AI-assisted development. The model gets fast, precise feedback, and the code that reaches a human reviewer has already cleared a strict bar.
Generated code looks right whether or not it is
A language model writes plausible code. Plausible and correct overlap a lot, but not always, and the gap is hard to see by reading. In one well-known study, researchers asked GitHub Copilot to complete 89 security-relevant scenarios and found about 40% of the 1,689 programs it produced were vulnerable (Pearce et al., IEEE S&P 2022).
Human review catches some of this. It's also slow, and it gets slower as the amount of generated code grows. So the useful question is how much of the checking a machine can do before a person looks.
The Rust compiler rejects mistakes other compilers accept
Every typed language catches some bugs at compile time. Rust catches more of the kinds that matter in real systems, and it does so by default.
A missing case is a compile error. Here a model adds a Refunded state and forgets one of the places that handles it:
enum Payment { Pending, Settled, Refunded }
fn label(p: &Payment) -> &'static str {
match p {
Payment::Pending => "pending",
Payment::Settled => "settled",
}
}
The build stops with error[E0004]: non-exhaustive patterns: &Payment::Refunded not covered and points at the line. In many languages that code runs and returns nothing useful for refunds until a customer finds it. Rust requires every match to cover every case (The Rust Book, ch. 6.2).
The same goes for the bugs that are hardest to find by testing. Safe Rust guarantees the absence of data races (The Rustonomicon). A model that shares a mutable counter across threads without a lock gets a compile error, where the same code compiles in C++ or Go. Rust also has no null reference (ch. 6.1). In safe Rust, the borrow checker refuses a reference that outlives its data (ch. 4.2).
None of this checks business logic. A model can still compute the wrong refund. The compiler narrows what a reviewer has to look for to the part that needs a human.
Compiler errors are feedback a model can act on
The other half of the argument is what the compiler says when it refuses. Rust's errors name the problem, the line and often the fix. That makes them good input for a model.
Microsoft Research built a tool on exactly this loop. RustAssistant feeds compiler errors back to a language model and recompiles until the build is clean. On real compilation errors from popular open-source Rust repositories it reached a peak accuracy of about 74% (Deligiannis et al., ICSE 2025).
Types help even earlier. Researchers at ETH Zurich and UC Berkeley constrained a model's output to well-typed programs as it generated them, and compilation errors fell by more than half on standard benchmarks (Mündler et al., PLDI 2025). That work used TypeScript. The mechanism is the type checker, and Rust's is stricter.
So the loop is short. The model writes, the compiler objects in specific terms, the model fixes it. Most of that happens before anyone opens a pull request.
Google's numbers show what code that compiles in Rust is worth
This only matters if code that gets past the Rust compiler is actually better. The largest public evidence is from Android, where Google has written new code in Rust alongside C and C++ for several years.
Google reports a 1000x reduction in memory safety vulnerability density in Android's Rust code compared to its C and C++. For medium and large changes, the rollback rate of Rust changes is about 4x lower than C++. Rust changes also spend about 25% less time in code review and need about 20% fewer revisions (Google, "Rust in Android: move fast and fix things", 2025-11-13).
Those are human-written changes. They measure what the language does to the code that survives it, and that's the property an AI-assisted team wants: less to review, and fewer surprises after merge.
Bun moved its whole runtime to Rust with AI doing the porting
The largest public test of this so far is Bun, the JavaScript runtime. In May 2026 its creator ported 535,496 lines of Zig to Rust with about 50 AI workflows running in parallel for 11 days. His reason was the class of bug Rust's compiler is built to refuse: "A large percentage of bugs from that list are use-after-free, double-free, and 'forgot to free' in an error path" (Jarred Sumner, "Rewriting Bun in Rust", 2026-07-08).
The compiler set the pace. Roughly 16,000 compiler errors became the work queue, fixed crate by crate, and the port merged only when 100% of Bun's existing test suite passed on every platform. Bun 1.4.0 fixes 128 bugs that reproduce in 1.3.14, and a build loop that reached 6,745 MB of memory in the old version stays at 609 MB in the new one.
The regressions it did ship tell the other half. Most came from code that was syntactically identical in both languages but meant something different, which no compiler catches. The test suite caught those.
What it costs
Rust is slower to get to a first build, for people and for models. In our experience, models struggle most with lifetimes and ownership across async code and threads. They can loop on borrow checker errors, trying small variations that don't address the design problem underneath. When that happens, the fix is usually a person changing the shape of the data, which a model rarely proposes on its own.
Compile times are also longer than in most languages a team might pick instead. In an AI loop, every round trip waits for the compiler.
And the compiler checks types. Tests, specifications and a reviewer who knows the domain are still needed to check that the program does what the business needs.
We think the trade is worth it for anything that runs in production and handles money, user data or concurrency. The time a model spends satisfying the compiler is time a human would otherwise spend finding the same mistakes in review, or in an incident.
Where we fit
MLabs writes production Rust and Haskell, and we publish Rust crates that others depend on, including lbr-prelude, the LambdaBuffers Rust runtime. We put senior engineers inside a team for a quarter at a time, and we use AI tools in the way this post describes: a specification first, then fast generation, then verification. Request a quote or learn more.
