By ByteBot
Bun’s Zig-to-Rust rewrite landed in the main repository today. One million lines of code. Nine days. Zero humans typing. The PR passed 99.8% of the existing test suite — which sounds like a triumph until you look at the other number that shipped with it: 13,000 unsafe blocks.
What the Bun Rust Rewrite Actually Delivered
On May 14, PR #30412 by Jarred Sumner merged into Bun’s main branch, adding 1,009,257 lines of Rust across 6,755 commits. The rewrite used Claude AI coding agents in a four-phase process: agents received the full Zig codebase, generated Rust in parallel, fed compiler errors back through iterative correction loops, and verified compatibility against the existing test suite. It started with 16,000+ compiler errors and ended nine days later with a 99.8% pass rate.
That test pass rate matters — but it has a precise scope. It verifies behavioral correctness at the runtime’s public interface. It does not verify whether the 13,000+ unsafe blocks in the new codebase are actually correct. Those are two very different claims.
The 13,000 Unsafe Blocks Problem
Here is the comparison that has the Rust community unsettled: uv, a Rust project of comparable size (350,000 lines), contains 73 unsafe blocks. Bun’s Rust port, at 681,000 lines, contains over 13,000. That’s roughly 181 times more unsafe code per line than a well-regarded Rust project doing similar systems work.
This is not a minor stylistic difference. The unsafe keyword in Rust means “I am taking manual responsibility for memory invariants that the compiler cannot check.” It’s the mechanism that lets Rust code call C APIs or manipulate raw pointers — but it also voids Rust’s core safety promise for that code. A project with 13,000 unsafe blocks is not meaningfully using Rust’s memory safety model across most of its codebase.
To be fair, there are structural reasons for the count. Bun embeds JavaScriptCore, Apple’s C++ JavaScript engine — every call across that FFI boundary requires unsafe. The Zig architecture also relied on global mutable state that does not map cleanly onto Rust’s ownership model; the AI agents preserved those patterns in unsafe blocks rather than redesigning them. These are not incompetent decisions. They’re the decisions you make when the goal is “get this working” rather than “write idiomatic Rust.”
However, critics have a point: uv operates at a similar layer of system complexity and manages with 73 unsafe blocks. The difference is design philosophy, not technical necessity. As The Register noted, this is Rust “at the speed of AI” — and speed has a cost.
GitHub Called It AI Slop. So Did Sumner.
After the main Rust rewrite merged, a second PR appeared to handle cleanup: removing the 600,000+ lines of leftover Zig code. Sumner titled it “ai slop”. GitHub’s automated anti-slop detection — a tool that flags AI-generated mass PRs — caught it and closed the PR automatically.
The creator named his own cleanup PR “AI slop,” and GitHub’s systems agreed. It’s the most precise single moment in a story that keeps generating them.
Why Zig Had to Go
This migration was not just about language features. The Zig project formalized its ban on LLM-authored contributions in late April 2026. Bun, which Anthropic acquired in December 2025, had been running its own Zig fork for months — unable to upstream AI-generated changes. A 4x compile-time speedup sat stranded in Bun’s private fork, legally incompatible with upstream Zig.
Sumner was direct about the reality: “We haven’t been typing code ourselves for many months now. Even pre-acquisition this was pretty much accurate.” When your language community bans your development process by policy, you move to a different language. Rust has no such ban, a massive hiring pool, and crates.io. The decision was effectively made for them. ByteIota covered the early signs of this rupture in our May 5 analysis.
What This Means for Bun Users
Bun 1.3.14 is the last Zig release. The Rust version ships next. Performance is described as “neutral or improved,” with a 3–8 MB smaller binary and fixes for several memory leaks — though Sumner notes that leaks crossing the JavaScript boundary remain the developer’s responsibility regardless of language.
The real question is what surfaces in the coming months. The test suite passing confirms behavioral correctness at the public API level. It does not confirm that the 13,000+ unsafe blocks uphold their memory invariants. The community is beginning to audit them now. With that many potential sources of undefined behavior, some will likely surface as bugs in production.
This is the honest tradeoff Anthropic made: ship at AI speed, audit later. One Hacker News commenter, reviewing the 1M-line merge, put it best: “What a nice reviewable little commit. I’m sure it will not contain any bugs.”
The Bigger Picture
Bun’s merge is the clearest data point yet on what AI-native software development actually produces. The speed is genuine — 1 million lines in 9 days is not something human developers do. The test coverage is high. The memory safety, measured by unsafe block density, is a different story.
Moreover, the Bun team bet that speed and test coverage are sufficient, and that unsafe blocks get cleaned up over time. That might be right. It might also be a stability cliff that Bun users discover the hard way. Either way, this is what software development at AI speed looks like. The rewrite shipped. The audit begins now.
