Post cover image
Photo by Phongpanot Phairatwetchaphan on Unsplash

July 16, 2026

10 Years to Build the Language. 11 Days for AI to Rewrite It. Then the Money Stopped.

A programming language finally proved it could ship real software. Then its new owner rewrote the book on what our future will look like in…

By Can Artuc

7 min read

A programming language finally proved it could ship real software. Then its new owner rewrote the book on what our future will look like in open source

For years, a small programming language carried the same accusation. Serious engineers said it could never be trusted with production software. One product proved them wrong. It ran on millions of machines, and every line of it was written in that language.

That product walked away in the spring of 2026. It went to a swarm of software agents that rewrote the entire codebase into something else, faster than any group of humans could have typed it.

The money walked away, too. A steady payment that had additionally helped keep the language alive stopped arriving. There was no email and no wind-down, only a bank balance that went flat, and a founder left to read what the silence meant.

The Flagship That Proved a Language

The language is Zig. The product is Bun.

Jarred Sumner started Bun in 2021 as an all-in-one toolkit for JavaScript and TypeScript developers: a runtime, a bundler, a package manager, and a test runner in one program. He wrote it in Zig, a young systems language created by Andrew Kelley. Bun grew into the most prominent large-scale project ever written in Zig, with over 22 million downloads a month.

Zig had spent years defending itself against one charge above all others: it was a toy and unsafe for real work. Bun was the counter-evidence. Every time a company shipped on Bun, Zig got to point at a production system running its code at scale.

Sumner had set up a monthly donation from Bun to the Zig Software Foundation, the non-profit that funds Zig's development. It added up to $60,000 per year. Kelley called the gesture "pretty cool." For a small language foundation, $60,000 a year from a single donor covers real operating costs.

Then, on December 2, 2025, Anthropic acquired Bun.

Claude Code, Anthropic's coding tool/cli, ships as a single binary compiled by Bun, so Bun has become core infrastructure for Anthropic's own product. Anthropic announced the deal in the same breath as news that Claude Code had reached a billion dollars in run-rate revenue.

Anthropic never disclosed what it paid for Bun, and Bun would stay open source and MIT-licensed.

So two things now hung on one company's goodwill: the proof that Zig could run in production, and a money contribution behind Zig itself.

Five months after Anthropic signed, the first one was gone.

None

64 Agents, 11 Days

On July 8, 2026, Sumner published how he and a fleet of Claude agents had rewritten all of Bun from Zig to the Rust programming language.

Bun was 535,496 lines of Zig, excluding comments. Sumner and a fleet of Claude agents converted all of it to Rust. The active work took eleven days, from May 3 to the merge on May 14.

Sumner ran 4 copies of the project side by side. Inside each one, 16 Claude instances worked simultaneously: some writing Rust, some attacking that Rust to find flaws, and some fixing what the attackers found. Around 64 agents ran at once, day and night, without waiting for a human to read each line… The model driving them was a pre-release version of Claude Fable 5.

The cost for that came to about $165,000 in tokens at list pricing: 5.9 billion input tokens the model had not seen before, 690 million tokens of output, and 72 billion cached reads. The final change touched more than a million lines of code and landed across 6,502 commits.

The Rust version passed 1,386,826 assertions, each one a small automated check confirming the code did a specific thing right, across 60,624 tests, with zero tests deleted or skipped, through 11 separate rounds of security review. Along the way, it fixed 128 bugs that the last Zig release still carried, and caught 19 regressions before shipping. The Rust build came out around 20% smaller and 2% to 5% faster than the Zig one.

Sumner's own estimate: 3 human engineers doing this by hand would have needed roughly a year. The agents did it in eleven days.

The code they replaced was not broken. It ran on millions of machines every day. So why rewrite half a million lines of it?

None

An Engineering Problem

One engineering problem drove the whole rewrite.

Bun mixes two kinds of memory. JavaScript values are managed automatically by a garbage collector, a background process that reclaims memory once the program stops using it, so the developer never has to free them. The native code underneath manages its own memory by hand. When those two systems disagree about when a piece of memory is still alive, things break.

