550k Lines in 11 Days for $165k - and the Zig Creator Called It Slop
Bun's AI migration gave the read-the-code debate its first real data point: 550k lines, 11 days, $165k, memory down from 6.7GB to 609MB. Then Zig's creator called the result unreviewed slop. Both are right about different things.
Table of contents
A real argument has broken out about whether developers still need to read code. One camp says the volume produced by models makes reading it impractical, so you should manage intent instead of implementation. The other says no amount of tooling fixes what is fundamentally a model-quality problem, and engineers still have to read the output.
Until recently both sides were arguing from intuition. Then Bun migrated its entire codebase from Zig to Rust, published the numbers, and gave everyone something concrete to argue about.
The numbers
The migration moved roughly 550,000 lines of code across about 6,500 commits in 11 days, using 64 parallel Claude agents running Fable 5.
The bill and the token consumption:
- $165,000 at API pricing
- 5.9 billion uncached input tokens
- 690 million output tokens
- 72 billion cached input token reads
The results after the port:
- Memory use settled at 609 MB after 2,000 builds, down from 6.7 GB
- Performance improved 2–5%
- Binary size fell roughly 20%
For comparison, the team estimated the same work by hand at about three engineers with full context for a year. At a loaded cost of roughly $250,000 each, that is around $750,000 and twelve months, against $165,000 and eleven days.
Why this is not the slam dunk it looks like
Bun's own blog frames this as a success, and on those metrics it is. But the most useful reaction came from Andrew Kelley, the creator of Zig, who called the result "unreviewed slop".
That criticism is the whole debate in two words, and it cannot be dismissed by pointing at the memory graph. The measurable outcomes — memory, speed, binary size — are exactly the properties a compiler and a benchmark can verify for you. They say nothing about whether the code is comprehensible, whether its error handling is sound in paths the tests do not cover, or what happens the first time someone needs to change it.
A migration is also the most favourable possible case for this approach. The target behaviour already existed, in working code, with a test suite to check against. That is a very different problem from building something new where the specification lives in someone's head.
What the evidence actually supports
Reading the numbers and the criticism together, a narrower claim survives both:
Mechanical, well-specified, verifiable transformations are now dramatically cheaper. Ports, migrations, framework upgrades, large-scale refactors with a reference implementation and a test suite — these have moved from "budget a year" to "budget a fortnight". That is a genuine change in what is worth attempting, and we covered the operational side of running work at that scale in always-on coding agents and splitting a big task across specialised subagents.
What that does not establish is a general 10x on software work. The migration succeeded partly because correctness was checkable by machine. Where it is not, you are back to reading the code — which is precisely the point the sceptics are making.
One practical thing worth changing today
Buried in the same discussion is a finding that costs nothing to act on: models are worse at reviewing their own output than each other's. Claude Code and Codex reportedly find more issues in each other's code than in their own.
If that holds up in your workflow, the fix is trivial: route review to a different model than the one that wrote the code. It is the same instinct as not having an author copy-edit their own draft, and it needs no new tooling — just a different model in the review step. It pairs naturally with the guardrails in AI coding governance for small teams and the traceability argued for in agent observability.
The cost side nobody budgeted for
One more signal worth noting: Adam Mosseri at Meta has indicated the company is looking at per-engineer token budgets, because a heavy user's consumption starts to approach their salary.
That reframes the Bun figure. $165,000 for eleven days is cheap against $750,000 and a year — but it is not cheap in absolute terms, and it was a single project. Sustained at team scale, inference cost becomes a line item that has to be managed rather than an incidental expense. Which is, incidentally, an argument for reading the code: an agent looping on a problem it does not understand burns budget as fast as one making progress.
Bottom line
The Bun migration is the best data point either side has, and it does not settle the argument — it narrows it. Verifiable transformation work got much cheaper and much faster, and that is real. Whether the output is maintainable is a separate question that the benchmark cannot answer, and "unreviewed slop" from the language's own creator is not a criticism the numbers refute.
If you take two things from it: attempt the migration you have been postponing, and have a different model review the result.
Sources: Bun's engineering blog, The Pragmatic Engineer, The Register, Developers Digest (July 2026). Cost and token figures as published by Bun.
