Zig's Anti-LLM Policy and the Bun Fork (Simon Willison)

April 30 2026 post by Simon Willison covering Zig's code of conduct — one of the strictest anti-LLM policies of any major open-source project — and Loris Cro's Contributor Poker and Zig's AI Ban, which articulates the rationale.

What Zig's policy actually says

Three lines, no ambiguity:

No LLMs for issues. No LLMs for pull requests. No LLMs for comments on the bug tracker, including translation. English is encouraged, but not required. You are welcome to post in your native language and rely on others to have their own translation tools of choice to interpret your words.

The translation clause is notable: Zig would rather read a contributor's native language and let other readers translate locally than accept an LLM-translated comment. The principle is about who is on the other end of the keyboard, not what the text looks like.

The Bun fork situation

Bun, the Anthropic-acquired (December 2025) JavaScript runtime, is the largest project written in Zig. Bun maintains its own fork of Zig and recently achieved a 4× compile speedup by adding "parallel semantic analysis and multiple codegen units to the LLVM backend." The diff is public.

Bun explicitly will not upstream this work:

We do not currently plan to upstream this, as Zig has a strict ban on LLM-authored contributions.

This is the cleanest test of the policy yet. The fork is a meaningful improvement to the compiler. It would benefit every Zig user. It cannot be upstreamed because of the way it was produced.

Loris Cro's "contributor poker" framing

Loris Cro, VP of Community at the Zig Software Foundation, frames Zig's reviewing posture as "contributor poker":

In successful open source projects you eventually reach a point where you start getting more PRs than what you're capable of processing. Given what I mentioned so far, it would make sense to stop accepting imperfect PRs in order to maximize ROI from your work, but that's not what we do in the Zig project. Instead, we try our best to help new contributors to get their work in, even if they need some help getting there. We don't do this just because it's the "right" thing to do, but also because it's the smart thing to do.

The reason I call it "contributor poker" is because, just like people say about the actual card game, "you play the person, not the cards". In contributor poker, you bet on the contributor, not on the contents of their first PR.

The argument has two halves:

Reviews aren't free, so they should be investments. A maintainer reviewing a contributor's PR is not just landing code — they are evaluating whether this person becomes the next durable contributor. Imperfect first PRs are fine because the goal is the relationship.
An LLM-authored PR breaks the investment. Even if the PR is perfect, the time spent reviewing it does not produce a new trustworthy contributor — there is no human at the other end accumulating context. So the cost is real and the long-run benefit is zero.

See contributor-poker for the standalone concept.

Simon's gloss

Simon adds an idea he's seen elsewhere: if a PR was mostly written by an LLM, why should a project maintainer spend time reviewing and discussing that PR as opposed to firing up their own LLM to solve the same problem? The asymmetry collapses the value of the PR — the maintainer can produce the same artifact themselves, and only the human relationship is irreproducible.

Why this is the cleanest argument seen so far

Most blanket-LLM-bans in open source have been justified on grounds of:

Code quality — LLMs hallucinate. (Counter: humans do too, and good review catches both.)
Licensing — training data provenance. (Counter: a hard problem to relitigate per-PR.)
Spam — AI-generated noise crowding out real work. (Counter: spam filters exist.)

The contributor-poker argument is different: it doesn't claim the code is bad or the license is dirty. It says the purpose of code review in an open-source project is to grow people, and an LLM PR optimizes for the artifact at the expense of the purpose. That argument survives even if LLMs get better.

Tension with practical use

The Bun fork is the visible cost. A Zig-derived runtime is doing real work on real performance problems with AI assistance. That work cannot flow back upstream under current policy. Whether that's the right call depends on whether you think Zig's primary asset is its compiler quality or its contributor base — and Cro's argument is explicitly that the contributor base is what compounds, not the compiler.

zig — entity page on the language itself
zig-functional-programmers — separate Zig coverage from the Pure Systems blog
contributor-poker — the standalone concept
i-dont-want-your-prs — Dawid Ciężarkiewicz's adjacent post-LLM rethink of open-source collaboration; same ground, different conclusion (drop PRs in favor of forks/discussion)
simon-willison-blog — entity
llm-enshittification — the maximalist version of the anti-LLM-in-FLOSS argument
no-silver-bullet-llms — the productivity-decline version of LLM skepticism
if-ai-writes-your-code-why-use-python — Mitchem flags Zig as on the wrong side of the training-data curve for AI-generated code; the no-LLM policy keeps the gap from closing, which Mitchem treats as a tax and Cro treats as a value
language-choice-for-agents — the concept page on the inverted cost function; Zig's situation is the cleanest counterexample