A developer runs a Bun server. Under load, the garbage collector decides one JavaScript object is finished and hands its memory back to be reused, while the native code underneath is still pointing at that same spot, expecting the object to be there. The next request reads that spot and gets data that has already been thrown away or overwritten. The server sends back a garbled response, or it crashes outright, and the on-call engineer loses hours chasing a fault that only appears under real traffic. Sumner named these failures directly: use-after-free, double-free, small leaks, all cases where code touches memory it no longer owns. "In safe Rust, these are compiler errors." The build fails on a laptop instead of in production.

That failure is exactly what Rust is built to stop. It has a borrow checker, a compiler feature that tracks memory lifetimes and refuses to build code that gets them wrong. Zig has none.

Rust's safety has one exception, a keyword called unsafe. Wrapping a piece of code in it tells the compiler to stop checking that piece and trust the programmer instead. Bun's new codebase uses it in places. Of its roughly 780,000 lines of Rust, about 27,000, a little under 4%, sit inside these unsafe blocks. In those lines, the compiler's memory guarantees are switched off, and the programmer is vouching by hand that the memory is handled correctly. So any memory-safety bug that survives now has to come from those 27,000 lines, not from the whole program. The danger zone is much smaller now, but not zero. Zig exposed the entire codebase to those bugs.

A test suite only catches the bugs someone thought to write a test for. Passing 1.4 million of those checks proves the code does what its authors expected, and nothing about the cases they never imagined, which are the ones real users tend to hit. The real verdict comes later, once the next stable release ships and the crash reports and security bugs start arriving.

On Hacker News, the loudest doubts were about maintainability. Bun is now more than 750,000 lines of Rust that agents mostly wrote. Can human engineers still read, review, and fix that much machine-written code years from now, or has it become something only the machines that produced it can truly follow?

If the idea of a codebase written mostly by agents makes you uneasy about your own stack, clap, leave a comment, and share this. Whether it generalizes is not settled, and your experience is part of the answer.

He Saw the Silence Coming

Kelley, who leads the Zig Software Foundation, answered the next day, on July 9, 2026, in a post on his own blog.

His first reaction was not anger. "When Jarred announced the Rust rewrite, we were ecstatic. It seemed too good to be true."

Then he described the money. The $60,000-a-year donation from Bun to the Zig Software Foundation had stopped. It "silently stopped" after the acquisition, in his own words, with no note from either side.

"When the donation silently stopped, our bank account was ready for it." He had seen it coming since the acquisition. The foundation had already planned around losing the money before it disappeared.

Kelley did not spare the codebase, either. He called Bun "the prime example of How Not To Write Zig Code." And he reached for an image to describe his relief: "now I'm metaphorically sipping delicious tea from a mug that says 'It Tastes Like It's Not My Problem Anymore'." The mug is a figure of speech, not a real object, but the feeling behind it is real enough.

Underneath the jokes, he named the actual split. "His singular focus on productivity and his startup's exit strategy was increasingly at odds with my longer term vision for the Zig project." Two people who once helped each other had been walking in different directions for a while. The acquisition made it official.

None

One Buyer. Every Piece.

One company acquired the most prominent product built on a small language. Months later, that product left the language, and the donation it had been sending to the language's foundation stopped without a word. The buyer of the flagship and the source of the funding were the same company, and both changes came out of the same acquisition.

There are 3 parts in this story.

The first part is an engineering challenge. You may like it or not, rewriting Bun for memory safety is a real engineering decision, and every decision has a trade-off.

And once Anthropic stopped building Bun on Zig, the donation had an obvious reason to end. A company pays for the language it depends on, and Anthropic no longer depended on Zig. This is the second part.

The third part is different. One company with deep enough pockets now holds the flagship, the money that flowed from it, the AI model that did the rewrite, and the tool that ships the result. When we put them together, then a single company owns every meaningful part of this story at once. I have no framework that tells me where that leads, and I do not trust anyone who says they have one.

If your stack rests on open source software that one deep-pocketed company could own end-to-end, from the code to the model to the money, clap, comment, and share this with whoever carries that risk on your team. Then go find out how many hands actually hold the pieces you depend on.

Kelley saw the silence coming and planned for it. A foundation can plan around a lost donation. It cannot plan around what comes after. What happens when one company can afford to own everything that matters in the tools you build on?