Zig Creator Calls Spade a Spade, Anthropic Blows Smoke

Zig creator Andrew Kelley has responded with unusual bluntness to news that Bun — one of the largest Zig codebases in the world — was rewritten into Rust with heavy use of AI coding agents, then, critics argue, wrapped in a marketing narrative that obscures what actually happened. Software engineer and blogger Ray Myers published a detailed breakdown of the episode, arguing that what looks like a straightforward technical decision is better understood as a business and PR move by a company with a high-stakes fundraising and IPO story to tell.

Note on sourcing: the account below relies substantially on Ray Myers' published analysis and on Bun's own migration writeup. Quotes and figures attributed to Myers, Kelley, and others reflect those write-ups and community discussion as reported; where wording is paraphrased we say so.

What Happened: Bun, Zig, and an AI-Assisted Rewrite

Bun is a JavaScript/TypeScript runtime — broadly comparable to a faster Node.js — originally written in Zig, a systems programming language positioned as a modern, simpler alternative to C. Before the rewrite, Bun was one of the largest real-world Zig projects in existence, making it a high-profile data point for Zig's viability in serious production systems work.

The Bun team, led by founder Jarred Sumner (whose company is Oven), carried out a large agentic rewrite from Zig to Rust, driven heavily by AI coding agents — with Anthropic's models and tooling used by the Bun team and featured prominently in how the effort was later promoted. To be clear about attribution: the rewrite itself was performed by the Bun/Oven team using Anthropic's tools, not by Anthropic. According to Myers' account, the resulting code was merged to mainline quickly, and the team's official explanation was published roughly two months later — a delay Myers argues is telling in itself, since it allowed the early narrative to be carried by headline coverage before the detailed rationale appeared.

The stated technical motivation was memory bugs. According to Myers' analysis, Bun was accumulating on the order of several memory-bug fix commits per week in its Zig codebase, including use-after-free errors. The team concluded that Rust's borrow checker offered a structural solution to this class of problem, and that rewriting in a Rust codebase that leans heavily on unsafe — which allowed a largely mechanical, file-by-file migration — was the most viable path forward.

One detail Myers flags as notably honest: the rewrite targeted Rust that makes extensive use of unsafe, not idiomatic safe Rust. That distinction matters. unsafe Rust interoperates with C-like patterns more freely and made the mechanical port possible, but it does not provide the full memory-safety guarantees that underpin Rust's reputation. Myers frames this as a first-pass migration, with deeper architectural redesign planned in later phases — a nuance largely absent from the headline coverage.

Andrew Kelley's Counterargument: Bad Engineering, Not a Bad Language

Zig creator Andrew Kelley — whose response Myers describes as unusually blunt — offered a sharply different diagnosis. Rather than accepting the premise that Zig was inadequate for Bun's requirements, Kelley argued (as reported by Myers and in community discussion) that the codebase was in poor shape because of the team's own engineering decisions, with heavy reliance on AI agents to write and review code cited as a central contributing factor.

As Myers summarizes it, Kelley's position is that Bun's code problems trace back to the team's engineering choices — in particular, overusing AI agents to write and review code across the codebase — rather than to any deficiency in Zig itself. (This is Myers' characterization of Kelley's stance rather than a verified direct quotation from Kelley.)

Kelley also reportedly characterized the internal team environment — drawing on community sources rather than firsthand knowledge — in strongly negative terms, along the lines of poor communication, unrealistic expectations, low empathy and inexperience, as summarized in Myers' write-up and community discussion. Some observers labeled Kelley's remarks a "meltdown." Myers disagreed, framing Kelley's willingness to speak plainly as a positive, and describing himself as newly sympathetic to Kelley's stance on the grounds that some situations need to be called out.

There's a practical irony at the center of Kelley's critique. The Zig project maintains a stated policy against accepting AI-generated contributions to its own codebase — a direct contrast to the heavily AI-driven contribution model used in Bun's rewrite. The same AI-first workflow that is being showcased as evidence of agentic coding capability is, in Kelley's view, the root cause of the code-quality problems that made the rewrite feel necessary in the first place.

The community reaction captured a certain nervous humor. Myers relays that at least one developer, Dax — a maintainer of a substantial open-source Zig codebase — joked, half in earnest, about the prospect of Kelley turning a similarly blunt eye toward their own project next.

