AI Agents Rewrote All of Bun in 11 Days: The Verification Problem Now Defines Software

When Bun 1.4 shipped as a stable release on August 20, 2026, it became the first general-purpose JavaScript runtime whose entire core codebase had been rewritten not by a team of engineers but by a coordinated swarm of AI agents — and most of the developers already running it had no idea. The code had been silently live in Claude Code since June 17, after Bun creator Jarred Sumner used approximately 64 parallel instances of a pre-release version of Anthropic's Fable model to migrate roughly 960,000 lines of Zig to Rust in eleven days. Paul Dix, founder and CTO of InfluxData, read Sumner's account and on August 25 published an essay on his website arguing that the Bun 1.4 rewrite marks a structural turning point: the act of writing code manually and having humans review it, Dix wrote, is "headed for extinction."

The essay has attracted attention largely for its sweeping thesis, but the more precise and practically important story is in the engineering. The Bun rewrite did not succeed because the AI was capable enough to write excellent Rust. It succeeded because Sumner built a verification architecture that made quality measurable without requiring any human to read the code.

The Forcing Function: A Language Policy and a Bug List

Anthropic acquired Bun from Oven.sh in December 2025, at which point Bun's codebase was largely written in Zig — a systems programming language that offers fine-grained manual memory control but has a comparatively small developer community. After the acquisition, an additional organizational reality surfaced: Zig's Software Foundation maintains an explicit policy in its Code of Conduct prohibiting AI-generated code contributions, making it structurally difficult for an AI company whose engineers rely on AI coding agents to maintain a large Zig codebase.

The language switch had a second motivation that Sumner describes as primary: memory bugs. A large share of Bun's open issue list consisted of use-after-free errors, double-frees, and memory leaks in error paths — problems that Zig does not catch at compile time, and that Rust's ownership model turns into compiler errors by default. Sumner wrote that mixing garbage-collected and manually-managed memory was "an uncommon enough thing for software to need that no language really designs for it," and that he was tired of going to sleep worrying about crashes.

The Rust switch addressed both problems simultaneously: it offered compiler-enforced memory safety for a codebase prone to ownership-related bugs and aligned with Anthropic's organizational coding practices.

How the Two-Phase Agent Architecture Actually Worked

The rewrite ran in two distinct phases, with approximately 50 separate workflows executing over the eleven-day window.

Phase A was a "faithful logic capture" pass. Each .zig source file was converted to a corresponding .rs file by a Claude agent, prioritizing accurate logic translation over compilation correctness. At the start of Phase A, running cargo check on the resulting Rust codebase produced more than 16,000 compiler errors. The initial binary could not print a version number or execute any JavaScript. This was by design: Phase A did not need to produce code that compiled — only code that accurately reflected the Zig logic.

Phase B worked crate by crate. A Rust crate is roughly equivalent to a library or module unit. The agents worked sequentially through each crate, iterating until it both compiled and passed the relevant test subset. The critical enabling mechanism was Bun's existing test suite, which was written in TypeScript — a language independent of whether the runtime underneath was written in Zig or Rust. This made the tests a conformance oracle: an agent could port code, run the tests, read the failure output, modify the Rust, and re-run without any human interpreting the results. The loop was automated and self-correcting.

At peak concurrency, approximately 64 Claude instances ran in parallel across four separate worktrees, with 16 agents per workflow. Sumner structured adversarial agent pairs — one agent generating code, a second reviewing it, flagging issues it detected independently. He also implemented dynamic workflows in which agents wrote execution plans for other agents, allowing the orchestration layer itself to adapt as the port progressed. Sumner described himself primarily as monitoring the workflow outputs, reading summaries, and occasionally prompting the system to adjust its approach — supervising a process rather than reviewing individual code changes.

The total pre-merge token consumption, per Sumner's official account: 5.9 billion uncached input tokens, 690 million output tokens, and 72 billion cached input token reads. At API pricing, that translates to roughly $165,000. Because Anthropic employees do not pay for internal token usage, the effective out-of-pocket cost to the project was zero.

The 13,000 Unsafe Block Debt

The test pass rate at merge time was 100% across all six supported platforms — Linux x64, Linux arm64, macOS x64, macOS arm64, Windows x64, and Windows arm64 — with zero tests skipped or deleted. But the figure that defines the long-term significance of the rewrite is not the pass rate. It is approximately 13,000: the number of unsafe keywords in the new Rust codebase at the time of writing, covering roughly 27,000 lines out of 780,000 total Rust lines, according to Sumner.

In Rust, unsafe is a keyword that tells the compiler to suspend its memory-safety guarantees at that site. Code inside an unsafe block can perform raw pointer operations, dereference arbitrary memory, and execute actions that could produce use-after-free errors or other undefined behavior — precisely the class of bugs that motivated the switch away from Zig. Every such block in the Bun codebase is a location where Rust's safety guarantees do not apply and where a human auditor will eventually need to verify that the operations are correct.

When the agent could not cleanly satisfy Rust's ownership model — typically because Zig's manual allocation patterns don't map to a clean ownership graph — it fell back to unsafe, preserving correctness while deferring the deeper architectural work. The result passes tests but is not memory-safe at those sites. Sumner has acknowledged the debt publicly and maintains an unsafe audit tracker, noting that about 78% of the unsafe blocks are a single line, often a pointer originating from C++ or a call into a C library.

