In December 2025, Anthropic acquired Bun, the JavaScript runtime written in Zig. In April 2026, the Bun team announced a 4× compile-time improvement on their fork of the Zig compiler — "parallel semantic analysis and multiple codegen units to the llvm backend", in their phrasing. They also announced they would not be upstreaming the work, "as Zig has a strict ban on LLM-authored contributions."

The framing landed badly with Zig observers, for two reasons. The first was that the framing made Zig's contribution policy the obstacle. The second, pointed out shortly afterwards by a Zig core contributor in the Ziggit thread, was that the patch had separate engineering reasons it would not have been merged regardless: "Parallel semantic analysis has been an explicitly planned feature of the Zig compiler for a long time", with "implications not only for the compiler implementation, but for the Zig language itself". The AI-ban explanation was, on a closer read, a tidy way of declining to litigate the engineering disagreement in public.

Both readings are useful. They are also both downstream of the actual rationale, which is one of the most carefully argued OSS-governance documents to appear in 2026.

What the policy actually says

The relevant clauses, in the Zig code of conduct under the section heading Strict No LLM / No AI Policy, are three:

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 the surprising one. It is also the one that disambiguates the policy from a code-quality rule. A blanket ban on LLM-mediated communication, including translation, is not a heuristic about whether agentic tools produce good code. It is a stance about what the project's communication channels are for.

Contributor poker

Loris Cro, Zig Software Foundation VP of Community and the author of the rationale post (April 29, 2026 — also discussed at Lobste.rs), gives the policy a name. The argument is short, and the structural moves are worth following carefully.

First, an empirical observation: "the reality of LLM-based contributions has been mostly negative for us, from an increase in background noise due to worthless drive-by PRs full of hallucinations (that wouldn't even compile, let alone pass CI), to insane 10 thousand line long first time PRs." The project has also seen, the post notes, "plenty of PRs that looked fine on the surface, some of which explicitly claimed to not have made use of LLMs, but where follow-up discussions immediately made it clear that the author was sneakily consulting an LLM and regurgitating its mistake-filled replies to us."

Second, and this is where the argument turns: the post asserts that the Zig project's normal answer to contribution overload is not to raise the quality bar. Cro writes that "we try our best to help new contributors to get their work in, even if they need some help getting there." The post explicitly frames this as the smart choice as well as the right one, because the project's primary investment is not the patch on the table; it is the contributor sitting across from the maintainer.

Third: LLM-mediated contribution breaks that arithmetic. Even a perfect LLM-mediated PR has the property that the time the maintainer spent reviewing it was not, in the structural sense, spent investing in a future contributor. It was spent reviewing, and only reviewing.

The metaphor Cro lands on — "In contributor poker, you bet on the contributor, not on the contents of their first PR." — is a tidy compression of the argument. The argument is not that the cards are bad. The argument is that the cards have stopped indexing the player.

Where other projects have landed

Zig's stance is on the strict end of a real distribution. Several other projects have published positions; the cluster of projects that ban LLM-authored contributions outright is concentrated in small-team systems software with high review-investment-per-contributor, but it is no longer a one-project pattern.

The reasons line up across two axes that each project weighs differently. NetBSD and Gentoo emphasise the license-compatibility risk: the concern is that the model has trained on incompatibly-licensed code and might emit it. curl emphasises the volume and signal-to-noise economics of unsupervised AI-generated reports against a small maintainer team. Apache emphasises the legal-clearance pathway and assumes the project can absorb the disclosure overhead. Zig's argument is the only one of the five that is primarily about what reviewing is for, and it is also the only one with the translation clause.

The 2026 argument

The HN thread on the rationale post drew 415 comments, and the structure of the disagreement has settled into a recognisable shape. The strongest pro-policy argument that has come out of testimony in the thread, and from related discussions, is one an HN commenter relayed from a colleague: "We do not need a middleman to talk to AI models. We are not bottlenecked by coding." If the maintainer's bottleneck is reviewing, and the LLM-mediated PR concentrates the reviewing cost without distributing the contributor-development benefit, the asymmetry is structural rather than contingent.

Several variations were aired. One commenter argued, on the structural point, that in any real workload with good processes, code review makes the speed of code generation a moot point. A second made the corollary observation: an LLM that produces code cannot substitute for the verification step, because the verification is where the review-load actually lives. A third, agreeing with the policy in spirit but disagreeing on scope, framed AI as assistive technology — comparing it to a screen reader or a robotic exoskeleton that lets people who otherwise could not contribute become contributors at all.

That last argument is the live one. It is also the one Cro's post does not directly engage. The post is explicit that the policy will produce false negatives: it will reject contributors whose use of LLMs is exactly the careful, iterative, verification-heavy use that the post itself acknowledges produces good code. The policy chooses the false negatives anyway, on the grounds that the contributor-investment problem the project is solving is better served by accepting them.

The crisis-mode reading

One commenter offered a reading worth pausing on: that contributions to free and open-source projects were already in "borderline crisis mode" before LLMs arrived, and the policy is the answer of a project that has done the math on how many active reviewers it has and how many real contributors it can plausibly cultivate per year. From that reading, the policy is not a stand against LLM correctness; it is a triage decision under a constrained reviewer budget.

Another, sharper, reading came from a commenter making the long-term case against: that the next generation of developers will, for better or worse, grow up using AI assistance to write their code, and that none of those developers will ever become Zig contributors under a policy that bans the assistance from the start. The policy may win at contributor poker in the short term, the argument runs, and lose at it on a longer horizon.

Both readings can be right. The question is which becomes load-bearing first.

Coda

The Zig policy is most precisely read not as an anti-AI policy but as a contributor-cultivation policy that happens to forbid the input class most likely to produce contributions that don't grow contributors. Whether the policy is right depends on what the project is for; reasonable projects can disagree about that, and several do, and they are starting to write down which.

The diagnostic over the next eighteen months is whether other mid-tier projects publish similarly reasoned policies — Cro-style arguments grounded in what the project is doing with its reviewer budget — or whether the field instead settles into vibes-based defaults on either side. The Bun-Anthropic-fork story is a small first sample of the new genre: a contribution offered, a policy invoked, a separate engineering reason left politely unspoken. The interesting question is not whether Zig is right. The interesting question is which other projects are now obliged to write down the policy they have been operating without one.