Bun Rewrote Its Codebase from Zig to Rust in 11

Joel Spolsky's 2000 essay "Things You Should Never Do" opens with a verdict that has haunted startup engineering teams for a quarter century: rewriting your codebase from scratch is the single worst strategic mistake a software company can make. His cautionary tale was Netscape, which spent three years on a ground-up rewrite while Internet Explorer quietly ate its lunch. The essay became gospel. "Don't rewrite" is practically a bumper sticker in senior engineering circles.

Bun just did it anyway. In 11 days.

Last week, Bun—the all-in-one JavaScript toolkit now under Anthropic's umbrella after being acquired late last year—announced it had ported its entire codebase from Zig to Rust using 64 parallel Claude agents running across four Git worktrees simultaneously. The project touched 1,448 files, produced 652 commits, and at peak throughput was generating 1,300 lines of Rust per minute. The equivalent compute cost, had Bun not been part of the company that runs the token casino, would have been $165,000. The result: 128 long-standing bugs fixed, binaries 20% smaller, performance marginally faster across the board, and—perhaps most tellingly—the rewritten codebase had already been quietly powering Claude Code since June without anyone noticing.

That last detail is either a strong vote of confidence in the methodology or a very convenient piece of post-hoc validation. Probably some of both.

Why Zig, and Why Not Anymore

To understand why Bun made this call, you have to understand what made their Zig codebase genuinely painful to maintain—and it wasn't Zig's fault, exactly.

Bun embeds JavaScriptCore, which is Safari's garbage-collected JavaScript engine. That means half of Bun's objects at any given time were owned by a garbage collector, while the other half lived in manually managed Zig memory. The two worlds had to constantly exchange pointers, and Zig—by design—gives you minimal compiler help with that kind of cross-boundary memory ownership. The predictable result was a changelog full of use-after-free bugs, double-frees, and memory that simply never got released. At one point, Bun's dev server was leaking three megabytes of memory on every rebuild, traced back to a single error path that forgot to clean up after itself.

Memory mismanagement bugs in a mixed-ownership environment aren't a Zig indictment so much as a fundamental impedance mismatch between the language's manual memory model and JavaScriptCore's GC world. Rust's borrow checker doesn't eliminate this complexity, but it does push most of the violations into compile-time errors rather than runtime surprises—which is a meaningful shift when you're trying to ship reliably.

But the memory problems alone probably didn't tip the decision. What did was Anthropic.

Once Bun became part of an AI company, the working assumption became that a large fraction of future code would be written by Claude. And Zig has made its position on AI-generated code unmistakably clear: the project refuses LLM-generated pull requests and will close security reports if the submitter admits an AI found the vulnerability. Beyond the policy stance, there's a practical training-data problem: Zig hasn't reached 1.0 yet, keeps introducing breaking changes, and there's relatively little of it on the internet for models to learn from. Claude writes bad Zig. Rust, by contrast, is one of the better-represented systems languages in training data, and the borrow checker's strictness actually plays to an LLM's strengths—the compiler catches what the model misses.

So Bun's founder Jared made the call in early May: port all 535,000 lines of Zig to Rust.

How You Actually Do This With AI

The methodology here is worth examining on its own terms, because "we used AI to do a big rewrite" is a claim that covers everything from thoughtful orchestration to spectacular disaster.

Bun's approach had a few features that distinguish it from cargo-cult AI usage. Before any agents wrote a line of code, Claude spent hours studying the existing codebase and produced a porting guide—essentially a translation spec. Then they ran a workflow that traced the lifetime of every struct field into a spreadsheet, documenting what Fireship's video describes as "years of tribal knowledge about who frees what and when." That kind of explicit knowledge capture is the thing most teams skip and then regret.

The review structure is also worth noting. Every agent doing implementation work was paired with two adversarial reviewer agents running in separate context windows, whose explicit instruction was to assume the code was wrong and find out why. That's not a foolproof quality gate, but it's a real one—it bakes skepticism into the pipeline rather than assuming the implementer got it right.

Whether this methodology is reproducible at other organizations, with different codebases and different resource profiles, is a genuinely open question. Bun had the advantage of owning the compute, a founder who understood the codebase deeply enough to specify the porting guide, and a tight feedback loop from Claude Code's production usage. Those aren't conditions you can assume.

The Zig Response, and What's Actually Buried in It

Andrew Kelley, Zig's creator, responded publicly—and Fireship's coverage is fair in noting that the response contained both legitimate technical criticism and some personal heat that muddied the former.

The technical points deserve to stand on their own: Kelley argues that the performance improvements Bun claimed largely came from enabling link-time optimization, which Zig has supported all along. The binary size reduction, he contends, was unrelated to the language switch. And he flags that Bun's benchmarks notably omit compile times—a category where Zig has a significant advantage over Rust. These are specific, falsifiable claims, and they haven't been conclusively rebutted in public as of this writing.

Kelley also acknowledged something that most language creators would quietly bury: the Zig team had apparently been using Bun's codebase internally as an example of how not to write Zig. That's a remarkable admission, and it cuts in two directions simultaneously. On one hand, it validates some of Kelley's technical criticism—if Bun was misusing Zig's idioms, the language's limitations may have been less of a factor than claimed. On the other hand, if your most famous user's codebase is your internal cautionary tale and you never said so publicly, the communication failure there belongs to more than one party.

The personal commentary—references to Jared's background, his "beginner energy," secondhand reports about his management style—is harder to evaluate and easier to dismiss. That kind of thing lands differently coming from a compiler engineer with institutional standing versus a random forum post, but it doesn't strengthen the technical case.

As Fireship put it: "Zig lost its most famous user. Andrew lost his cool. And Jared got publicly diagnosed with beginner energy by a compiler engineer." Nobody walks away from this with an unscuffed reputation.

The Bigger Question This Opens

The Bun rewrite is interesting on its technical merits. But the thing that's going to matter longer is the question it surfaces about AI-era language selection.

We're entering a period where AI tooling isn't just a workflow accelerator—it's becoming a genuine factor in the sustainability of a language ecosystem. Zig's principled stance against LLM-generated contributions is coherent and defensible on quality grounds. But it also means that any organization whose development increasingly runs on AI coding assistants faces a real friction cost with Zig that doesn't exist with Rust, Go, or Python. Whether that's a problem Zig should solve, or a constraint its users should accept, is a genuine values question about what kind of ecosystem you're building and for whom.

Bun's answer was to change languages. Other Zig users will answer differently. But the question isn't going away, and it's not unique to Zig—any language that's LLM-hostile, training-data-sparse, or rapidly pre-1.0 evolving is going to feel this gravity.

Spolsky's essay was right that rewrites are expensive and risky. It wasn't written for a world where 64 parallel agents can do in 11 days what used to take three years. What "the single worst strategic mistake" looks like in that world is still being worked out.

By Dev Kapoor, Open Source & Developer Communities Correspondent