The rewrite nobody wanted to do
Bun is one of the most-downloaded JavaScript runtimes on the planet, with around 22 million monthly downloads, used by Claude Code and OpenCode for their toolchain and supported first-party by Vercel, Railway, and DigitalOcean. The runtime was written in Zig. The team decided to rewrite it in Rust. By the standards of how rewrites usually go, the project should have taken years. It didn't.
Jarred Sumner, Bun's creator, told the Pragmatic Engineer podcast that the rewrite happened in a fraction of the time rewrites normally take, and the tool that made it possible was a piece of AI infrastructure called Fable. Fable was briefly offline due to US export controls on AI tooling, but the situation has been resolved and the tool is now available globally.
Why rewrite at all
Bun ran into a class of bugs that Zig is structurally bad at preventing. Memory-related bugs. Memory leaks, crashes from memory corruption, heap-out-of-bounds writes, the kind of failure that wakes a runtime maintainer up at 2am. Bun had patched the Zig compiler to reduce these, and added end-to-end memory leak tests, and the bug list still felt bad. Sumner: "Our bugfix list felt bad and I was tired of going to sleep worrying about crashes in Bun. I don't blame Zig for that."
Mixing garbage-collected values with manually-managed memory is uncommon enough that no language really designs for it, and Bun is exactly that combination. Rust's borrow checker makes the use-after-free, double-free, and forgot-to-free cases into compiler errors rather than late-night debugging sessions. As Sumner put it: compiler errors are a better feedback loop than a style guide.
The reason rewrites usually fail
There are two problems with rewrites. They take too long, and they take waaaay too long. A dev who has done rewrites knows the pattern. Nine months in, there's another six months to go. Two years in, the rewrite is at 60% feature parity and the original is three years behind on new features. The rewrite never catches up. The team gives up. The original accumulates patches on top of the original architecture for another two years, and the rewrite branch rots.
The reason this doesn't happen to Bun is that Fable wasn't asked to do the rewrite. Fable was asked to translate, and a senior engineer was sitting next to the output the entire time, making the calls that only a senior engineer can make. The AI handled the mechanical mapping of Zig idioms to Rust idioms, the import graph rewiring, the type-system translation. The human handled the parts that don't have a one-to-one mapping, the parts where the original implementation was already a clever trick, the parts where the rewrite needs to introduce a new abstraction that the original was getting away with not having.
What this means for the rewrite graveyard
The Bun case is the first credible data point in a long time that suggests rewrites don't have to be the multi-year projects they used to be. The pattern that worked was: a tool built for one specific job, used in tight loops with a senior engineer making every call, against a codebase that the senior engineer knows intimately. None of those conditions are trivial. The team rewriting an unfamiliar legacy system from scratch in a new language will not get the same result.
The honest reading is that AI-assisted rewrites are now possible when the human is the bottleneck and the AI is the accelerator, and they are still impossible when the human is also the bottleneck on understanding what the system is supposed to do. The order matters. The rewrite is not the place to learn the system. By the time you start the rewrite, you should already know the system better than the AI does.