The easy version of the Zig story is that an open-source language project has gone anti-AI.

The more useful version is harsher than that. Zig is arguing that review time is too scarce to spend on contributors who outsource the learning loop.

That is what makes the policy interesting. Most debates about AI-assisted coding get stuck on code quality, ideology, or whether maintainers can even tell when a model was involved. Zig's answer goes somewhere else: the point of a first pull request is not only to land code. The point is to find out whether the person behind it is worth investing in.

That framing landed hard on Reddit because it turns a culture-war argument into a resource-allocation argument. Maintainer attention is finite. If a project believes review is really mentorship plus trust-building, then a model-assisted PR can look less like free labor and more like a bad use of reviewer hours.

What is actually verified

Zig's Code of Conduct is unusually direct. It says: no LLMs for issues, no LLMs for pull requests, and no LLMs for bug-tracker comments, including translation.

That policy got renewed attention after Zig Software Foundation vice president of community Loris Cro published an essay on April 29 titled "Contributor Poker and Zig's AI Ban." His core claim is not that all AI use is evil or technically invalid. It is that Zig reviews contributions as part of an iterated relationship.

Cro's term is "contributor poker." In his telling, a healthy open-source project does not just evaluate the patch in front of it. It places a bet on the contributor, hoping the first round of review produces a later contributor who is more trusted, more productive, and better able to own the code after merge.

That logic depends on review producing learning. Cro argues that, in Zig's experience, LLM-heavy contributions have mostly broken that bargain. He describes worthless drive-by pull requests full of hallucinations, huge first-time PRs, and cases where follow-up discussion suggested the contributor was relaying mistake-filled model output back to maintainers. He also says the core team's review bandwidth is already overdrawn, to the point that even good PRs can sit unreviewed.

Those facts are public and direct from the project itself: the anti-LLM rule is in the Code of Conduct, and the maintainer rationale is now on the record in a primary-source essay.

Why this matters beyond Zig

The important part is not whether you agree with Zig's conclusion. It is the model of open source hidden underneath it.

A lot of AI coding talk assumes the bottleneck is code generation. Zig is saying the bottleneck is reviewer time, trust formation, and long-term stewardship. If that is true, then a contribution that saves the submitter effort but produces no durable reviewer-side payoff is not a win.

This is also why the policy reads less like purity politics and more like queue management. Maintainers are making a ranking decision. Given a limited number of reviewer hours, who gets the investment?

That argument is stronger than the usual hand-waving about "AI slop." It explains why a project might reject even superficially decent LLM-assisted work. A clean first PR is not enough if the project believes the person behind it still has not built the context needed for later maintenance, bug triage, or design tradeoffs.

There is also a quiet business point here. Cro says Zig's funding model depends in part on building an ecosystem where contributors improve their systems thinking and become trusted engineers around the project. If that is true, then the anti-LLM rule is not only a moderation preference. It is part of how Zig thinks it sustains itself.

The reaction shows where the fight really is

The Reddit reaction in r/Zig was not mainly about detection. The more interesting comments argued over whether the filter makes strategic sense.

Some commenters backed the project's right to set hard boundaries and said the rule keeps low-context "slop" out of a technical space that already has enough noise. Others raised the obvious counterpoint: if more strong engineers use AI tools routinely, a blanket ban may screen out contributors a project would actually want.

Lobsters had the sharper version of that disagreement. One highly upvoted comment said the real distinction is whether feedback compounds across later contributions. If an LLM-authored PR does not create a better future contributor, the reviewer investment has weak return. Another thread pushed back that this may also block high-value engineers who use AI competently and would otherwise contribute useful work.

That is the real split. Zig is betting that LLM use correlates strongly enough with low long-term contributor value to justify a hard line. Critics are betting the filter is too crude and will repel people a project should want.

What remains uncertain

The policy itself is clear. The harder question is whether Zig's heuristic will keep working.

Cro explicitly leaves room for adjustment as the project learns more. That matters, because the public evidence here is mostly experiential. Zig has described what its maintainers saw in their own review queue, but outsiders cannot independently measure how many good LLM-assisted contributors a blanket ban might exclude.

There is also a difference between the rule's rationale and its enforcement. A hard prohibition can state a project's values, but it does not guarantee that bad contributors disappear or that capable contributors stop using models privately. It mostly changes the project's declared threshold for acceptable participation.

And while the policy got fresh momentum from broader online discussion, some surrounding claims in those discussions are more disputed than the core rationale. The cleanest verified story is still the narrow one: Zig has a strict anti-LLM policy, and a senior project figure has now explained it as a bet on contributor development rather than a simple anti-AI posture.

The practical takeaway

Open source projects are going to keep splitting on this question.

Some will treat AI as a force multiplier and tighten review around output quality. Others will decide that review is fundamentally about growing humans, not grading machine-shaped patches, and they will push the tools to the boundary or ban them outright.

Zig is one of the first major language projects to state that position without euphemism. That is why the Reddit thread mattered. It did not just surface another "AI bad" argument. It surfaced a more uncomfortable claim: for some maintainers, the scarce resource is not code. It is the chance to turn one serious contributor into five years of future value for the project.

If that claim spreads, the next fight over AI in open source will not be about whether the code compiles. It will be about what maintainers think they are reviewing in the first place.

Sources