On 8 July, Bun's creator Jarred Sumner published the numbers behind a piece of work most engineering teams would have written off as impossible. A Rust rewrite of the JavaScript runtime, a codebase of roughly a million lines originally written in Zig, had been carried through in 11 days across 6,502 commits, driven by as many as 64 AI coding agents running in parallel. The token bill came to about $165,000 at published API pricing.
The comparison that travelled furthest was the counterfactual: the same work, done conventionally, was put at around a year for three engineers. Within a day, that post, a rival Postgres rewrite and a pointed rebuttal from the creator of Zig were sitting within 30 points of each other at the top of Hacker News. The argument that followed is not really about one runtime. It is about what happens when the cost of rewriting foundational software falls by two orders of magnitude.
What Actually Happened Inside the Rewrite
The raw figures behind the Rust rewrite are unusual enough to be worth stating plainly. The run consumed about 5.9 billion uncached input tokens and 690 million output tokens. Agents worked in parallel rather than in sequence, which is why the wall-clock time collapsed while the total work did not. The output was checked continuously against Bun's own test suite, which carries in the region of a million assertions.
That test suite is the load-bearing part of the story. A machine-driven port has no judgement about intent; it has only a specification it can execute. Bun happened to have one of the most demanding executable specifications in the JavaScript ecosystem, built up over four years of chasing Node.js compatibility. The published figure for the Rust build is 99.8% test compatibility on Linux x64 with glibc.
What that figure does not mean is that the Rust build is what you install today. It remains experimental, limited to a single platform, and is not the default binary. Bun's stable 1.3.x line continues to be produced from the Zig codebase. According to the July account, the rewritten code did reach users inside Claude Code v2.1.181 on 17 June, which is a meaningful production signal, but it is not the same as a general release.
Why a Working Runtime Would Leave Zig at All
Three reasons were given, and none of them is about raw speed. Both languages compile to native code without a garbage collector, and the expectation set out publicly was that the Rust build would land within a few percent of the Zig one.
The first reason is people. Rust has a far larger contributor pool than Zig, and for a project that wants outside patches, the size of the hiring and contribution funnel is a design constraint like any other. The second is maintainability at scale, where Rust's ownership model and type system move a class of errors from runtime to compile time. The third is institutional. Bun was acquired by Anthropic in December 2025, and Claude Code ships as a Bun executable to millions of users. Sumner's summary of the stakes was blunt: if Bun breaks, Claude Code breaks. That acquisition post also committed to Bun staying open source and MIT-licensed, and to continued development in public on GitHub.
Andrew Kelley, who created Zig, published a rebuttal the following day. His central objection was one of review capacity rather than language preference: shipping around a million lines of machine-generated code that no human has read is a different risk profile from shipping a million lines that a team wrote and reviewed. He also questioned how consistently the test suite had been applied. It is a fair challenge, and the honest answer is that nobody yet has a good method for reviewing code at that volume.
Postgres Got the Same Treatment, and the Fuzzers Answered
The second project made the trade-off legible. pgrust, a rewrite of PostgreSQL in Rust started in early April 2026 by Michael Malis and Jason Seibel, took a similar route: an initial from-scratch attempt, then a switch in June to automated C-to-Rust conversion followed by AI-driven rewriting into safer Rust.
On 25 June the project announced it was passing 100% of PostgreSQL 18.3's 46,000-plus regression tests, along with the isolation tests, and could boot from an existing Postgres data directory. For a database, that is a genuinely hard bar to clear.
Then Andreas Seltenreich, who wrote the SQLsmith fuzzer, pointed it at the result on 9 July. Within days it had produced a segmentation fault from a single line of SQL, SELECT numrange_subdiff(1,1);, an internal error on a MERGE statement, several broken planner invariants and a missing validation check on bytea literals. Recovery tests stood at 34 of 47. Published benchmarks were similarly sobering: roughly 728 transactions per second against 6,365 for stock PostgreSQL 18.4, initialisation about eleven times slower, and out-of-memory kills under sustained load. The codebase carries 2,664 unsafe blocks and 1,835 unsafe functions, which is a reminder that a mechanical translation into Rust does not automatically produce memory-safe Rust.
The Kernel Settled the Language Question Years Earlier
Lost in the noise is that the underlying question was answered some time ago, and quietly. At the Linux kernel Maintainers Summit in December 2025, the consensus was that Rust in the kernel is no longer experimental. Jonathan Corbet, reporting the outcome, framed it as the experiment being done and having succeeded. Rust support had been merged in late 2022 and grown steadily since; the summit simply removed the label.
That path took three years of human review, subsystem by subsystem, with maintainers arguing over each interface. It is the opposite of an 11-day sprint, and it is why the kernel result is durable. The language was never the contested part. The contested part is how fast a codebase can move into it and still be trusted.
What the Numbers Do and Do Not Prove
Read carefully, the Rust rewrite of Bun and its Postgres counterpart support a narrower claim than the headlines suggest. They show that where a codebase has a large, executable specification, an agent fleet can now translate it between languages in days rather than years, at a cost that a single well-funded individual could cover. That is a real and significant capability shift.
They do not show that the output is production-ready. pgrust's fuzzing results demonstrate exactly what a regression suite does not catch: it verifies the behaviour someone thought to write a test for, not the behaviour nobody imagined. Bun's own position, keeping stable releases on Zig while the Rust build matures, is the more instructive signal. The people closest to the work are treating it as promising and unfinished, which is the correct reading.
There is also a maintenance question nobody has answered yet. A codebase produced in 11 days still has to be understood by whoever fixes it at 3am two years from now. Reviewability is not a nice-to-have in systems software; it is the mechanism by which trust is accumulated.
What This Changes for Small Teams
At MW3.biz, we read this as a democratisation story with an asterisk. Capability that used to require a funded team is now reachable by two people with a credit card and a good test suite, and that is the direction we consistently want technology to move. We also think the asterisk matters: the projects that succeeded here were the ones that had already invested years in tests, and that investment is not something an agent can retrofit. Our view is that wider access to this kind of tooling is worth having, and that the honest way to advocate for it is to report the fuzzer results alongside the commit counts.
The practical takeaway for a small team is unglamorous. The leverage is in the specification, not the model. If your project has a thin test suite, an agent-driven refactor will produce something that compiles, passes what little you wrote, and fails in the field. If it has a thorough one, the same tooling becomes a genuine force multiplier, in the same way open-weight models have widened access to everyday coding work. Spending a fortnight on test coverage is now a better investment than spending it on the refactor itself.
Neither rewrite is finished, and both are worth watching rather than copying. The current state of the Bun port and the open issue list on pgrust will say more over the next six months than any single benchmark does today. What has already changed is the price of trying.
