Sumner explicitly frames the 11-day timeline as evidence of a new productivity regime, stating that a team of engineers with full context would have needed roughly a year for the same port. He credits Claude Fable 5 running under Claude Code, with close human monitoring, as the mechanism that made a solo rewrite of ~500k lines viable.
Philpax argues that fixing memory leaks, shrinking the binary 20%, and gaining 5% performance through a mechanical translation — with no algorithmic rework — reflects poorly on Zig as a systems language. If the destination language wins on stability and size without effort, that undercuts Zig's core value proposition for production workloads.
The editorial pushes back on the pile-on by noting Bun was born in 2021, when no LLM would have helped and Rust's async and FFI ergonomics were rougher. Zig gave Sumner the iteration speed to ship a viable JavaScript runtime at all — the fact that it can now be mechanically translated away doesn't retroactively erase that.
The synthesis emphasizes that Sumner did no algorithmic rework — the 5% speedup, 20% size reduction, and vanished memory leaks are side effects of moving to Rust's ownership model and toolchain, not of rethinking Bun. This reframes the story as a data point about language ecosystems rather than a claim that Bun got fundamentally better.
On July 8, 2026, Bun creator Jarred Sumner published *Rewriting Bun in Rust* — the story of porting Bun's ~500k-line Zig codebase to Rust in 11 days with a pre-release version of Claude Fable 5, working mostly solo. Bun was acquired by Anthropic in December 2025, and Sumner disclosed that he and much of the Bun team are now Anthropic employees. The rewrite landed with 100% of the existing test suite passing on all supported platforms.
The numbers Sumner reports are blunt: the Rust build is roughly 20% smaller on disk, about 5% faster on the standard Bun benchmarks, and — most damning for the old codebase — several long-standing memory leaks simply disappeared as artifacts of the port. There was no algorithmic rework. This was a translation, done by an LLM harness under human review, that happened to fix bugs on the way through.
Sumner's own framing is the quiet part out loud: "This Rust rewrite would've taken a team of engineers with full-context on the codebase a year of work. With 1 engineer using Fable & closely monitoring Claude Code, we went from start to 100% of the test suite passing on all platforms in 11 days." That is the sentence the industry is going to argue about for the rest of 2026.
Start with Zig. Bun was, for years, Zig's most visible production success story — the proof that a pre-1.0 systems language could power something people actually ran in CI. Sumner has been public about how much he liked the language. The fact that he still moved off it, and that a mechanical port to Rust *improved* stability and size without touching the design, is a harder review than any blog post could deliver. Commenter Philpax put it plainly on Hacker News: "it can't be good for Zig that a naive rewrite away from it fixed memory leaks, improved stability, shrunk binary size by 20%, and improved performance by 5%." The counter-argument — that Zig made Bun *possible* in 2021, when no LLM would have helped and Rust's async story was worse — is also true. Both things can be true. But going forward, the ecosystem gravity is one-directional.
Second, the AI angle. It is tempting, and wrong, to read this as "Claude rewrote a runtime." Read the piece and the community threads carefully and a different story emerges: Sumner had complete context on every line of the original, wrote a harness that fed the model bounded chunks, ran the full test suite as the oracle, and hand-reviewed diffs. Commenter didibus captured the mood: "Article did a decent job of showing discipline and care and human involvement to assert the automated rewrite was done diligently." The productivity multiplier here isn't the model — it's the maintainer with full context multiplied by the model. Give the same tool to an engineer who didn't build Bun and you get a broken port with a passing subset of tests and a very long tail of weird bugs.
Third, the economics. Commenter sashank_1509: "This is much cheaper than hiring a software engineering team. They could have hired me for 200k and I could not do this in a year." That's the honest read. A year of a mid-senior systems engineer is somewhere between $250k and $400k fully loaded. A pre-release Fable 5 seat, even at enterprise pricing, is not that. The delta is a rounding error against the schedule compression. For any project with a single maintainer who *knows the code cold*, the calculus on "should we rewrite in a better-supported language" just changed. It used to be a two-year decision. It is now an eleven-day decision.
Fourth, the not-so-fun part. User pier25's comment is the one worth taking home: "What has pushed me back to Node is seeing how amateurish the transition has been handled — no LTS support for the Zig version regarding CVEs, huge bugs..." The Zig-era Bun is now a legacy branch inside a company that would clearly rather not maintain it, and the messaging around what security support looks like during the cutover has been thin. If you ship Bun in production, that's the concrete risk to plan around — not whether Rust was the right target.
If you're already on Bun in production, don't do anything dramatic. Wait for a 1.4.x with at least one point release of bake time and a clear statement on Zig-branch CVE backports. The interesting question isn't stability of 1.4 — the test suite passes and the perf is slightly better — it's whether the small ecosystem of native modules and integrations that assumed the Zig ABI have followed the port cleanly. That's where the sharp edges will be for the next 60 days.
If you're a maintainer of a systems-language project sitting on Zig, Nim, Crystal, or any of the pre-1.0 alternatives to Rust and Go, this is the moment to be honest with yourself about ecosystem drift. The cost of switching languages used to be measured in engineer-years; it is now measured in engineer-weeks, provided one engineer has full context on the codebase. That collapses the strategic case for staying on a niche language purely because "a rewrite is too expensive." It isn't anymore. It might still be the wrong move — Zig's compile times, C interop, and low-level control are genuine — but "we can't afford to leave" is no longer a real answer.
If you're a hiring manager, the uncomfortable read: a maintainer with full context on a codebase, plus a strong agentic harness, is not equivalent to "one engineer" anymore for tasks like ports, refactors, and mechanical migrations. You are not going to backfill Jarred Sumner with two junior hires and Claude Code. The multiplier lives with the person who knows every line.
The next twelve months are going to produce a lot of "we rewrote X in Rust with Claude" posts, and most of them will not go this well, because most of them will not have a Sumner-shaped maintainer at the wheel. The interesting thing to watch isn't whether Bun 1.4 keeps its lead over Node and Deno — that's a benchmark race that doesn't move much. It's whether Anthropic starts publishing the *harness*, or a productized version of it, as a first-class tool for large-scale mechanical migrations. If they do, the market for greenfield systems languages gets much smaller very quickly. If they don't, this remains a compelling one-off. Either way, the calculus on "which language do we bet on" just got a new variable, and it's not one anyone had in their spreadsheet a year ago.
Personally I don't care that they used AI to rewrite Bun to Rust. Even if 1.4 is not good enough it will probably get better over time.What has pushed me back to Node is seeing how amateurish the transition has been handled.- No LTS support for the Zig version regarding CVEs etc.- Huge bugs lik
Article did a decent job of showing discipline and care and human involvement to assert the automated rewrite was done diligently, as best as it can be when using AI for it. I does make me feel a bit more comfortable about it.As an aside, I don't know why anyone would not want to use a memory-s
I think the important thing is this is much cheaper than hiring a software engineering team. They could have hired me for 200k and I could not do this in a year. I do not have the context, and I do not know Zig or Rust, perhaps I could pick it up in a month, but I would be extremely slow.Forgetting
Without commenting on Bun itself as a project, or the nature of the rewrite, it can't be good for Zig that a naive rewrite away from it fixed memory leaks, improved stability, shrunk binary size by 20%, and improved performance by 5%.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
It's very odd how quickly people fall back on emotional claims to attack this. Like we're engineers, if you can point at concrete problems with this rewrite I'd love to hear them. Obviously Jared is going to give the positive case, saying that he's doing that doesn't prove t