AI Ban in Zig and the 'Contributor Poker' Problem

The Zig project has been one of the few open source projects for months with an explicit, documented stance against AI-generated contributions. Now, Loris Cro, one of its principal maintainers, has published an article that goes beyond the usual arguments about code quality and articulates something more uncomfortable: the problem isn't just what the code does, but what the act of contributing means when AI is involved.

The text, which circulated this week on Hacker News, introduces the concept of contributor poker: the idea that when someone submits a pull request, maintainers are playing a game of asymmetric information. They don't know how much time the author invested, what they truly understand about the problem, or whether they'll be available to iterate if something goes wrong. With AI-generated code, that asymmetry explodes.

What Loris Cro Argues

Cro distinguishes two layers of concern that normally get tangled in these debates.

The first is technical quality. Yes, current models make subtle mistakes, especially in low-level languages like Zig, where memory semantics and the absence of a runtime demand surgical precision. A failure that a more permissive compiler would catch at runtime can here become undefined behavior difficult to trace. This alone would be reason enough for caution.

But the second layer is what gives the article its title: the hidden cost to maintainers. Reviewing code—regardless of its origin—consumes time and attention. When that code comes from someone who generated it in seconds without understanding it deeply, the review effort doesn't decrease; in many cases, it increases. The maintainer must do the cognitive work that the contributor delegated to the machine. And if the PR is rejected or needs substantial refactoring, the total cost of the exchange falls almost entirely on whoever didn't generate the code.

Cro frames it as an incentive problem: AI reduces friction for the contributor, but shifts it—amplified—to the reviewer. In a volunteer-run project with few maintainers, that's not a minor detail.

Why This Discussion Matters Beyond Zig

Zig's policy isn't representative of the open source ecosystem generally. Most projects haven't taken a stance, and some of the largest ones—the Linux kernel included—have chosen not to explicitly ban AI-assisted code, leaving the responsibility to the contributor.

But the conceptual framework Cro proposes does have broader application. Contributor poker describes a dynamic that exists in any project where there's asymmetry between the effort to generate and the effort to review. AI didn't invent that problem, but it scales it significantly because it reduces the marginal cost of submitting a contribution nearly to zero.

This has practical implications for teams maintaining active projects. Not necessarily to ban the use of models—something difficult to verify and potentially counterproductive—but to think about how to structure expectations: must the author be able to explain every design decision? Should PRs come with tests written by the contributor? Should contributions from new participants be size-limited?

Several projects are already adopting these measures informally. Zig has simply made them explicit and taken an additional step by turning it into official policy.

Who This Matters To

The article is of particular interest to three profiles: maintainers of open source projects beginning to notice an uptick in low-cognitive-density PRs; developers who use code assistants and want to understand how their contributions are perceived; and engineering teams defining internal policies on AI use in collaborative workflows.

It's not a technical text in the strict sense—no benchmarks or examples of broken code—but it offers useful vocabulary for a conversation that until now has been conducted rather imprecisely.

---

Here at ClaudeWave, we find Cro's distinction between technical quality and review cost reasonable: they are two separate problems and deserve separate answers. A total ban may be too blunt for many contexts, but ignoring the second layer of the problem—as most public debate does—doesn't help anyone either.