Andrej Karpathy

Code to the Moon

<h2>What happened</h2>
<p>Bun, the JavaScript runtime recently acquired by Anthropic, rewrote its entire codebase from Zig to Rust in 11 days. The rewrite covered roughly 535,000 lines of code, cost about $165,000 in API tokens, and was done almost entirely by 64 parallel Claude agents rather than engineers.</p>
<p>The result shipped as Bun v1.4.0: 128 bugs fixed, binary size down ~20%, memory usage dramatically reduced (one benchmark dropped from 6.7 GB to 609 MB for 2,000 parallel builds), and HTTP throughput up 2–5%.</p>
<h2>Why Zig had to go</h2>
<p>Bun creator Jarred Sumner’s explanation is straightforward: Zig has no RAII-style <code>Drop</code> semantics, which meant memory had to be managed manually. Bun runs on JavaScriptCore, which has its own garbage collector. Mixing the two led to persistent use-after-free bugs, double-frees, and memory leaks that kept coming back no matter how carefully the team tried to fix them.</p>
<p>Rust’s borrow checker and <code>Drop</code> trait turn those bugs into compile-time errors. The team didn’t want to enforce style guides or rely on discipline — they wanted the compiler to make the bugs impossible. That’s a reasonable engineering call.</p>
<p>After Anthropic’s acquisition, there was another practical factor: Zig has poor LLM tooling support compared to Rust, which matters when your parent company’s product is an AI coding assistant.</p>
<h2>How the rewrite actually worked</h2>
<p>The workflow was mechanical and test-driven. The team wrote a <code>PORTING.md</code> guide and a <code>LIFETIMES.tsv</code> file to document memory ownership patterns. Agents translated Zig files to Rust one at a time. Separate “adversarial review” agents — running in clean contexts with no memory of the original translation — checked the output for issues. The team then iterated through roughly 16,000 compiler errors until all unit tests passed (over one million assertions total).</p>
<p>The pace worked out to about 1,300 lines per minute. Total: 1.8 million lines of code across 6,502 commits in 11 days. The resulting Rust code is about 4% unsafe.</p>
<p>One detail worth noting, flagged by Mitchell Hashimoto: keeping review agents in separate, clean contexts matters. A single long compacting session accumulates biases from earlier decisions. Fresh context for verification is a genuinely useful pattern.</p>
<h2>The cost argument</h2>
<p>For comparison, Jared Palmer noted that rewriting Turborepo from JavaScript to Rust took 3–5 engineers about 14 months in 2023–2024. When you factor in salaries and opportunity cost, that’s several million dollars. The Bun rewrite at $165,000 is hard to argue with on pure economics, even if you’re skeptical about code quality.</p>
<p>Hashimoto put it bluntly: there’s no way a team of engineers paid a combined $165,000 over 11 days could have shipped the same scope.</p>
<h2>Andrew Kelley’s response</h2>
<p>Zig creator Andrew Kelley was not impressed. His public post called the AI-generated code “unreviewed slop” and argued that Bun’s memory bugs came from poor programming practices, not from Zig’s limitations. He also pointed out that the performance improvements Bun attributed to the language switch — particularly the LTO gains — were available in Zig all along and simply weren’t being used. Same with the binary size improvements.</p>
<p>Kelley also disclosed some history: Bun’s relationship with the Zig Software Foundation had been strained for a while. He described Bun’s codebase as having poor code quality and management culture, and said he viewed the split as a relief — Bun was a net liability for Zig’s reputation, in his view.</p>
<p>He also noted that Zig’s project policy rejects AI-generated contributions, which makes the “unreviewed slop” framing consistent with how he thinks about AI code generally.</p>
<h2>The legitimate criticisms</h2>
<p>Kelley’s technical points deserve to be taken seriously, even if the tone was sharp. If the LTO and binary size improvements were available in Zig and just weren’t being used, then attributing those gains to the language switch is misleading. That’s a fair criticism of how Bun’s blog post framed the results.</p>
<p>The broader question about AI-generated code quality is also real. Passing a test suite is necessary but not sufficient — tests don’t catch everything, and 535,000 lines of code that no human has carefully read is a genuine maintenance risk. The 4% unsafe Rust figure means there are still sections where the borrow checker isn’t protecting you.</p>
<p>On the other hand, the memory safety argument stands on its own. Rust’s type system genuinely does make a class of bugs impossible that Zig cannot prevent at compile time. That’s not a skill issue — it’s a language design difference.</p>
<h2>What’s actually interesting here</h2>
<p>The rewrite itself is probably less significant than the methodology. Large-scale AI-assisted rewrites with adversarial review agents, clean context separation, and test-suite verification as the acceptance criterion — that’s a workflow that will get reused. The economics are hard to ignore.</p>
<p>Whether the resulting code is maintainable long-term is a separate question that won’t be answered for a while. But the claim that rewrites have to be slow and expensive just took a serious hit.</p>


Collections

Bun's creator Jarred Sumner rewrote the entire Bun JavaScript runtime from Zig to Rust in 11 days using 64 parallel Claude Code AI agents. The motivation was structural memory safety: Zig lacks RAII-style Drop semantics, causing persistent use-after-free and double-free bugs that code review couldn't fix. The agent workflow used adversarial review agents, a PORTING.md guide, and a LIFETIMES.tsv file to preserve behavioral fidelity across the codebase. The rewrite cost ~$165,000 in API tokens — compared to an estimated one year of work for three engineers. Bun v1.4.0 ships the result: 128 bugs fixed, memory usage down from 6.7 GB to 609 MB in one benchmark, binary size reduced ~20%, and HTTP throughput up 2–5%.

Bun rewrote its runtime from Zig to Rust in 11 days using 64 parallel AI agents

<ul>
<li>128 bugs fixed</li>
<li>Binary size reduced ~20%</li>
<li>HTTP throughput up 2-5%</li>
</ul>
<p>You forgot the more important metric:</p>
<ul>
<li><strong>100% trust of the community lost</strong></li>
</ul>


<p>Calling Bun’s Zig struggles a “skill issue” might be accurate, but business demands pragmatism. Bun’s creator isn’t an industry veteran like Hashimoto; he’s a solo dev whose project exploded into the mainstream. Pivoting to Rust is the logical next step. It offers better infrastructure, mature ecosystem support, and a much larger pool of engineers to hire from than Zig.</p>


<p>Bun has amazing documentation and a great developer experience, but their focus has shifted from becoming the most reliable Node.js alternative to improving Claude Code. I’d love to see reliability and ecosystem compatibility remain the top priority.</p>


<p>I strongly appreciate both Agentic Coding and not having fear of refactoring such a codebase; though, the title and the kind of announcement ring an alarm bell in my mind. Boasting about using a bazillion agents is ok if you are doing experimental software, but Bun is used by a lot of developers, and I would imagine such an announcement to be more focused on features than on “look, we used a ton of agents while we were having drinks.”</p>


<p>Had a personal Bun+Hono project moved to Deno as soon as that was relased.</p>
<p>This move looks like an R&amp;D experiment by Anthropic than a serious engineering decision and Andrew Kelly’s remarks strengthens my opinion.</p>
