AI Can Now Rewrite a Codebase in 11 Days. Most Teams Still Can't Afford to Work That Way.

Two independent commentators looked at Anthropic’s most powerful model, Fable, and reached opposite-sounding conclusions in the same week. One says it just proved AI can rewrite a codebase almost nobody would have trusted it with. The other says its price tag means most teams should barely touch it.

What they said

Paul Dix, founder and CTO of the database company InfluxData, was reacting to Bun 1.4, a JavaScript runtime whose maintainers used AI to convert its code from one programming language (Zig) to another (Rust) at large scale. Dix wrote:

“The fact that AI wrote 1M LOC and then refined it over the course of the next couple of months to produce a reliable piece of software that is currently running on millions of developer machines is absolutely mind blowing. […] If you can build a verification system and give proper direction, AI can produce a highly complex, highly sophisticated piece of software and it can continue to refine it until it just works.”

(“1M LOC” means roughly one million lines of code, the individual lines of instructions that make up a program.)

Drew Breunig, an independent data and AI strategist, was writing about the same model from the cost side. He argued that before Fable, developers had little reason to fine-tune how they used AI coding tools, because a newer, cheaper model would arrive soon and paper over the difference anyway:

“Prior to Fable, it felt silly to waste too much time improving your coding harness or context strategies. […] But then Fable landed. It was (and still is!) incredible. But the cost was so high and Opus was good enough for most of the code we needed.”

(“Coding harness” means the surrounding tooling and workflow that manages what an AI coding assistant does and how; “context strategies” means decisions about what information you feed the model before it starts a task. Breunig’s point is that neither was worth optimizing when a cheaper, better model was always about to arrive anyway.)

He pointed to GLM 5.2, a rival model that came out the same week as Fable, as one reason the calculation changed: he estimates it costs roughly a ninth of what Fable charges per use, and about a fifth of what Opus 5, a less expensive Anthropic model one step down from Fable, charges.

Who they are

Dix built InfluxDB, an open source database designed to store and query time series data, meaning data points recorded with a timestamp, like sensor readings or server metrics over time. He has no connection to Anthropic or to Bun; he’s an outside engineering leader commenting on a rewrite he watched happen. Breunig previously led data science and strategy work at PlaceIQ and its parent company Precisely, and now writes and advises independently on AI and data strategy, including work with the Overture Maps Foundation, a nonprofit that maintains shared map data standards. Neither is a spokesperson for the companies whose products they’re discussing.

The rewrite behind Dix’s claim

The project both are circling is worth spelling out, because it’s unusually well-documented. Bun, a JavaScript and TypeScript runtime (the underlying program that executes that code), was acquired by Anthropic in December 2025. In May 2026, its creator used a pre-release version of Fable to translate roughly 535,000 lines of Bun’s Zig code into new Rust code, according to Bun’s own blog post about the project. The work ran for 11 days, produced roughly 6,500 commits (individual saved snapshots of code changes), cost about $165,000 in AI usage fees, and introduced 19 regressions (things that used to work and briefly stopped), all of which were fixed before release. Dix’s “oracle” is the existing Zig codebase and its large pre-existing test suite: a known-good reference the AI’s Rust output could be checked against automatically, over and over, until it matched.

What they get right, and where it’s incomplete

Dix’s underlying point holds up: this wasn’t a demo. It was a large rewrite of infrastructure-level code, checked against real tests, that shipped and is running in production today. But the case study has a limit worth naming directly: Anthropic owns Bun and used its own model to rewrite its own now-owned codebase. That doesn’t make the results fake, but it means this is a vendor demonstrating its product on an asset it controls, not an independent team’s arm’s-length experiment. It’s also a best-case scenario for the “verification system” Dix describes: Bun already had years of rigorous, human-written tests to check the AI’s work against. Most codebases don’t have that, and building it from scratch is its own significant project.

Breunig’s tiering argument is grounded in something concrete, a real, if self-reported, price comparison, rather than a vague sense that AI is “getting expensive.” Its limit is that the specific cost ratios he cites are his own estimates, not figures independently verified against each vendor’s published pricing. His broader claim, that teams now have to decide deliberately which AI model handles which task, doesn’t depend on the exact ratio being precise.

Where they agree, and where they diverge

Both are describing the same turning point from different sides. Before Fable, according to Breunig, it wasn’t worth investing in how you used AI coding tools, because the next model would likely be both better and cheaper. Fable broke that pattern: a real capability jump that didn’t arrive at a lower price.

Where they diverge is what to do about it. Dix’s example is a case for reaching for the most powerful, most expensive model on a task big enough to justify it, provided you have a way to verify the result automatically. Breunig’s advice points the other way for everyday work: don’t default to the expensive model, because cheaper options are good enough for most tasks, and the price gap is large. Read together, they’re not actually in conflict. They describe two ends of the same decision: match the model to the task, and only pay premium prices when the stakes and the verification are both in place.

Why it’s notable

Most coverage of a new flagship AI model centers on benchmark scores. Both of these takes skip that entirely and focus on what changes in day-to-day engineering practice once a model is both meaningfully more capable and meaningfully more expensive than what came before. That’s a more useful signal for builders than another leaderboard placement, because it’s about how the tool gets used, not how it scores in isolation.

What it means for builders

Before reaching for the most capable, most expensive model on a large task, ask whether you have a way to check its output automatically, tests, a working reference version, or some other objective pass/fail check. That verification step, not the model’s raw capability, is what let Dix’s example turn into working software instead of a pile of AI-generated code nobody could trust.

For routine day-to-day work, don’t assume your most expensive model option is the right default. Try a cheaper model on a task first and check whether the output is good enough before paying a premium price for something a lower-cost option could have handled. Treat model choice as a decision you make per task, based on both the stakes and whether you can verify the result, not as a single default you set once and stop thinking about.

End of article