Why Does the Zig Project Completely Ban AI Contributions? A Deep Dive into Contributor Poker Theory

While the entire industry is fervently embracing AI-assisted programming, the Zig project has chosen a seemingly contrarian path — a complete ban on LLM contributions. This path points precisely to the most easily forgotten essence of the open-source movement. Zig's anti-AI contribution policy isn't an impulsive decision, but one grounded in a complete philosophy of open-source collaboration.

Just How Strict Is Zig's Anti-LLM Contribution Policy?

Zig currently has one of the strictest LLM usage restrictions among major open-source projects. It not only prohibits using LLM-generated code in Pull Requests, but also bans the use of large language models in issues, bug tracker comments, and even translations.

At first glance, this policy looks like a resurrection of technological conservatism, but a closer examination reveals that its very radicalism exposes an inconvenient truth the industry doesn't want to face: we have virtually zero quality control over LLM-generated content.

Banning even translations may seem like overkill, but it's actually logically consistent — once you allow "partial use of LLMs," the boundary becomes infinitely blurred. Who decides whether a piece of code is "LLM-assisted" or "LLM-generated"? Who audits whether an issue comment has been polished by GPT?

Zig chose the simplest, most blunt, but also most honest approach: a blanket ban. The project encourages contributors to use English but doesn't mandate it, allowing posts in native languages — they want your authentic expression, not AI-polished "perfect" text.

This is nearly impossible to enforce perfectly in practice, but the signal it sends matters more than the policy itself — they want your brain, not your prompt.

Bun and Zig's Ecosystem Conflict: A Parable of Open-Source Fragmentation

Bun is the most prominent project written in Zig — a high-performance JavaScript runtime known for its extremely fast startup speed and runtime performance. In December 2025, Bun was acquired by Anthropic and began heavily using AI-assisted development.

This is one of the most dramatic conflicts in the 2025 open-source ecosystem. Bun used Zig to build its most successful project, was then acquired by an AI company, used AI to significantly improve Zig's compiler — achieving a 4x compilation performance boost through parallel semantic analysis and multiple codegen units — only to discover these improvements couldn't be contributed back upstream.

It's practically a parable about open-source fragmentation.

Bun has stated it doesn't plan to merge improvements upstream, citing Zig's strict prohibition on LLM-generated contributions. But the most telling part is the Zig core team's response: even without the LLM ban, the parallel semantic analysis patches wouldn't have been accepted, because they would alter the language's semantic behavior.

This reveals that the LLM policy is merely a surface-level conflict. The deeper disagreement is that Bun and Zig have fundamentally different visions for the language's future:

• Bun needs a "fast enough compiler"
• Zig needs a "semantically correct language"

The temptation of 4x compilation speed is significant, but if the cost is uncertainty in language behavior, for a systems language whose core philosophy is "no implicit behavior," this trade-off simply doesn't add up.

What Are Semantic Analysis and Codegen Units?

A brief technical explainer: semantic analysis is a critical phase in the compiler responsible for checking the logical correctness of code, including type checking, variable scope verification, and more. Bun accelerated compilation by parallelizing this phase, but parallelization can introduce non-determinism in execution order, potentially affecting language behavior.

Codegen units are the working units during the compiler's code generation phase; splitting into multiple units enables parallel machine code generation. The Rust compiler has a similar mechanism.

Bun's fork is evolving from a "technical branch" into a "directional divergence," and whether this is a blessing or curse for the Zig ecosystem is too early to conclude.

Contributor Poker Theory: The Core Logic Behind Zig's AI Ban

Loris Cro, Community VP of the Zig Software Foundation, wrote a detailed explanation of the reasoning behind the ban, introducing a concept called "Contributor Poker." This is the most incisive articulation of the essence of open-source collaboration I've ever seen, and the most powerful rebuttal to the entire "AI boosts productivity" narrative.

The core logic is this:

Successful open-source projects eventually receive more PRs than they can handle. Faced with this problem, Zig's strategy isn't to quickly reject imperfect PRs, but to help new contributors complete their work.

Why? Because Zig values the contributors themselves, not the contributions. Each contributor represents an investment by the core team. The primary goal of reviewing a PR isn't to merge new code, but to cultivate trustworthy long-term contributors.

It's like a professor spending three hours marking up an essay — the goal isn't just to improve that essay, but to help the student grow from the feedback. If it turns out the essay was written by ChatGPT, the professor's time is completely wasted, because no student grew from that feedback.

LLM assistance completely destroys this model: even if the PR is flawless, the review time the team invested fails to cultivate a new contributor. Maintainers invest the same or even more review time, but sitting across from them isn't a growing human developer — it's a black box that will never "learn."

Why Is It Called "Contributor Poker"?

The name comes from the poker strategy of "reading the player, not the cards." In traditional open source, a rough PR that demonstrates understanding is more valuable than a perfect PR of unclear origin, because behind the former stands a person who can be developed.

The Zig team is betting on the growth potential of contributors, not the code quality of the first PR. This logic feels especially precious in the AI era — and especially fragile.

An Inescapable Ultimate Question

Finally, there's a killer question worth everyone's consideration:

If your PR is primarily written by an LLM, why should a maintainer spend time reviewing and discussing it, instead of just using an LLM to solve the same problem themselves?

This question tears away the last fig leaf of AI-assisted open-source contribution.

In the traditional model, external contributors' value lies in bringing perspectives, time, or expertise that maintainers don't have. But when LLMs become the intermediary, contributors' unique value is flattened — what you can prompt out, maintainers can prompt out too, and maintainers understand the project context far better than you do.

This means LLM-assisted contributions in many cases aren't helping — they're creating additional review burden.

Of course, Zig's stance has its limitations: not all open-source projects have the luxury of cultivating contributors, and many projects lack code rather than people. But Zig's choice proves at least one thing — amid the AI wave, "not using AI" can itself be a deliberate technical decision, not merely fear or conservatism.

---

When everyone is asking "what can AI do for open source," Zig asks a more fundamental question: "Is open source ultimately about writing more code, or about cultivating more people who can write code?" The answer to this will determine whether the open-source movement evolves or alienates in the AI era.