Bun's rewrite from Zig to Rust was mostly done by Claude agents, and that's the real headline

Simon Willison surfaced Jarred Sumner's writeup of rewriting Bun's core from Zig to Rust this week, and the numbers stopped me cold. PR #30412, merged May 14, added roughly 1 million lines across 2,188 files, reached 99.8% test compatibility on Linux x64, and shrank the binary by 3 to 8MB. Sumner's dry aside is that the rewrite took less time than finishing the blog post about it did.

The part that matters for anyone building: much of that translation was done by Claude agents. A pre-release Fable 5, running six days straight on high-memory nodes, producing 6,755 commits. This happened after Anthropic acquired Bun, so it's also a look at how the company that makes the model actually uses it internally when the stakes are their own runtime.

A million lines of language migration is not a task you prompt your way through. Zig and Rust have different memory models, different error handling, different everything. You don't get 99.8% test compatibility by asking nicely and hoping. You get it by having a spec, a test suite that acts as ground truth, and a loop that runs against it for days. The tests were the harness. The agent just kept grinding until they passed.

This connects directly to something Ethan Mollick reported the same week. With early access to Fable 5, he handed it a 19-page design document and watched it run for about nine and a half hours unattended to build a full survey-analysis tool. Calibration, corrected statistics, evidence inspection, the whole thing. Two data points, same lesson. When you give these models a specification instead of a prompt, the horizon of what a single run can accomplish stretches from minutes to days.

I've felt this shift in my own personal projects. The days where I was rewarded for clever prompting are ending. What's rewarded now is writing a spec precise enough that a machine can execute against it for six days without me babysitting it, plus a test suite honest enough to catch it when it drifts. That's a different skill. It looks a lot more like writing a design doc and less like pair programming. If you can't write the spec, the nine-hour run just gives you nine hours of confidently wrong code. The bottleneck moved. It's not "can it code." It's "can you say what you want precisely enough to be worth automating."