Contributor Poker

"Contributor poker" is the Zig Software Foundation's framing for how to allocate maintainer review time, articulated by Loris Cro in defense of Zig's blanket LLM contribution ban. The phrase comes from poker's "play the person, not the cards" — the bet a maintainer makes when reviewing a PR is on the future relationship with the contributor, not the immediate value of the patch.

The argument in shape

Maintainer review time is the bottleneck in any successful open-source project. Once a project gets more PRs than maintainers can process, there are two strategies:

1. Accept only near-perfect PRs. Maximize artifact ROI per minute reviewed. This is what most projects gravitate toward as they get popular.
2. Accept imperfect PRs and help authors fix them. Treat reviewing as investment in growing the contributor base. The early PRs are tuition for a long relationship.

Zig deliberately picks (2). The argument is not that it's nicer; it's that it's the smart long-run move. Every contributor whose first PR was carried over the finish line by patient review becomes someone who can review for the next contributor. The compounding is in people, not patches.

How LLM-authored PRs break this

The investment thesis collapses when the author isn't a person who accumulates skill from the review. Two consequences:

• A perfect LLM PR returns zero on the relationship axis. The artifact is good, but no future contributor has been grown. The maintainer's time was spent on something the LLM could have done unsupervised.
• An imperfect LLM PR returns negative. The maintainer now has to teach the human in front of the LLM what was wrong, but that person didn't write the wrong thing — the LLM did. Feedback doesn't land on the actual author. The cycle doesn't close.

So a maintainer reviewing an LLM PR is paying the same cost as reviewing a human PR but receiving none of the long-run benefit.

Simon Willison's gloss

Simon Willison adds a sharper version of the same argument: if a PR was mostly written by an LLM, why should the maintainer review and discuss that PR instead of firing up their own LLM and solving the problem directly? The maintainer can produce the artifact themselves; only the human relationship is irreproducible. So spending review time on LLM-authored PRs trades something irreplaceable for something the maintainer already has.

When the framing applies

This is specifically about projects whose theory of change runs through people, not artifacts:

• Volunteer-staffed open-source projects whose main bottleneck is maintainer hours
• Projects that need long-tail contributors (no one can fund a full-time team forever)
• Projects with a strong "Zig culture" / "Rust culture" / "Linux culture" identity that takes years to internalize and propagates contributor-to-contributor

It does not obviously apply to:

• Single-vendor open source where contributor growth isn't the strategy (the company employs the contributors)
• Projects whose value is entirely in the artifact and not the community (one-shot tools, dataset releases)
• Projects where review time isn't the binding constraint

Why the framing is durable

Most blanket LLM bans in open source have been justified on quality (LLMs hallucinate), licensing (training data provenance), or spam (AI-generated noise). All three are real but each has a partial counterargument: humans hallucinate too, license problems are hard to relitigate per-PR, spam filters exist.

The contributor-poker argument is structurally different. It doesn't depend on LLM output being bad. It says the purpose of review is to grow people, and an LLM PR optimizes for the artifact at the expense of the purpose. That argument survives even if LLMs become indistinguishable from senior engineers.

Counter-pressures

The visible cost is concrete: Bun's 4× Zig compiler performance fork won't be upstreamed because it was AI-assisted. That's a meaningful improvement that can't flow back. Whether the trade is worth it depends on which asset is the durable one — Zig's view is that the contributor base is, not the current compiler.

Related

• simonw-zig-anti-ai — Simon Willison's coverage
• zig — the language whose policy this defends
• i-dont-want-your-prs — adjacent post-LLM rethink of open-source from a different angle (drop PRs entirely, take prompts and forks instead)
• llm-enshittification — the maximalist anti-LLM-in-FLOSS argument