cd /news/artificial-intelligence/the-bun-rewrite-proves-never-rewrite… · home topics artificial-intelligence article
[ARTICLE · art-103402] src=dev.to ↗ pub= topic=artificial-intelligence verified=true sentiment=· neutral

The Bun rewrite proves 'never rewrite from scratch' was always a cope

In just 11 days, 64 AI agents successfully ported approximately 535,000 lines of Zig code to Rust for the Bun runtime, reducing memory usage from 6.7 GB to 609 MB in a benchmark of 2,000 parallel builds. The project, led by Bun creator Jarred Sumner, cost about $165,000 in API fees and generated over 6,600 commits, but also introduced 19 known issues and drew criticism from Zig creator Andrew Kelley, who called the code 'unreviewed slop.'

read4 min views5 publishedAug 19, 2026

In just 11 days, 64 AI agents successfully ported roughly 535,000 lines of Zig code to Rust. It didn't take 14 months, or a war room full of senior engineers. All it took was eleven days and a credit card. ## The rule that just cracked

In the year 2000, Joel Spolsky wrote that the rewrite from scratch is the "single worst strategic mistake" that any software company can make. That became gospel. Every experienced developer has used it when they disagree with a more junior person's suggestion to rewrite it. I know I have. 😅

The rationale behind it was quite simple: rewrites discard all the bug fixes that have been made over the years. All that messy code you hate is actually knowledge encoded in patches. On closer inspection, we can see that the intention behind the rule was not to establish a universal truth, but rather to limit expenses. ## Why the taboo existed

Rewriting was not allowed as it was a slow, manual process. It would literally take a team of humans re-deriving a decade of edge cases forever. It took 3 to 5 engineers 14 months to rewrite Turborepo from Go to Rust. That's the real cost of the dogma. Fourteen months of salary. Fourteen months where the old thing keeps shipping and the new thing ships nothing. That is the limitation we face. It's not about philosophy, it's about math. ## What Bun actually did

Jarred Sumner, the creator of Bun, aimed to eliminate memory leaks and use-after-free bugs, so he decided to rewrite the core of the runtime from Zig to Rust, where safety is enforced by the compiler. What he did next was point agents at it. There were approximately 50 automated workflows that were running all the time, 4 at a time at peak on separate Git worktrees. Every worktree had 16 Claude agents. The agents chewed through and fixed over 16,000 compiler errors on their own. The numbers are absurd in the good way:

→ 535,496 lines of Zig translated, over 1 million lines of Rust added

→ 6,778 commits, roughly 6.6 billion tokens, about $165,000 in API costs

→ 64 parallel agents at peak, 11 days start to finish

Compare that to Turborepo. $165K and eleven days versus five engineers and over a year. The rewrite constraint wasn't loosened, it was removed. ## The results are real, and messy

Don't worry, this product does exist. With Bun v1.4.0, a benchmark of 2,000 parallel builds showed a memory decrease from 6.7 GB to 609 MB. The port fixed 128 old bugs. Binary size was reduced by around 20% on Linux and Windows, with 2-5% higher HTTP throughput. However, we should not deceive ourselves by thinking that it is a perfect rewrite. The new version introduced 19 known issues and it still contains approximately 4% of unsafe Rust code. Andrew Kelley, the creator of Zig, even described the entire project as "unreviewed slop." This comment should not be dismissed. He has a point about review debt. It could be a risky business to run a million lines of code that no human has looked over carefully in a production system. ## So who's right

Here's the tension that keeps me up at night. Spolsky was right for his cost model. Kelley's right about the gap on reviews. And Bun's right about the fact that it ships and benchmarks better. All three scenarios can be simultaneously true. This is what makes the situation interesting, rather than a clear victory for one side or the other. In the past, it was believed that a rewrite implied that humans needed to re-create everything manually. This belief has now been proven incorrect for many types of codebases. The actual lesson to be learned is not that "one should always rewrite," but that most engineering rules are frozen cost estimates pretending to be sound advice. However, if you modify the curve of this cost, the advice is no longer valid. We need to review our sacred rules like we review dependencies. Some are load-bearing. Some are just habits no one has questioned since 2000. 🧊

The real question is not whether AI can refactor your code. It's whether the reason you rejected the idea in the past still stands. What is another rule in your stack that is a "never do this" but the math on why has changed?

── more in #artificial-intelligence 4 stories · sorted by recency
── more on @bun 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
Live at https://your-agent.zahid.host
Get free account → Pricing
from €0/mo · no card required
LIVE [news/the-bun-rewrite-prov…] indexed:0 read:4min 2026-08-19 ·