Andrew Kelley — creator of the Zig programming language — published a point-by-point critique of Bun’s AI rewrite on July 9, 2026. By the next morning it was the top story on Hacker News with 985 points and 488 comments. His verdict on Bun’s pre-rewrite codebase: “Hacks on top of hacks.” On the engineer who wrote it: “Jarred was already writing slop well before he had access to LLMs.” This is not a typical OSS complaint — it names names, disputes specific facts, and reveals a formal policy shift triggered by the whole saga.
Five Claims, Five Rebuttals #
Bun’s July 8 blog post frames the Rust rewrite as a technical improvement story: better binary size, better memory, eliminated a class of memory bugs. Kelley’s response takes each claim and asks: was this actually a Rust win, or just work that should have happened in Zig?
On binary size: Bun credited Rust’s LTO. Kelley points out that Zig has supported LTO throughout Bun’s existence — they simply never used it. On testing: Bun’s blog says the test suite was sufficient to validate the rewrite. Kelley’s rejoinder is blunt — if the tests were sufficient to catch everything, why did Bun have so many Zig bugs in the first place? On fuzzing: the blog implies Bun started fuzzing in the Rust era. In calls with the Zig Software Foundation, Bun’s team had said they were not fuzzing anything. On compilation speed: Zig compiles 600,000 lines in 16 seconds cold. Bun’s blog post doesn’t mention Rust compilation speed at all — conspicuously.
The pattern in Kelley’s critique is consistent: the wins Bun attributes to Rust were engineering decisions Bun could have made years ago. They didn’t. That’s not Zig’s fault.
Slop Was Already There #
The harshest line in Kelley’s post isn’t about AI — it’s about what came before it. The Zig team reviewed Bun’s codebase and found it “extremely alarming”: assertions abused as control flow, hacks layered on hacks, no systematic investment in stability. Kelley contrasts this with TigerBeetle — another Zig project — which “put in the time to find and eliminate the bugs” and has a notably different reputation for reliability.
His argument is that AI didn’t introduce sloppiness to Bun. It accelerated existing sloppiness and made it a million lines long. The Anthropic acquisition added another dimension: after December 2025, Zig communities started receiving what Kelley calls “a surge of drive-by slop contributions” from AI enthusiasts who pasted LLM output into forum posts and PRs. “Tasteless” is the word he uses.
However, it’s worth noting Kelley’s post ends with unusual candor. He acknowledges “unprocessed emotions of resentment” and explicitly says he doesn’t wish Sumner ill will. The critique is substantive — but it’s also personal, and he knows it.
Related:[Bun Rust Rewrite Merged: The 13,000 Unsafe Block Problem]
Zig Bans AI — and It’s Not Alone #
Zig’s Code of Conduct now formally prohibits all AI-generated contributions: code, comments, prose, translations, anything brainstormed or debugged with an LLM. Kelley’s reasoning is economic: AI-generated PRs have “negative value, not zero — negative.” They consume limited reviewer time while producing contributors who cannot learn, absorb feedback, or grow into long-term project participants.
In a March 2026 survey of 112 major open-source projects, only four had implemented outright AI bans: Zig, NetBSD, GIMP, and QEMU — 3.5% of the sample. Most projects accept AI-generated code implicitly. Zig is betting that explicitness is worth the friction.
Meanwhile, the HN thread highlights a genuine technical debate the policy can’t settle: does boundary-scoped unsafe Rust actually provide meaningful safety improvement over proven, battle-tested Zig? Proponents say unsafe Rust is at least greppable and containable. Critics note that 13,000 unsafe blocks against uv’s 73 — in a project of comparable scale — is a 181x gap that no amount of test coverage fully explains away.
Can You Trust Code Nobody Read? #
Bun’s +1,009,272 line diff was reviewed exclusively by claude[bot] and coderabbitai[bot]. No human read it. Bun’s defense is quantitative: 1.3 million test assertions, adversarial AI review where separate Claude instances were instructed to find bugs, six-platform CI, 128 additional bugs fixed post-merge. The result is Bun’s most stable release. Claude Code ships on it.
But Kelley’s circular-logic critique cuts deep. If tests are the trust anchor — and the same test suite existed in the Zig era — why did Bun have so many stability issues before? The honest answer might be: the tests got better alongside the rewrite. But that’s different from “tests alone are sufficient to trust a million lines of AI output no human reviewed.” One analysis put it plainly: “The rewrite took 11 days. Trust still has to run in real time.”
Key Takeaways #
- Kelley disputes five specific technical claims from Bun’s blog post — the wins aren’t Rust-exclusive, they were available in Zig and never pursued
- The “slop” accusation predates AI: Bun’s codebase was already hacks-on-hacks before LLMs accelerated the pace
- Zig formally banned AI contributions after the Anthropic/Bun acquisition triggered a wave of low-quality submissions — one of only 4 major OSS projects to do so
- The deeper question isn’t “did the rewrite work” (it did) — it’s what “code review” means when nobody has time or ability to read a million-line AI diff