Simon Willison on Zig's Anti-LLM Policy

Simon Willison wrote up an analysis of Zig's anti-LLM policy, which he describes as being "the most stringent" of any major open source project. He describes Zig's blanket ban on LLM-assisted contributions as structural, not moralistic.

Loris Cro, Zig's VP of Community, frames it as contributor poker: successful projects eventually get more PRs than they can review. Zig deliberately doesn't filter for raw quality at that point; it treats early PRs as bets on a contributor relationship. The review work is the investment they make, the bet they place on each contributor; the payoff is the prolific, trusted participant it sometimes produces: "You play the person, not the cards."

LLM-assisted PRs break that model. Maintainer time spent reviewing the PR doesn't onboard anyone. If the contributor's understanding lives in an LLM session that gets closed after the merge, the project has spent its review budget on something with limited use, and the tail cost when something breaks lands back on the maintainers. The question isn't whether the PR is good. It's whether reviewing it builds anything long-lasting.

This is a sieve in action. The policy filters out a category of would-be contributor, including some who would have been fine apart from their use of AI tooling, in exchange for protecting the investment of knowledge the rest of the developers have created. There's a trade-off here, and Cro is honest about how some good contributors get caught in it. The defense is that Zig has alternatives.

Bun is the proof of how the cost gets spread when the policy holds. Bun, acquired by Anthropic in December 2025, maintains its own fork of Zig and recently landed a 4x speedup on Bun compile by adding parallel semantic analysis and multiple codegen units to the LLVM backend.

Bun will not upstream the work, because the patch is LLM-assisted and thus violates Zig's accepted policy regarding LLM-generated or -assisted code.

Zig is making a bet that, long-term, their project is better off rejecting wins like Bun's even though they are wins. Bun's fine with it because they can absorb the maintenance cost of their local build of Zig.

Zig has a relatively rare problem¹, though: it has a PR oversupply, especially compared to risk and need. The codebase is a compiler, where a bug ripples through everything downstream and the maintainers eat the cost long after the contributor disappears. They have a contributor pipeline they can afford to be picky about. They have downstream users wealthy enough to fork. The sieve catches what the project can afford to lose.

Most venues adopting a similar policy don't have those conditions, and this kind of blanket ban costs them more, proportionally, than it costs Zig.

Reddit's r/java is one example. The subreddit has a no-AI rule, and the rule is reasonable as a reaction to a real problem: AI slop in posts ("I didn't think about this but the LLM phrased my question like so, I like dogs, the recipe for a chocolate cookie is buy a box of Chips Ahoy") and answers in the same vein. That kind of question - and that kind of answer - deserves culling, as it adds very little.

But r/java is a forum, not a project. It doesn't have a contributor pool to protect. It doesn't have a tail-cost problem from a bad merge. Its failure mode is (presumably) degraded discussion, and a blanket ban overshoots that failure mode. People who used AI on a side project and want to mention it are discouraged. People who want to ask a question that an LLM helped them frame cannot. Even a well-written, thorough answer can get met with "this is AI slop," even if no AI helped write it, even if it's absolutely correct commentary. The rule kills legitimate participation alongside the slop it was meant to catch.

The Zig sieve and the r/java sieve look similar from far away. They are not similar in what they cost or what they protect. Zig's sieve protects an iterative game with contributors (making most of them winners, to be fair!) r/java's sieve protects against poor post quality, which is a moderation problem and has better tools: disclosure norms, "show your work" requirements, quality moderation on the actual symptom rather than on the suspected cause. When a community imports Zig's policy without sharing Zig's conditions, it keeps the cost without keeping the value.

The diagnostic, then, is not whether to have an AI policy. It's whether the policy you have is a thought or a reaction. Zig's policy is understandable and proper because Zig has named the cost, named what it's protecting, and is positioned to bear what the sieve catches. A forum copying the same policy without doing that work has taken on the burden without inheriting the conditions that made it bearable.

The right question for any such environment is what its actual failure mode is, and whether its AI policy is calibrated to that failure mode or to someone else's.