Myers' Third Reading: A Marketing Story Dressed as a Technical Decision

Ray Myers — who describes himself as both a user of Anthropic's models and, through his own work on coding agents, a competitor to Claude Code — positions himself as an informed but independent observer. His analysis proposes a third narrative that sits outside both the pro-rewrite framing and Kelley's.

Myers' argument, in his own framing, runs roughly as follows: faced with a legitimate memory-bug problem, the team had several viable options, and management approved the Rust rewrite in large part because it was an attractive opportunity to showcase new AI coding capabilities — helped along by the fact that Anthropic already works in Rust and that the Zig project is openly opposed to AI-generated contributions. That, Myers contends, may make sound business sense, but it is not the same thing as a clean technical-decision story.

Myers is careful to concede that the memory-bug problem was genuine — nobody fabricated the issue. His argument is that the choice of which solution to pursue was shaped by factors beyond pure technical merit: the opportunity to publicly demonstrate agentic coding capabilities, existing organizational familiarity with Rust, and a Zig project culture that is openly hostile to AI-generated contributions.

The financial context sharpens the point. Across 2025, multiple news outlets reported that Anthropic raised capital at valuations climbing into the hundreds of billions of dollars — figures reported in the range of roughly $180–$350 billion depending on the round and the report — while the company remained unprofitable and was frequently discussed as a future IPO candidate. (Readers should treat any single valuation number as a point-in-time press report rather than a fixed, confirmed fact.) That situation, Myers argues, creates structural pressure to validate a specific narrative: that AI agents can now handle tasks as complex as rewriting a major production runtime. In his framing, every headline reading "Anthropic rewrites Bun at the speed of AI" is worth real money to that investor story.

Grading Bun's Technical Writeup: What Was Left Unsaid

Myers applies a structured evaluation to Bun's official post-migration explanation, assessing it against three criteria he considers essential for a credible architectural decision document:

Criterion	Bun's Writeup	Myers' Assessment
What is the motivation?	Memory bugs clearly explained	✅ Adequate
What options did you consider?	Mentioned but thinly explored	⚠️ Partial
What are the pros and cons of the chosen option?	"Bun is better in Rust" framing — upsides emphasized, trade-offs largely absent	🚫 Missing

The missing trade-off discussion is Myers' central technical objection to the writeup. The "Bun is better in Rust" section, in his reading, lists mostly positives — and appears to pad the count by including improvements made after the rewrite that have little to do with the migration itself. When a technical writeup omits pros and cons, Myers warns, it strongly suggests a decision made first and justified afterward.

He holds up Richard Feldman's documentation of the decision to move the Roc compiler from Rust to Zig as a strong example of this kind of writing — a move Myers says initially surprised him, but one that ultimately persuaded him because it engaged seriously and specifically with the trade-offs on both sides. The contrast is pointed: a decision to move to Zig was argued rigorously; a decision to move away from Zig, at least in this case, was not.

Myers also argues that Bun's team never seriously tried the available alternatives. Bun's own post references TigerBeetle's TigerStyle guide — a Zig-oriented discipline that explicitly addresses use-after-free by constraining dynamic memory allocation after initialization — and Google's C++ style guide as examples of the style-guide approach to memory discipline. Yet Bun chose not to pursue this path, despite having previously gone so far as to fork the Zig compiler itself to improve build times. Myers' implication is pointed: a team willing to fork a compiler is certainly capable of writing and enforcing a style guide.

The Engineering Culture Problem Behind the Code Quality Problem

