10 Years To Build The Language, 11 Days For AI To Rewrite It, Then The Money Stopped
Writer : Haris Waheed
Full Stack Web Developer & SEO Specialist | Building Fast, Search Optimized Websites for Business Growth.
In Brief
For years, a small, uncompromising programming language called Zig carried a specific accusation from the wider software industry, that it could never be trusted to run real, production grade software at scale. One project spent years proving that accusation wrong. Bun, the JavaScript runtime and toolkit built almost entirely in Zig, ran on millions of machines and became one of Zig’s most visible, most important production users. Then, in the spring of 2026, months after Anthropic acquired the company behind Bun, its founder pointed a swarm of ai coding agents at the entire million plus line codebase and had it rewritten from Zig into Rust, largely unattended, over eleven days. The rewrite worked, by most technical measures. It also exposed real, measurable problems in the resulting code, ignited one of the most heated public arguments in open source software this year, and coincided with the end of a funding relationship that had helped keep the Zig Software Foundation financially afloat. This article walks through exactly what happened, what the numbers in the actual pull request show, why the language’s own creator called the result unreviewed slop, and argues honestly about how much of this story is really about ai capability and how much is about something considerably older, incentives, money, and who gets to decide what quality actually means.
Now, the full story.
The Language That Finally Proved Itself
For a long stretch of its existence, Zig lived with a specific reputation problem. It is a genuinely ambitious systems programming language, designed from the ground up to do more with less, with a philosophy built around explicitness, a zero dependency toolchain, and a refusal to hide complexity behind convenient abstractions. Serious engineers respected the ideas behind it. Plenty of the same engineers also said, openly and often, that it could never actually be trusted with real, production critical software, that it was too young, too unstable, too far from a stable 1.0 release to bet a real company on.
Bun became the project that quietly, decisively proved that skepticism wrong. 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, all built as a drop in replacement for the considerably more established Node.js, and all written almost entirely in Zig. Oven, the company behind Bun, raised seven million dollars in 2022, led by Kleiner Perkins with participation from Guillermo Rauch and Y Combinator, and Bun steadily grew into one of the most visible, most technically respected users of Zig anywhere in the industry, running on millions of machines. For a language that had spent years fighting a credibility gap, Bun was living proof the gap could be closed.
Bun was more than just a showcase, too. It was a regular financial contributor to the Zig Software Foundation, the small, 501c3 nonprofit responsible for funding the language’s core development. The foundation runs on a genuinely modest budget, roughly six hundred seventy thousand dollars a year according to its own public financial reporting, with the overwhelming majority of that money going directly to paying core contributors for their work. In a nonprofit that size, a single steady corporate donor matters enormously, and Bun, by most accounts, was exactly that kind of steady presence for years.
The Acquisition Nobody Fully Understood Yet
On December 2, 2025, Jarred Sumner announced, in a company blog post, that Bun was joining Anthropic. Sumner emphasized that Bun would remain open source under its existing MIT license, and framed the acquisition as a resourcing win, funding that would let the team hire more engineers and move considerably faster on new features. There was a specific technical detail buried in the announcement that mattered more than it seemed to at the time. Claude Code, Anthropic’s own agentic coding tool, ships as a Bun binary. Anyone who had ever run Claude Code had, whether they realized it or not, been running Bun underneath it the entire time. Acquiring Bun was not just a talent acquisition for Anthropic. It was acquiring a piece of infrastructure Anthropic’s own flagship product already depended on directly.
That dependency is worth sitting with for a moment, because it explains a great deal about what happened next. A runtime written in a language still without a stable 1.0 release, still fighting for legitimacy in parts of the industry, was quietly load bearing infrastructure for one of the most important AI coding products on the market. If you would rather skip straight to talking about what responsible AI adoption in a real production codebase actually looks like for your own business, our team at Zynthx Technologies has exactly that conversation with clients regularly, and you can start a project or book a free consultation any time.
The Wall Zig Put Up
Here is where the story’s central tension actually starts. Zig, the language itself, maintains a strict, categorical, and deliberately uncompromising policy, no AI generated contributions, anywhere, under any circumstances. The policy covers issues, pull requests, and even bug tracker comments, and it leaves essentially no room for exceptions. Maintainers are explicitly permitted to reject a contribution purely on suspected AI involvement, without needing to debate its technical merit at all. Andrew Kelley, Zig’s creator, has been blunt and consistent about the reasoning behind the policy, describing AI generated pull requests as invariably garbage that waste reviewer time regardless of whether the underlying code happens to work.
Loris Cro, a leading figure at the Zig Software Foundation, reaffirmed this exact policy publicly in late April 2026, specifically in the context of growing tension with Bun’s increasingly AI heavy development practices. Bun, a company that quite literally builds an AI coding tool for a living and works in a deeply AI native way internally, kept running into that same wall repeatedly. According to independent technical coverage, the team had already declined to upstream a roughly fourfold performance improvement to Bun’s compile process specifically because the enhancement had been produced through AI assisted development and conflicted with Zig’s rules, leaving the gain stranded in a downstream fork that could never be merged back into the main language.
Just four days after Cro’s public reaffirmation of the no AI policy, on April 29, 2026, Bun began work on decoupling itself from Zig entirely, using precisely the kind of AI assisted development the language had just drawn its hardest possible line against.
Eleven Days, Fifty Agents, One Million Lines
What happened next is, by nearly every independent account, one of the largest publicly documented AI driven code migrations ever attempted. Sumner opened pull request number 30412 with a three word title, and the work behind it began on May 3, 2026. Rather than a single AI assistant working through the codebase file by file, the rewrite ran through Claude Code’s Dynamic Workflows system, a structured pipeline capable of fanning work out across dozens or even hundreds of parallel AI agents simultaneously. Reports on the exact configuration vary somewhat, with figures ranging from roughly fifty to sixty four Claude instances running in parallel at peak, operating continuously on a dedicated cloud instance for the better part of eleven straight days. Sumner himself reportedly stayed closely involved throughout, continuously adjusting how the agents were instructed and how the generation process worked each time a new problem surfaced, rather than simply issuing a single prompt and walking away.
The scale of what came out the other end is genuinely difficult to process in normal software engineering terms. The final diff that merged into Bun’s main branch on May 14, 2026 added just over one million lines of code. The resulting Rust codebase came in at approximately seven hundred eighty thousand lines, larger than the five hundred thirty five thousand four hundred ninety six line Zig codebase it replaced, though the underlying counting methodology between the two figures is not perfectly comparable. By way of comparison, a rewrite of this scale, more than half a million lines of production critical systems code, would historically have required a dedicated team roughly a year of sustained work, a timeline long enough that most companies would never have approved the project in the first place. Independent reporting pegs the total cost of the entire effort at roughly one hundred sixty five thousand dollars in raw API pricing, a genuinely remarkable figure for a migration of this magnitude regardless of how you feel about the result.
What was actually running underneath this effort matters too. The rewrite used a pre release version of what would later be publicly announced as Claude Fable 5, Anthropic’s Mythos class model, meaning Bun’s own team had access to genuinely frontier capability well before the general public did, another direct benefit of the acquisition that made this specific timeline possible at all.
What The Numbers Actually Show
Here is where the story stops being purely a triumphant tale of AI capability and becomes something more complicated, because the actual, measurable results of the rewrite cut in both directions at once, and a fair account has to hold both halves honestly.
On the clearly positive side, the numbers are genuinely strong. The resulting Rust binary came in twenty percent smaller than its Zig predecessor, ran two to five percent faster on the same workloads, and eliminated a specific, longstanding memory leak that had reportedly caused Bun to leak up to seven gigabytes of memory after roughly two thousand build cycles, a real, meaningful production reliability improvement that Zig’s own memory model had apparently struggled to prevent over years of active development. The entire migration also passed Bun’s existing automated test suite, which is not a trivial bar to clear at this scale.
On the more concerning side, independent code review of the merged Rust codebase surfaced numbers that gave a lot of experienced engineers real pause. The rewritten code contained 13,044 unsafe blocks, a specific Rust construct that deliberately opts out of the language’s core memory safety guarantees, the exact protections that are typically the entire reason a team chooses Rust in the first place. For comparison, hand written Rust projects of a similar size average roughly seventy three such blocks, meaning the AI generated codebase used this particular escape hatch at a rate roughly one hundred seventy times higher than a typical human written project of comparable scope. The code also contained more than nine hundred ninety nine uses of static mut, a pattern that introduces global mutable state, widely considered close to the direct opposite of what Rust’s entire safety model is designed to prevent.
Zig’s own creator did not hold back in his public assessment of the result. Andrew Kelley described the rewritten codebase as unreviewed slop, and went further, arguing that Bun’s underlying engineering practices had been a genuine concern well before AI tools entered the picture at all, describing a pattern of aggressive feature releases that had, in his view, already produced piled up bugs, weak error handling, and accumulating technical debt long before any AI agent touched the code. Kelley speculated, pointedly, that Sumner may have been operating under business pressure to hit specific objectives rather than pure technical pressure, a dynamic he suggested likely intensified once Anthropic’s acquisition raised the stakes and the visibility of everything Bun shipped. In Kelley’s own framing, Bun parting ways with Zig was, on balance, good news for Zig’s reputation rather than a loss worth mourning.
Not everyone in the community agreed with that read. Theo, host of the widely followed t3.gg podcast and a close friend of Sumner’s, pushed back directly, arguing that Kelley’s public criticism amounted to an act of community self destruction from a language steward who fundamentally misunderstood the actual engineering problem Zig was originally built to solve in the first place. The disagreement between two respected, technically credible voices in the same ecosystem is itself part of the story, a sign that this is not a simple case of obvious right and obvious wrong, but a genuine, substantive disagreement about what responsible engineering actually looks like when AI capability changes what is technically possible on a timeline this short.
The Money That Stopped
Here is the part of the story that gets considerably less attention than the technical drama, and it deserves more. For years, Bun had been one of the Zig Software Foundation’s steady financial contributors, a meaningful, recurring source of support for a nonprofit operating on a budget of roughly six hundred seventy thousand dollars a year, the overwhelming majority of which goes directly to paying the small number of core contributors who maintain the language itself. Once Bun’s rewrite was complete and the project had formally decoupled from Zig, that steady contribution stopped. There was no dramatic announcement, no formal wind down notice explaining the decision. The foundation’s own public financial reporting for the surrounding period describes a familiar, uncomfortable pattern for a small nonprofit, a slow decline in donations even as user activity and demand for paid contributor work kept climbing.
The community response to that gap is worth noting too, because it complicates any simple ai took the money and ran narrative. Mitchell Hashimoto, creator of the Ghostty terminal emulator and a longtime Zig supporter, publicly pledged an additional four hundred thousand dollars to the Zig Software Foundation shortly after the Bun controversy became public, structured as two hundred thousand dollars a year over two years, explicitly reaffirming his respect for the foundation’s approach to maintainership and its uncompromising stance on AI generated contributions. Hashimoto was careful to frame his donation as separate from any judgment about Bun specifically, stating plainly that he had no problem with what Bun had done and was not interested in turning his support into commentary on that decision, while also noting, with visible frustration, how quickly parts of the community had rushed to villainize each other over a genuinely complicated situation that deserved more empathy than it received.
That detail matters enormously for how you should read this entire story. The money that stopped arriving from Bun did not leave Zig without a lifeline. It revealed, quite starkly, how dependent a small but genuinely important piece of open source infrastructure had become on a small number of large, discretionary donors, and how quickly that support can shift when one of those donors changes its own strategic direction, for reasons that had nothing to do with any judgment about the foundation’s work.
The Debate Worth Having
This is exactly the point in the story where the conversation deserves real, honest argument rather than settling for whichever framing generated the most outrage on social media.
The Case That This Proves AI Assisted Rewrites Are Genuinely Ready
The strongest version of this argument points directly at the outcome. A migration that would historically have consumed a dedicated team’s entire year, and would therefore likely never have been greenlit in the first place, was completed in eleven days for roughly one hundred sixty five thousand dollars, passed the existing test suite, and produced a binary that was measurably smaller, measurably faster, and free of a longstanding memory leak that years of human engineering effort had not managed to fully resolve. Proponents of this reading argue that the actual bottleneck in large scale rewrites has always been cost and time, not the theoretical value of doing the rewrite at all, and that AI agents operating at this scale genuinely changes which rewrites become economically viable for teams to attempt, potentially unlocking safety and performance improvements across countless aging, unsafe codebases that would otherwise never receive the investment a full rewrite requires. On this view, the unsafe block count and the static mut usage are real issues worth fixing, but they are the kind of issues a subsequent, more targeted cleanup pass can address, not evidence the entire approach is fundamentally broken.
The Debate Worth Having
This is exactly the point in the story where the conversation deserves real, honest argument rather than settling for whichever framing spread furthest on social media.
The Case That AI Really Is The Underlying Cause
The strongest version of this argument does not require ai to have directly automated any specific role to still be the real underlying cause. It points out that without the enormous capital demands of the AI infrastructure buildout, Oracle would likely not have needed to free up capital at this scale in the first place, regardless of how the Cerner integration or the VA contract were going independently. On this view, ai is not a minor contributing factor sitting alongside the real causes, it is the actual root cause that created the financial pressure everything else got layered on top of, and describing the Cerner acquisition or the government contract as more important risks missing the forest for the trees. The infrastructure spending was a choice Oracle made specifically because of the competitive pressure created by the broader ai race, and every other financial strain the company was managing simply made that already difficult choice even harder to fund without cutting headcount.
The Case That The Numbers Reveal A Real, Serious Problem
The counterargument does not deny that the rewrite technically worked, in the narrow sense that it compiled, passed tests, and shipped. It challenges whether passing tests is actually sufficient evidence of genuine quality for production critical infrastructure. A rate of unsafe block usage roughly one hundred seventy times higher than comparable hand written Rust code is not a minor stylistic quirk, critics argue. It represents exactly the kind of safety guarantee Rust exists specifically to provide, deliberately bypassed at a scale that suggests the AI agents were optimizing for passing the existing test suite rather than for the deeper, harder to verify property of genuine memory safety the language was chosen to deliver in the first place. Existing test suites, by design, only catch behavior someone already thought to test for. They do not reliably catch the kind of subtle, hard to trigger bugs that unsafe code and uncontrolled global mutable state are specifically prone to producing under real, unpredictable production load, the kind of bug that often takes months or years of real world usage to actually surface. Kelley’s harsher framing, that Bun’s underlying engineering culture already had quality problems well before AI entered the picture, adds a further layer to this argument, suggesting the AI rewrite may have amplified an existing pattern of moving fast at the expense of rigor, rather than introducing a new problem on its own.
Where This Actually Lands
Both readings are held by genuinely serious, technically credible people, and the honest synthesis does not fully side with either camp. The rewrite is a real, significant demonstration that AI agents operating at scale can complete migrations that were previously economically unthinkable, and that capability is not going away regardless of how this specific instance is judged. At the same time, the specific numbers in the merged code represent a real, measurable gap between passing an existing test suite and actually achieving the deeper safety guarantees the target language was chosen to provide, and dismissing that gap because the migration was fast and cheap risks normalizing exactly the kind of technical debt that tends to surface at the worst possible moment, once a system is already carrying real production weight. What is not seriously disputed by either side is that the underlying capability shift is real and immediate. The disagreement is entirely about how much additional, careful, human led scrutiny that capability still requires before its output should be trusted the same way carefully reviewed human written code has traditionally been trusted, and that is a genuinely open, actively contested question rather than one this single high profile case settles either way.
What This Actually Means For Your Business
Step outside the specific drama of Bun and Zig for a moment, because there is a genuinely transferable lesson here for any business thinking about using AI for a large scale technical migration of its own. The core lesson is not that AI driven rewrites are either magic or reckless. It is that the speed and cost advantages are real and substantial, while the quality assurance burden does not disappear, it simply moves. A test suite that was adequate for catching bugs introduced by careful human engineers over years may not be adequate for catching the specific failure patterns an AI agent optimizing purely for passing that same test suite is prone to introducing, which means the review process itself needs to be rebuilt around the new tool, not simply pointed at the same old checklist and trusted to catch everything that matters.
This is exactly the kind of careful, honest technical assessment our team handles for clients considering exactly this kind of large scale AI assisted migration. Our AI automation service is built around figuring out realistically where AI genuinely accelerates a project safely and where additional human review needs to be built into the process from day one, rather than bolted on after something has already shipped. If what your business actually needs is a properly built, properly reviewed platform, whether that involves an AI assisted migration or a fresh build, our web development service, app development service, and custom software development service all handle that work with the kind of rigor this story demonstrates genuinely matters, and you can see real examples of that work in our portfolio.
If your business runs critical infrastructure that touches customer data or payments specifically, our e commerce website development service is worth a conversation given how much risk sits in exactly the kind of safety guarantee this story shows can get quietly bypassed under time pressure. Given how directly this story involves security relevant code patterns slipping through an existing test suite, our ethical hacking training program at Zynthx Academy is increasingly relevant for any team relying more heavily on AI generated code. Our python programming training program, machine learning training program, and data science training program go deeper for teams who want to genuinely understand what these systems are doing rather than trusting output at face value, and our web development training program and app development training program cover building the kind of properly reviewed product this entire story argues for. Our uses of AI training program gives a grounded, practical overview for teams earlier in this journey, and our digital marketing training program, SEO training program, and e commerce website training program round out the picture for teams focused on growth once the underlying technical foundation is solid, and once your product is solid, our digital marketing service helps make sure it reaches the right audience.
If you are further along and want to work in this space directly, our careers page lists open roles, with dedicated pages to apply for a job, apply for an internship, or apply as a skills trainer. You can read more about who we are on our about page, browse more pieces like this one on our blogs page and our dedicated blog section, including our recent post on the best website design trends for businesses in 2026, or simply contact us directly. You can also follow along on Facebook, Instagram, and LinkedIn, see our full company overview on Slideshare, or read verified client feedback on our Bizoforce profile and Yellow Pages UAE listing.
Common Questions
Did Bun actually stop working during the rewrite. No. Bun’s stable release channel continued shipping Zig based builds throughout the transition, while the Rust rewrite was developed and merged as a separate effort, meaning existing users were not left on a broken runtime during the migration itself.
Why does Zig ban AI generated code so strictly. The Zig Software Foundation’s leadership has been explicit that the policy exists because reviewing AI generated contributions consumes valuable maintainer time on code they consider frequently low quality regardless of whether it technically functions, and because the policy allows maintainers to reject a contribution on suspected AI involvement alone without needing to justify the decision on technical grounds case by case.
Was the rewritten Bun codebase actually less safe than the original. The specific metrics available, a dramatically higher rate of unsafe code blocks and global mutable state compared to typical hand written Rust, suggest real safety concerns exist in the merged code, even though it passed Bun’s existing automated test suite. Whether those specific patterns translate into real world reliability problems is something that will likely only become fully clear with more time in production.
Did the Zig Software Foundation lose funding permanently because of this. The foundation lost a steady, longtime corporate contributor once Bun’s relationship with the language ended, but the broader open source community responded with renewed support shortly afterward, including a significant new pledge from Ghostty creator Mitchell Hashimoto, suggesting the funding gap was at least partially, though not necessarily fully, offset by renewed community backing.
Should other companies attempt a similarly large AI driven rewrite. The Bun case demonstrates the approach is technically possible and can produce real, measurable performance gains at a fraction of the traditional cost and timeline, but the safety metrics in the resulting code suggest any team attempting something similar should build considerably more rigorous, AI aware code review into the process than relying on an existing test suite alone, particularly for anything touching production critical or security sensitive systems.
The Honest Closing Thought
What makes this story worth telling in full, rather than reducing to either a triumphant AI capability headline or a cautionary tale about reckless engineering, is that it is genuinely both at once, playing out inside the same eleven days, the same million lines of code, and the same small, tightly connected open source community. A ten year old language finally proved it could carry real, production critical software. The company that proved it then used AI to leave that same language behind, in a fraction of the time any human team could have managed, producing results that were simultaneously faster, smaller, and, by at least one serious measure, less carefully guarded than the code it replaced. And underneath all of that technical drama, a small nonprofit that had quietly depended on one company’s steady support found itself needing to lean on its wider community instead, a reminder that the infrastructure holding up a meaningful share of the software world often runs on considerably thinner, more fragile financial footing than most of the people relying on it ever stop to consider.
The lesson worth carrying forward is not a simple verdict on whether AI driven rewrites are good or bad. It is that the capability is real, the risks it introduces are also real and specific rather than vague, and the businesses and communities that come out ahead will be the ones that take both halves of that truth seriously at the same time, rather than picking whichever half makes for a better headline.
Let's Start a Project
Share your idea with Zynthx and our team will help you plan the next clear step.
Writer : Haris Waheed
Full Stack Web Developer & SEO Specialist | Building Fast, Search Optimized Websites for Business Growth.
