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?
Top comments (2)
It's kinda become what I've been doing lately... ALOT... Eg. MCP, slow and stupid using JSON and Node for high-speed tool calling, so I rewrote to self-hosting Rust, using a custom format for the tooling (actually simpler, deterministic triples, so it makes more sense to LLMs reading it and to users writing it). Result is zero-allocation and exponentially faster tool calling, while lowering token usage and improving LLM signal to noise.
I hated how slow Playwright was for LLMs using a browser, so I wrote MCP-Lite to replace it, using the AOM instead of DOM, cheaper, faster, better signal to noise.
I saw Inno Setup costs money if you use it commercially, so I wrote my own installer in Rust, made it cross-platform, tried adding MSI support using the rust-msi crate, but it's actually not windows MSI compliant, so I wrote my own msi crate.
I love Dwarf Fortress, but it's dated and runs slow, so I rewrote it in Rust and decided I'm gunna expand beyond the original, currently hovering around 4.5m LOC
I didnt like VS Code running Electron, it seemed wasteful to me, so I wrote my own in Rust and decided to make it fully tailored to agentic coding.
I didnt like the bloat and incompatibility of chromium for LLMs, so I wrote my own browser in rust, purely for agentic browsing.
I saw Temporal made a post about their 8ft keyboard, thought it looked like a cool company to work for, so in order to catch their attention, I rewrote Temporal from scratch in Rust, optimizing it as I go, expanded it to cover the major competitors (DBOS and ReState) too, added migration tooling and auto-implement tooling, along with all the optimizations I discovered along the way from the other projects.
I didnt like how bloated linux was for hosting server processes on cloud, so I decided to write my own OS from scratch, integrate a custom quantized qwen 2.5 coder 0.5b in its kernel to act as an integrated assistant, so you dont have to bother with remembering syntax. Along with that, build a full custom programming language, model harness, quantization method, JIT compiler and file transfer protocol.
And that's not even all š so the old saying of never rewrite, is being eclipsed by 'the great rewrite'. It's now so easy to fix old bloated, inconsistent, patchwork slow systems, that took 20+ years to build. If you have access to the source, or atleast sufficient enough documentation, you can rewrite it and it will be faster, more secure and more reliable. Not saying it'll be perfect day 1, but it definitely wont take 20+ years to get it stable either...
The sentence I'd frame from this: "most engineering rules are frozen cost
estimates pretending to be sound advice." We hit a small-scale version of
exactly that this week ā two textbook rules we'd never questioned (stemming
helps search; sophisticated ranking beats a crude ratio), and measurement
killed both in one afternoon. The rules weren't wrong when they froze; the
inputs changed.
One question about the Bun case, because I think it decides how far the
lesson generalizes: Spolsky's rule protected knowledge encoded in patches.
Agents can only preserve knowledge encoded in checks ā tests, benchmarks,
the compiler. The 128 old bugs fixed and 19 new issues introduced look like
exactly the delta between those two encodings. So is the real precondition
for an AI rewrite not the $165k, but how much of the old system's decade of
edge cases exists in executable form? "Never rewrite" wouldn't become
"rewrite freely" ā it becomes "a rewrite is exactly as safe as your test
suite is representative."
And that second thing is measurable, but almost nobody measures it. We
learned this the humiliating way last week: our own quality benchmark said
92.3%, and against real data the same system scored 5%. The tests passed ā
they just didn't look like reality. I'd love to know Bun's equivalent
number: how much of the old Zig behavior was actually pinned down before 64
agents started translating. That number, not the token bill, seems like the
one future rewrites should be budgeted around.