Read more: Verification, not capability, is the bottleneck holding agentic AI back

Already Running on Millions of Machines Before the Public Release

The public stable release of Bun 1.4 on August 20 followed several months of post-merge refinement. During that period, agents continued to run improvement loops — catching bugs surfaced by usage, fixing them, and re-testing. The team also completed eleven rounds of security review and launched 24/7 coverage-guided fuzzing of every parser in Bun — JavaScript, TypeScript, JSX, CSS, JSON5, and more. The effective beta period was not a traditional staged rollout but a continuous agent-assisted hardening phase.

Months before the public release, independent technologist Simon Willison confirmed in July 2026 that the Rust-based Bun v1.4.0 was already embedded inside Claude Code v2.1.181 (released June 17) and later versions. Using forensic string inspection on the Claude Code binary, Willison identified 563 Rust source file paths and confirmed the embedded Bun version string matched 1.4.0 — a version that had not yet appeared as an official GitHub tag. Sumner's own summary of the silent deployment: "Startup got 10% faster on Linux but otherwise, barely anyone noticed. Boring is good."

Vercel added Bun 1.4 support to Vercel Functions on August 20, citing more than 2,900 resolved issues and over 1,500 additional Node.js compatibility tests passing compared to Bun 1.3.

Bun 1.4.1, a patch release addressing post-stable bugs, followed on September 4, 2026.

The Two-Tier Developer World Paul Dix Describes

Dix's essay is not primarily about Bun. It uses Bun as the clearest available evidence for an argument about access asymmetry in software development.

Anthropic and OpenAI developers, Dix writes, are currently operating in what amounts to "the near future" relative to everyone else. They have access to pre-release frontier models and near-unlimited token budgets. The Bun rewrite was done with a pre-release version of Fable — the Mythos-class model that the general market is accessing now in limited form. For the engineers who used it in May 2026 at no internal cost, the capability was qualitatively different from what any external developer could buy that week with a standard subscription.

The implication Dix draws is probabilistic rather than immediate. He does not argue that traditional software development ends next year. He expects another decade of companies continuing to ship software the conventional way — human-written, human-reviewed, PR by PR. Organizational inertia, accountability structures, and security review processes all favor the old approach. But the most productive teams, Dix argues, will increasingly direct AI agents, build verification systems, and review outputs rather than code. His own experience: using a weekly Fable allotment, he had agents complete a working Iceberg REST API integration for InfluxDB in 14 hours and an edge data replication system in 28 hours — features he describes as thousands of lines of implementation and test code that he supervised rather than wrote.

Mitchell Hashimoto, co-founder of HashiCorp, offered a complementary observation on the day the Bun PR merged: programming language choice "used to be LOCK IN" and is "increasingly not so." If a team can migrate a million-line codebase in eleven days, the cost of switching languages drops below the threshold where it functions as a strategic constraint. "Rust is expendable," Hashimoto wrote — useful until it is not, then replaceable at a pace no previous generation of software teams could sustain.

The Bottleneck Is Verification, Not Models

What most coverage of this event misframes is where the genuine difficulty resided. The Bun rewrite was not tractable because Fable was capable enough to write good Rust. The approximately 13,000 unsafe blocks confirm it did not write particularly good Rust. It was tractable because Bun happened to have a language-independent conformance suite.

If Bun's tests had been written in Zig, they would have been useless as an evaluation oracle for a Rust port. If Bun's tests had been sparse or incomplete, the zero-defect merge might have concealed many more correctness bugs. The quality of the output was bounded by the quality of the verification system, not by the quality of the AI. This is the structural conclusion that generalizes to organizations beyond Bun: teams that want to use coordinated agents at scale need to invest first in their testing and verification infrastructure. The harness — the suite of automated checks that can evaluate agent output without human code reading — is now the scarce engineering asset.

The software industry has historically treated testing as a cost center and code review as the primary quality gate. Bun's rewrite inverts that priority: with agents as primary authors, code review becomes impossible at the volumes they produce, and comprehensive automated testing becomes the only viable substitute.

Read more: Claude Code desktop gains Resume, ending the context-loss tax for developers

What Comes After 13,000 Unsafe Blocks

The near-term technical milestone to watch for the Bun project is not another language switch. It is whether Anthropic discloses a timeline for auditing and reducing the unsafe block count — and whether that reduction work will itself be done by human engineers or by a new generation of memory-safety-focused agents. The Rust ecosystem has produced tools for automated unsafe block detection and triage, and Anthropic's internal agent infrastructure gives it the capacity to run systematic audits at a scale that would be prohibitive for most organizations.

The longer arc is the one Dix sketches: as frontier model access becomes available at lower cost and higher throughput — he points to upcoming inference hardware announcements as signals — more development teams will operate in the mode Sumner used in May 2026. The constraint will remain verification. Every team that wants to use agents at scale will need to answer a prior question before it can benefit from the speed: does it have a conformance suite capable of evaluating output it cannot read?

Bun had that. It worked. The unsafe blocks are the bill that comes due when it works fast instead of well — and clearing that bill is the kind of sustained, methodical engineering work that may itself be the next argument for running it through an agent loop rather than a human one.