The Harness Was the Product: Lessons from Bun's 11-Day Rust Rewrite

Bun ported 535,496 lines of Zig to Rust in 11 days, driven by 64 Claude agents that produced 6,502 commits. That number is the one everyone quotes. The number that matters more is 3: the trial run started with three files. The full 1,448 came later. Jarred Sumner’s write-up, Rewriting Bun in Rust, reads like a throughput story. It is actually a harness story, and the harness is the part you can copy.

One disclosure up front so you can weight the source. Bun became an Anthropic company in December 2025, Sumner and much of the Bun team now work at Anthropic, and he used a pre-release Claude Fable 5 for much of the rewrite. Treat the specific model and the marketing framing with the skepticism they deserve. The four operational moves underneath, though, do not depend on which model ran them. They are orchestration, and orchestration is portable.

Skeptics were loud, and their objections are worth keeping in view. On the Hacker News thread about the porting branch, commenters invoked Joel Spolsky’s “Things You Should Never Do” (rule one: never rewrite from scratch), raised Second System Syndrome, and pointed out that Zig had recently rejected a Bun contribution under a no-AI-code policy. Sumner himself called the branch highly experimental, with, in his words, a “very high chance all this code gets thrown out.” Hold that tension. The engineering can be excellent and the outcome can still be uncertain. What follows credits the mechanics without buying the verdict.

If you want the companion question, whether “reviewed by two agents” is actually enough to trust the output, we argue that separately in reviewed by two agents is a claim. This piece covers the mechanics of running the fleet. Whether the fleet was right is a separate question.

Move 1: Encode shared context as durable files

Sixty-four agents cannot hold a conversation. They can read the same file. That distinction is the whole first move.

Bun’s prep produced two artifacts. The first was PORTING.md, a pattern-mapping document distilled from roughly three hours of conversation with Claude about how each Zig idiom should become a Rust idiom. The second was LIFETIMES.tsv, generated by a dynamic workflow that read every struct field in every file, traced the control flow, proposed a Rust lifetime for each case, had two adversarial review agents check the proposal, and serialized the accepted result into a table other agents could load.

The pattern here is context-as-artifact, which we have written about before in your harness, your memory. A parallel fleet has no shared working memory. Each agent boots cold, does one unit of work, and dies. If the ground truth for “how do we map a tagged union” lives in one agent’s context window, the other 63 agents will each invent their own answer, and you get 64 dialects of Rust. Writing that decision to PORTING.md collapses 64 guesses into one lookup.

LIFETIMES.tsv is the sharper example, because lifetimes are exactly where a Rust port goes wrong. Rather than let each agent reason about ownership from scratch (slow, and inconsistent across agents), the prep phase did the reasoning once, adversarially, and froze the answer into a row per case. An implementing agent no longer decides a lifetime. It reads one.

The copyable rule: before you scale a fleet, ask what every agent needs to agree on, and write that agreement to a file the agents read on boot. The artifact has to be durable and inspectable, something you can diff, review, and regenerate. A prompt does not qualify.

Move 2: De-risk with a trial run before you scale

The full job was 1,448 files. The first run was 3.

This is the move most teams skip, because three files feels like a rounding error against fifteen hundred. It is the cheapest de-risking you will ever buy. On those three files, Bun ran the exact loop it intended to run at scale: one implementer agent wrote the .rs file, two adversarial reviewer agents checked that it matched the original .zig behavior and honored PORTING.md plus LIFETIMES.tsv, and a fixer agent applied the accepted suggestions. Four roles, one file, run to completion before anything scaled.

A trial run answers questions a prompt cannot. Does the reviewer catch real behavioral drift, or does it rubber-stamp? Does the fixer apply suggestions cleanly, or does it introduce new breakage? Do the two artifacts actually contain what the implementer needs, or is there a gap you only see under load? Three files surface these answers for the price of three files. Fifteen hundred files surface them for the price of fifteen hundred.

The economics are stark. A loop defect found on file 3 costs you three files of rework. The same defect found on file 900 has already contaminated 897 commits. Scaling an unproven loop multiplies the blast radius of every flaw the loop contains, and saves no time doing it.

