Moving 535,496 Lines to "Another Language" in 11 Days — What Bun's Full Rewrite Reveals About a New Use for Coding Agents, and the Aftertaste It Left
Bun was fully ported from Zig to Rust—530,000 lines in 11 days—by running multiple coding agents in parallel. We lay out the scale and motivation of the case, what it means for development teams, and the criticism that mass generation without review can't be trusted.
Jarred Sumner, the creator of the JavaScript/TypeScript runtime "Bun," has revealed that he fully rewrote Bun's internals from Zig to Rust. According to the account, a codebase on the order of 530,000 lines was ported over in 11 days by running multiple coding agents in parallel. This isn't merely a story about making things faster; it's drawing attention as a case study of just how far agents can carry a heavy task like "switching languages." At the same time, criticism has emerged over how the work was reviewed, so we'll lay out both sides.
The Scale Behind the Numbers
According to the blog post published by the creator, the scale and conditions of the rewrite are as follows. He explains that a task estimated at a year of manual effort was compressed into 11 days.
| Item | Details |
|---|---|
| Original code | 535,496 lines (Zig) |
| Scale of changes | About 1 million lines of diff, 6,502 commits |
| Duration | 11 days |
| Tools used | Claude Code dynamic workflows + Claude Fable 5 (prerelease) |
| Parallelism | Peak of roughly 64 instances split across 4 working trees |
| Generation speed | Peak of about 1,300 lines per minute |
| API cost | About $165,000 (5.9 billion input and 690 million output tokens, 72 billion cache reads) |
| Tests | About 60,000 tests and over 1.4 million assertions. 100% passing on all 6 platforms. No tests deleted or skipped |
Post-migration measurements show execution speed improved by 2–5%, the binary shrank by about 20%, and a measurable memory leak during dev server rebuilds was eliminated.
Why "Switch Languages" Instead of "Make It Faster"
The motivation for the rewrite wasn't performance but cutting bugs off at the root. Bun runs JavaScript, which frees memory automatically via garbage collection (GC), side by side with Zig, which manages memory manually. The creator explains that this combination had become a breeding ground for recurring defects such as "accessing already-freed memory (use-after-free)," "double frees," and "memory leaks at the boundaries of error handling." Mixing GC and manual management is a domain that language design struggles to anticipate, so the storyline goes, he decided to rebuild this layer using Rust's ownership model.
What Changes for Development Teams
What this case shows is that our sense of time around "full cross-language migration"—work that has been estimated in months to a year—may be shifting. The key point is that you can't just hand it off to an agent and be done.
- Parallelization and partitioning: Speed comes from splitting many agents across working trees and orchestrating them with dynamic workflows. Rather than making a single agent smarter, the design that pays off is running many of them in well-coordinated order.
- Tests decide whether a migration is viable: Over 1.4 million assertions form the foundation for judging that "nothing broke in the port." The thicker a codebase's test assets, the more realistic this kind of migration becomes.
- Costs are made visible: The roughly $165,000 price tag is discussed in comparison to a year of labor costs. You need to go in prepared to estimate the API charges you trade for that speed.
Conversely, this also draws a line: on codebases with thin tests or ambiguous specs, it's hard to bring the same approach over as-is.
Can We Say "If the Tests Pass, That's Enough"?
On the other hand, this approach has also drawn criticism. Zig's creator, Andrew Kelley, questioned the stance of shipping a million lines of code without human review, making a point along the lines of: "Are we to believe that a test suite that couldn't catch the bugs in the Zig code will catch the bugs in a million machine-generated lines?" If the tests were letting bugs in the original code slip through, how far can those same tests guarantee the safety of the generated code? That's the crux of the argument.
This is also a question that runs through all of development in the generative-AI era: "Who verifies AI-written code, and when?" Speed and cost reduction are clear benefits, but mass generation that skips the review step has drawn concerns like these—and it's reasonable to take it in with that measured tone. How you design the safety valves—test coverage, phased migration, auditable logs—looks likely to be the dividing line when trying the same approach at your own organization.
References: Rewriting Bun in Rust (Bun official blog) / Zig creator calls Bun's Claude Rust rewrite 'unreviewed slop' (The Register) / Rewriting Bun in Rust (Simon Willison) / Bun Rewrites 535K Lines of Zig to Rust in 11 Days Using Claude (Developers Digest)
