'Reviewed by Two Agents' Is a Governance Claim. Test It Like One.

Jarred Sumner ported 535,496 lines of Zig across 1,448 files to Rust in 11 days, May 3 to 14, 2026. His agents produced roughly a million lines of Rust across 6,502 commits, peaking near 1,300 lines per minute. No human read those lines the way a reviewer reads a pull request. Nobody could. So the Bun team substituted other evidence that the code was correct: two adversarial agent reviewers per task, a large existing test suite, and a workflow designed to fix the process that produced the code.

That substitution is the interesting part, and it is the part worth arguing about. When AI writes at a million lines, line-by-line human review stops being a control. Something has to stand in for it. What stands in becomes the governance claim, and a governance claim is only as strong as its track record of catching what it promised to catch.

Andrew Kelley, the creator of Zig, published a rebuttal that names the question underneath the drama. Set aside the language war. The real issue is whether the substitute evidence was ever strong enough to gate the output it was now being asked to gate.

One fact sharpens the claim. Bun became an Anthropic company in December 2025, Sumner and much of the Bun team work at Anthropic, and he ran much of the rewrite on a pre-release Claude model. The party that wrote the code, the vendor that supplied the model, the agents that reviewed it, and the organization vouching for the result are the same party. That does not make the work wrong. It means the evidence for correctness has to carry more weight, because no independent reviewer sits in the loop.

What Sumner actually built

The workflow was not careless. It was engineered, and the engineering deserves a fair account.

Sumner ran up to 64 Claude instances across four git worktrees. Each unit of work passed through a fixed pipeline: one implementer wrote the code, two adversarial reviewers received only the diff and were instructed to find bugs, and a fixer resolved what they found. Around 50 dynamic workflows coordinated the fleet. The run consumed 5.9 billion uncached input tokens and 690 million output tokens, roughly $165,000 at API pricing. After merge, the team found and fixed 19 regressions.

The motivation was real pain, not novelty seeking. Bun mixed JavaScriptCore’s garbage collection with manual Zig memory management, and the seam between the two produced recurring use-after-free bugs, double-frees, and leaks. In March, a bug in Bun’s own bundler emitted source maps when it had been told not to, leaking source. Rust’s ownership model closes off a class of those errors at compile time. The rewrite has a coherent technical rationale.

Two adversarial reviewers per diff is more scrutiny than most human teams apply to most pull requests. Fixing the process that generates code, rather than patching each output, is the correct instinct at scale. On its own terms, this was a rigorous operation.

The claim underneath the workflow

Kelley’s sharpest line is not about Rust. “The main issue here had nothing to do with the language features of Zig vs Rust,” he wrote, “and everything to do with the diverging value systems.” Then he stated the challenge directly: “The argument for shipping all the million lines of unreviewed code is that the test suite is good enough to catch everything. It’s not sufficient to catch bugs in Zig code but it is sufficient to catch bugs in [a] million lines of unreviewed slop?”

Read that as an engineering question rather than a taunt. The same test suite that governed the Zig codebase is now the primary gate on ten times more code, most of it never read by a human. The suite’s job did not change; the volume of what it must catch multiplied. For the suite to be a sufficient gate now, it would have had to be far stronger than its own history suggests.

Because we know its history. The reason the rewrite happened is that the Zig codebase kept shipping memory-corruption bugs and, once, leaked its own source. Those defects escaped the exact verification system now being trusted to certify a million unread lines. Kelley also reports the Bun team told the Zig team they “were not fuzzing anything,” which removes one of the strongest tools a suite could use to find memory bugs at volume.

A verification system’s credibility is not measured by how many assertions it contains. It is measured by the defects that historically got past it. Bun’s own bug record is the evidence about that suite, and the record says the suite let real, serious bugs through.

Two adversarial reviewers is a claim too

The reviewer setup has the same property. Giving two agents only the diff and telling them to find bugs is a strong-sounding design. Whether it is actually strong is an empirical question with an empirical answer: on a labeled set of known past defects, what fraction would these two reviewers have caught?

Nobody ran that test before trusting the reviewers at volume. We covered why that matters in why agents can game the tests that grade them: a verification signal that has never been measured against real escaped defects is a claim wearing the costume of a control. Two reviewers looking at a diff with no whole-program context share blind spots. Memory-lifetime bugs and use-after-free are exactly the class that a diff-scoped reviewer, with no view of the object’s full lifecycle, is worst positioned to see. Those are also the bugs that drove the rewrite. The reviewers were strongest at catching local mistakes and weakest at catching the category the project most needed caught.

This is how verification debt accrues. Each unmeasured gate feels like coverage. Stack enough of them and the system reports high confidence built entirely on untested proxies. The 19 regressions found after merge are the visible portion. The invisible portion is whatever the suite and the reviewers were structurally unable to catch, which by definition does not show up in the post-merge count.

The test to run before you trust the gate

None of this says Sumner was reckless or that AI rewrites are illegitimate. It says something narrower and more useful. Before a verification system becomes the sole gate on AI-generated code at volume, establish its historical defect-escape rate on that codebase. The rigor of the process is not the question. The proven strength of the thing the process leans on is the question.

Do this before your next large AI-assisted change:

Pull the defect history of the suite you are about to trust. List the last 20 to 50 production bugs. For each, ask a plain question: would the current test suite have caught this before release? Sort into caught and escaped. The escaped pile is your real coverage picture, and it is usually worse than the assertion count implies.

Characterize the escaped bugs. If they cluster in a category, memory lifetime, concurrency, and cross-module state are the usual clusters, then that category is your gate’s structural blind spot. Generating ten times more code does not shrink that blind spot. It feeds it.

Score your reviewers against labeled defects. Take known past bugs, hand your agent reviewers the diffs that introduced them, and measure the catch rate. A reviewer that catches 90% of style issues and 30% of lifetime bugs is not a general gate. It is a style gate with a lifetime blind spot, and you should know which one you have before you ship a million lines behind it.

Then decide what the gate can carry. A suite with a known 30% escape rate on memory bugs can gate code that has few memory-safety concerns. It cannot gate a million lines of manual memory management on its own. The strength of the evidence has to match the risk of the code it certifies.

Sumner’s process was genuinely more rigorous than most teams manage. Kelley’s point survives that fact: rigor applied to an unproven suite is still unproven. The suite that let source leak in March is the same suite that certified a million lines in May. Before you let a verification system gate AI output at volume, make it show its record. A gate you have never tested is a hope with a green checkmark.

---

This analysis synthesizes Zig creator calls Bun’s Claude Rust rewrite ‘unreviewed slop’ (The Register, July 2026), My Thoughts on the Bun Rust Rewrite (Andrew Kelley, July 2026), Rewriting Bun in Rust (Bun, July 2026)…

Victorino Group helps enterprises measure whether their verification systems are strong enough to gate AI-generated code. Let’s talk.