The copyable rule: never run a fleet at full width on its first execution. Pick the smallest N that exercises the complete loop, run it to done, inspect the output by hand, and only then widen. The trial run saves far more than it costs: it separates debugging a loop from debugging that loop’s output at fifteen-hundred-file scale.

Move 3: Constrain the operating environment, and let failure teach you the constraints

The full run’s first attempt failed, and the failure was not in the code. Parallel agents, each trying to manage its own working state, ran git stash, git stash pop, and a hard git reset. Those commands are global. One agent’s hard reset erased another agent’s uncommitted work. The agents were stepping on each other through the version control system itself.

The fix went into the workflow, not the code. Sumner forbade any non-atomic git command: no stash, no reset, no operation that mutates shared state in a way another agent can observe mid-flight. He also banned cargo and other slow commands from the agent loop, because a slow command is a long window during which state can drift and agents can collide. The operating environment got narrower, on purpose, and the collisions stopped.

This is the move that only failure can teach, and it maps directly to a hazard we catalogued in the data floor of the agent containment stack: agents corrupt shared substrate through operations that are perfectly legal in isolation. A human running git stash is fine, because a human runs one at a time. Sixty-four agents running git stash concurrently is a data-loss event. The command was never the problem in a single-actor world. Concurrency made it one.

The copyable rule: enumerate every operation in your agent loop that touches shared state non-atomically, and forbid the ones that can collide. You will not predict all of them in advance. Run the fleet, watch it corrupt itself, read the failure, and write the constraint. The constraints discovered by failure are more valuable than the ones you guessed, because they are the ones that actually bite.

Move 4: Shard by worktree to parallelize without collision

Once atomic-only git was enforced, throughput still needed structure. Bun sharded the work into four separate git worktrees, each running 16 Claude instances that committed and pushed files independently. Four lanes, sixteen agents per lane, sixty-four in total, each committing atomically into its own worktree.

Worktree sharding is the physical expression of the same principle behind the atomic-commit rule: reduce the surface where agents contend. Sixty-four agents in one working directory contend on every file operation. Sixteen agents across four worktrees contend far less, because most of their work is isolated to their own checkout, and the shared surface is a push, which the version control system already knows how to serialize. This is what an agent harness does at the infrastructure layer: it shapes the environment so parallelism is safe by construction, not by hope.

At peak the fleet moved roughly 1,300 lines per minute, every line reviewed by two separate adversarial reviewers plus a fix round before commit. And here is the line Sumner is honest about: at the end of those 6,502 commits, “absolutely none of it worked yet.” Compilation and correctness were still ahead. The harness delivered throughput. Throughput is not the same as done, which is precisely why the governance question in the companion piece matters.

The copyable rule: when a single working directory becomes the contention point, shard it. Give each cluster of agents an isolated worktree, let them commit atomically inside it, and let the version control layer handle the merge. You parallelize the work along boundaries the tools already know how to defend.

Do this now

Take one agent workflow you already run in parallel, even at N of 2, and audit it against the four moves. What shared context are your agents each re-deriving that should live in a file they read on boot? Have you ever run the loop on the smallest possible N before scaling it, or does it go straight to full width? Which operations in the loop touch shared state non-atomically, and have you watched what happens when two agents hit them at once? Where is the single directory or resource that every agent contends on, and can you shard it?

The artifacts and the constraints are the harness. The prompt is almost incidental. Bun’s rewrite is worth studying not because a fleet wrote a lot of Rust fast, but because the write-up shows exactly which four decisions turned a pile of parallel agents into a system that did not corrupt itself. Copy the four decisions. Weight the model claims and the final verdict for yourself.

---

This analysis synthesizes Rewriting Bun in Rust (Bun, July 2026), the Hacker News discussion of the porting guide (Hacker News, July 2026), Zig creator calls Bun’s Claude Rust rewrite ‘unreviewed slop’ (The Register, July 2026)…

Victorino Group helps teams design the harness, artifacts, and constraints that let an agent fleet run without corrupting itself. Let’s talk.