Anthropic rewrote a 500,000-line runtime in 11 days. Here's what that actually changes.
In December 2025, Anthropic acquired Bun, the fast all-in-one JavaScript runtime and toolchain. Bun's core was written in Zig by its creator, who prized the language's low-level control and speed. By mid-2026 that same codebase had grown to close to a million lines, and the bugs that came with rapid feature growth were becoming Bun's biggest liability — including a widely reported source-map bug in the bundler.
The fix the team chose was drastic: rewrite the entire runtime in Rust. Historically, a rewrite of that size is the kind of project teams avoid, because it usually means freezing feature work and bug fixes for the better part of a year while a small team painstakingly ports everything over.
Instead, Bun's creator ran the port using a fleet of parallel Claude agents working in an implementer/reviewer loop, with roughly three hours of his own time spent defining how the port should be structured. The rest was orchestration: agents split the codebase into around a hundred crates to keep compile times sane, worked through roughly sixteen thousand compiler errors that surfaced once cyclical dependencies were untangled, and used Bun's existing TypeScript test suite — deliberately independent of the runtime's implementation language — as the ground truth for correctness. The whole port took eleven days and landed with over ninety-nine percent test compatibility on Linux.
Why this matters beyond one company's tooling choice
The interesting part isn't that AI wrote a lot of code — it's the shape of the workflow. This wasn't "prompt a model and hope." It was closer to running a small army of reviewers against a fixed spec (an existing, language-agnostic test suite) and a fixed target (a mechanical, low-behavioral-change port). That combination — a clear success criterion plus parallel agents checking each other's work — is what made a normally year-long migration collapse into less than two weeks.
It also wasn't free of friction. Independent commentators flagged some of the generated pull requests as low-quality or hard to review given their size, and the creator of Zig publicly pushed back on the framing that Zig itself was the source of Bun's stability problems, arguing the real issue was engineering practice, not the language. Both things can be true at once: the mechanical transformation worked remarkably well, and the human judgment calls around scope, review, and what to trust the agents with still mattered enormously.
The takeaway for anyone building with AI right now
I think about this project the same way I think about the RAG systems and voice agents I build for clients: the model is rarely the bottleneck anymore. The bottleneck is whether you've given it a task with a verifiable success condition — a test suite, a source document, a structured API — versus asking it to freelance. Bun's rewrite worked because "does the existing test suite still pass" is an unambiguous, mechanically checkable question. The chatbots I build refuse to answer when a source document doesn't say something, for the same reason: constrain the task to something checkable, and the reliability follows.