Myers connects the code-quality issues to a broader workplace-culture critique. He references public recruiting language from Oven that, as he characterizes it, warned prospective hires about the intensity and pace of work — framing the early phase of the company as a demanding "grind" and cautioning that candidates who prioritize substantial non-working time might not be a good fit. (This reflects Myers' summary of that recruiting material rather than a verbatim quotation.)

Myers' response is direct: sustained "crunch time," he argues, is bad for both health and productivity, and he characterizes this as a well-established finding about knowledge work. He points readers toward the human-factors research summarized in Hillel Wayne's writing on empirical software engineering for supporting evidence. His argument is that crunch culture, combined with a heavily AI-driven contribution workflow and limited code-review discipline, created the conditions in which a codebase accumulates memory bugs quickly — and that this would likely have been true regardless of the implementation language.

That is Kelley's point translated into organizational terms: the language did not cause the bugs; the process did. Switching languages without fixing the underlying process may simply relocate the problem rather than solve it.

The Wider Stakes: Anthropic's Narrative and What It Costs Zig

Myers raises a concern that extends well beyond the immediate technical dispute. A large, well-capitalized AI company with an IPO narrative dependent on demonstrating transformative capability has an enormous megaphone relative to an independent open-source language project. If the public story of the Bun rewrite solidifies as "Zig wasn't safe enough, AI fixed it with Rust," that framing carries real reputational consequences for a language community that had no say in the engineering decisions that produced the bugs in the first place.

Myers' own work during the writing of his piece adds a provocative data point: using what he describes as a hybrid human-AI approach under a project he calls Project Bunsen, he says he identified dozens of bugs (he cites roughly 50) in the Zig version of Bun. The implication is that thorough, rigorous analysis — not a wholesale language rewrite — might have surfaced and addressed the exploitable issues that automated review missed. As Myers puts it, the AI-driven review embedded in the migration process was not strong enough to reliably catch a use-after-free.

The broader argument Myers makes is that this style of AI-first development — more agents solving the problems that agents introduce, tokens replacing tools, SKILL.md files standing in for skill — works against sound engineering practice. As he frames it, the pattern substitutes buying tokens for building better tools, pasting a SKILL.md for actually learning skills, and calling a set of parallel agent sessions a "team" in place of the human dynamics that real software teams depend on.

He is not arguing against AI-assisted development as a category; he describes himself as deeply invested in making that technology work well. His specific objection is to what he calls the "Dark Software Factory" — an all-agent, minimal-human-oversight production model — being promoted as a desirable ideal when evidence from projects like Bun suggests it can produce brittle codebases requiring expensive and disruptive rescue operations.

Key Takeaways

• The Zig-to-Rust rewrite of Bun was real, and the memory-bug problem was real — but the choice of a full rewrite over other remediation strategies was shaped by business incentives, not purely technical ones, according to Myers' analysis.
• Zig creator Andrew Kelley's core argument, as summarized by Myers, is that Bun's codebase problems stem from engineering culture and AI overuse, not from any limitation of Zig as a language.
• The rewrite leaned heavily on unsafe Rust, not memory-safe idiomatic Rust — a nuance absent from most coverage and significant for honestly evaluating the memory-safety claims made on its behalf.
• Bun's official technical writeup falls short of Myers' standard for credible architectural decision documentation: it explains motivation adequately, explores alternatives only partially, and largely omits trade-offs.
• Anthropic's financial position — large amounts of capital raised at valuations reported into the hundreds of billions, and an IPO story dependent on demonstrating AI's transformative capability — creates, in Myers' view, a structural incentive to produce and amplify narratives like this one.
• Zig's reputation faces collateral damage from a marketing story built around a codebase that Kelley and Myers argue was poorly maintained regardless of language choice.
• Myers reports identifying roughly 50 bugs in the Zig version of Bun using a hybrid human-AI approach (Project Bunsen), suggesting rigorous analysis — not language replacement — may have been a viable alternative path.
• Alternatives were not seriously attempted, in Myers' reading: no enforced style guide, no targeted architectural restructuring, despite Bun having previously forked the Zig compiler — a far more invasive intervention — purely for build-performance gains.

What Comes Next

The Bun rewrite has already shipped. The Rust port is now mainline, and the Zig version is history. The immediate technical question is settled. What remains actively contested is the narrative — and that contest matters, because it will shape how engineering teams evaluate AI-assisted development workflows, how language communities attract contributors and production adoption, and how investors weigh whether AI-capability stories reflect engineering reality or engineering theater.

Kelley's willingness as Zig's creator to call this situation plainly — to name the business incentives, the process failures, and what he sees as marketing sleight of hand — has at minimum forced a more nuanced public conversation than the original headlines allowed. Myers' analysis adds the structural critique: the companies best positioned to tell the story of AI's capabilities are also the ones with the most to gain financially from that story being believed and repeated. Until independent technical audits — like Project Bunsen — become standard practice for evaluating high-profile migration narratives, the loudest marketing voice will keep drowning out the more complicated signal coming from the codebase itself.