Would You Ship a Codebase Rewritten Entirely by Agents?

The team behind Bun ported 535,000 lines of Zig to Rust in 11 days, with one engineer, 64 Claude agents running in parallel, roughly $165,000 in API costs, and compiler errors treated as a distributed work queue. 

The port is already running in Claude Code and Prisma's public beta. Zig's creator called it "unreviewed slop."

So I asked our engineering leaders: would you ship a codebase rewritten entirely by agents?

Shipping Codebases with Agents is the New Turing Test

Nikhil Gopinath Kurup (SVP of Engineering, ML)

Yes, I'd ship this one. And notice what the Bun team actually said: they gave the credit to the compiler, not the model. "Compiler errors as a work queue" is basically the whole story. They didn't trust the agents at all. They built a setup where every one of the ~1,300 lines a minute got checked mechanically, and the borrow checker doesn't care how good your prose is.

The way I think about it, this is really a Turing test. If you have a perfectly specified system, and a compiler is about as perfect as it gets, then the input is spec'd, the output can be verified from every angle, every claim in the spec has a test case, and there's already an implementation to diff against. Once you have all that, it stops mattering what's inside the box writing the code. Could be an army of interns, could be a few 100x engineers, could be 64 Claudes running for 11 days. If it swims like a duck and quacks like a duck, it's a duck. The author basically disappears into the verification.

You can see the edges of that in the fine print, though. 19 known regressions still made it into the final compiler and look at what they were: side effects inside a debug_assert that disappeared in release builds, bytemuck panicking where Zig used to silently truncate, comptime format-string behavior that got lost in translation. 

"Ship an agent-written rewrite as far as you can verify it."

Nikhil Gopinath Kurup

SVP of Engineering, ML

None of those are memory bugs. The duck test only checks for the stuff that's actually in your spec. The compiler caught its whole class and was blind to the rest. That's why they also re-ran the exact same TypeScript test suite and put two adversarial Claudes on it: one trying to ship and one trying to break. Even with all that, some behavior still slipped through.

We did a smaller version of this ourselves recently. We had SDKs for our APIs in a few languages, a customer wanted a new one, and that is an almost perfect agent task. Translate from an existing SDK, re-run the same 100%-coverage test suites the other languages already had. Spec, reference, full coverage, clean duck test. The agent handled it well.

But I wouldn't reach for this everywhere. That SDK job worked because the spec, the reference, and the tests all existed first, and engineers built them. Everything before that point, speccing the system, designing it, deciding what's even worth building, reviewing whether it's right, is still on the engineers here, and I'm not looking to change that. 

Agents have made those people a lot faster. They're not going to replace them. Ship an agent-written rewrite as far as you can verify it. When you're writing the code and the thing that checks the code at the same time, that's still a person's job.

Shipping Faster With AI Is in Tension With Guaranteeing Quality

Ethan Andyshak (SVP of Product)

“The agents never had to be trusted, only checked.” This is the most important detail for me. Using agents to write code is efficient, but we're not at the point yet where we can safely ship all agent code without reviewing it. 

This is a challenge because reviewing code can be time-consuming: you have to read and understand what the agent did in order to figure out if it makes sense. Even when there's no AI involved, this process requires a non-trivial percentage of the time it takes to write the code. 

“If you try to fix AI problems with more AI, you might just be making a xerox of a xerox”

Ethan Andyshak

SVP of Product

If companies try to accelerate by using agents to write large code bases quicker than they can be reviewed by humans, humans are still a bottleneck in the workflow, and you can't achieve the full acceleration that you might want. 

As a result, we see new AI-driven tools coming out to take some of the burden of reviewing the code as well. At the end of the day, if you try to fix AI problems with more AI, you might just be making a xerox of a xerox — you're still losing some quality unavoidably.

In the future, we hope that the original agents writing code will have closer competence to senior developers, and that the peer review agents have the same critical eye as those senior developers' colleagues. Until then, while we're in this awkward growing pains phase, the pressure to ship code faster with AI remains in tension with the pressure to use human code review to guarantee quality.

Quality Still Takes Nuance and Iteration, Even Shipping With AI

Hari Chandrasekhar (SVP of Engineering, Core)

The single biggest advantage I take from the Bun story is the validated tests. That is probably the main reason they could ship an agentic migration with confidence. The procedure they outline is a good illustration of the nuance, iteration, and meticulous thought that actually goes into building a product at the quality bar people expect.

Expectations of AI systems and agents have skyrocketed, but it is still not magic. These systems think and act based on historical evidence and traces drawn from human experience and ideas. A genuinely new product or feature gets built on top of those ideas through repeated thought and improvement. Most successful products come from that additional process, and specialized products bring in niche concepts that make them stand out. The article shows how agentic systems can expedite the work, but the specialization and meticulous treatment were orchestrated by a human with the agent’s help.

“Expectations of AI systems and agents have skyrocketed, but it is still not magic.”

Hari Chandrasekhar

SVP of Engineering, Core

Building on Ethan’s “checked, not trusted” point: can we ship code that is entirely agent-built? Yes, if there is enough process and enough guardrails to guarantee the level of validation a product’s quality bar requires. Vibe coding is getting popular, and we have also heard reports of people taking backward steps. In areas with simple, known, already proven steps, vibe coding works, and more people without a technical background will be able to use it. 

But products with niche and fresh ideas need newer thinking and rigor. Agents will make that possible far faster, but it involves a dimension of human intelligence, experience, and thought that is not yet encoded or contextualized for current AI. Over time there will be an iterative process where the systems eventually learn it.

To summarize: can we ship code with agents? Yes, we are heading there. But there is a part of human intelligence, iteration, and thinking that is still required to orchestrate and set up the systems for high standards.

Why the Bun Rewrite Actually Worked

Suresh Mathew (CEO & Founder)

Would I ship a codebase rewritten entirely by agents? Yes, but with a big caveat.

It comes down to first principles here: The fundamental issue is you’re relying on a probabilistic engine. An LLM gives you the most likely output, not a correct one. So trust is off the table from the start, meaning verification must become everything.

"Take away that harness and I wouldn't ship it."

Suresh Mathew

CEO & Founder

And verification is actually harder here than a human port. Humans reviewing code as they translate it is free QA. A million agent-written lines that nobody read? That checking has to be built explicitly. 

Bun had years of tests and a compiler enforcing exactly what they cared about. That’s why it worked. Take away that harness and I wouldn’t ship it.

Shipping agents is the first problem. Running them is the next. Sedai optimizes the agents you've already built. See how.

Want to know how AI agent optimization works? Read our guide.