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

The Strictest Anti-AI Policy in Open Source: What Zig Did

The Zig programming language project has recently sparked widespread discussion with what is arguably the strictest anti-LLM (Large Language Model) policy in the open source community. The rules are blunt and simple:

• No using LLMs to submit Issues
• No using LLMs to submit Pull Requests
• No using LLMs to post comments in the bug tracker, including translations

In 2025, where AI-assisted programming has become a mainstream development tool, this policy stands out sharply. As of now, GitHub Copilot has over a million paying users, AI-native IDEs like Cursor and Windsurf are rising rapidly, and Stack Overflow's 2024 Developer Survey shows over 76% of developers use or plan to use AI programming tools at work. Against this industry backdrop, Zig's blanket ban appears exceptionally contrarian.

What makes this even more intriguing is that the most prominent project in the Zig ecosystem — the Bun JavaScript runtime — has been acquired by Anthropic and is heavily using AI-assisted development. On one side, full embrace of AI; on the other, total prohibition. The contrast is thought-provoking.

What Is Zig: A Systems Language Pursuing "No Hidden Behavior"

To understand why the Zig project made such a radical decision, you first need to understand its background. Zig is a systems-level programming language initiated by Andrew Kelley in 2015, positioned as a modern replacement for C while designed to interoperate seamlessly with C/C++ code. Its core design philosophy is "no hidden control flow" — unlike the extensive implicit behaviors in C++ and Rust (such as implicit type conversions, automatic destructor calls, operator overloading, etc.), Zig requires all behavior to be explicitly visible in the code. Zig also has a unique technical feature: it ships with a toolchain that can directly compile C and C++ code (based on Clang/LLVM), making it an extremely convenient cross-compilation tool. The Zig project is managed by the Zig Software Foundation (ZSF), a 501(c)(3) nonprofit organization that operates on corporate sponsorships and community donations, with a small but exceptionally capable core team. It is precisely this small-team, high-standards operating model that laid the groundwork for its subsequent AI policy.

Why Bun's 4x Performance Improvement Can't Be Contributed Back to Zig Upstream

The Bun team achieved a major breakthrough on their maintained Zig fork: by adding "parallel semantic analysis and multiple codegen units" to the LLVM backend, they improved Bun compile performance by 4x. This should have been a contribution any upstream community would eagerly welcome, but the Bun team explicitly stated:

We don't currently plan to upstream this, as Zig strictly forbids LLM-generated contributions.

Background on Bun and the Anthropic Acquisition

Bun is a JavaScript/TypeScript runtime released by Jarred Sumner in 2022, known for extreme performance, with its core written in Zig (rather than traditional C/C++) — making it Zig's biggest "killer application" to date. Bun's design goal is to be a full-featured replacement for Node.js, integrating a package manager, bundler, test runner, and transpiler. In 2025, AI company Anthropic (the developer of Claude) acquired Bun, a move widely interpreted as Anthropic seeking to build technical advantages in AI code generation and execution infrastructure. After the acquisition, the Bun team began extensively using AI-assisted development workflows, forming a stark contrast with their upstream Zig project's anti-AI stance.

The Technical Significance of Parallel Semantic Analysis

To appreciate the weight of this 4x performance improvement, some compiler fundamentals are needed. LLVM (Low Level Virtual Machine) is today's most mainstream compiler infrastructure framework — outside of GCC, nearly all major programming languages (including Rust, Swift, Zig, etc.) rely on LLVM as their code generation backend. A compiler's work is typically divided into two major stages: the frontend (lexical analysis, syntax analysis, semantic analysis) and the backend (optimization, target code generation). Semantic analysis is a critical frontend step, responsible for checking type correctness, variable scope, lifetimes, and other logical constraints.

Traditionally, Zig's semantic analysis executes serially on a single thread, meaning even on multi-core CPUs, the compiler can only process code units one at a time. The "parallel semantic analysis" implemented by the Bun team allows multiple CPU cores to simultaneously process different code modules, while "multiple codegen units" lets the LLVM backend generate multiple object files in parallel — together, these significantly reduce compilation time. Such modifications touch the compiler's core architecture; any introduction of concurrency can affect the determinism and correctness of compilation results, so the upstream project's cautious stance is reasonable.

This statement quickly sparked heated discussion in the community. Zig core contributors later clarified that even without the LLM policy, this specific patch would not have been directly accepted — parallel semantic analysis is a feature in Zig's long-term roadmap that has profound implications for the language itself and requires a full design discussion process. But the LLM ban was undoubtedly the more newsworthy obstacle, pushing Zig's AI policy into the spotlight.

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

Loris Cro, Vice President of Community at the Zig Software Foundation, provided the most compelling argument for the blanket LLM ban in his blog post Contributor Poker and Zig's AI Ban.

Investing in People, Not Code

In any successful open source project, maintainers eventually face a reality: the number of PRs far exceeds the team's processing capacity. Facing this problem, the Zig project made an unusual choice — rather than rejecting imperfect PRs to maximize ROI, they try their best to help new contributors complete their work, even if they need extensive additional guidance.

This isn't just idealism; it's strategy. In the Zig team's view, every contributor is an investment. The primary goal of reviewing and accepting PRs isn't to merge new code, but to cultivate new contributors, helping them grow through sustained participation into trustworthy, productive project members.

A newcomer's PR today might be full of issues, but if maintainers are willing to invest time in guidance, that person might be independently handling complex compiler problems in three months, and could even become a core maintainer within a year. Zig has done this math very clearly.

The Hidden Costs of Code Review

The key to understanding Zig's strategy lies in recognizing the true cost of PR review. In large open source projects, Pull Request review is far more than "glancing at code and clicking merge." A high-quality code review typically includes: understanding the PR's design intent, verifying the implementation conforms to project architecture standards, checking boundary conditions and error handling, running test suites, assessing regression risk to existing functionality, and engaging in multiple rounds of feedback with the contributor. Data from the Linux kernel project shows that a moderately complex patch averages 3-5 review iterations from submission to final merge. For compiler projects where correctness requirements are extremely high, review costs multiply further. This is why the Zig team views review time as an "investment" — if that time yields a contributor who can independently review others' code in the future, the ROI is enormous; but if the contributor is merely a "mouthpiece" for AI, that investment is completely wasted.

How LLM Assistance Fundamentally Breaks This Model

LLM-assisted contributions break the underlying assumptions of this investment model. Even if an LLM helps you submit a technically perfect PR, the time Zig's team spends on review cannot yield a capable new contributor. The maintainers' energy becomes a sunk cost — feedback goes to a "proxy" that won't grow, rather than a real person who will learn.

Loris compares this strategy to "Contributor Poker":

It's called 'contributor poker' because, like people say about the real card game, 'you play the person, not the cards.' In contributor poker, you bet on the contributor, not the content of their first PR.

In other words, when Zig maintainers review a PR, what they're really evaluating isn't whether the code is good, but whether the person is worth investing in.

A Question Every Open Source Project Should Ponder

Contributor Poker theory raises an increasingly pointed question: If a PR is primarily written by an LLM, why should project maintainers spend time reviewing it rather than using an LLM to solve the same problem themselves?

This question touches on the fundamental contradiction of AI-assisted programming in open source collaboration. When contributors use AI to generate code, reviewers are essentially doing quality assurance on a "proxy's" output. This proxy won't grow from code review feedback, won't build trust relationships in the community, and won't respond to urgent bugs at 3 AM.

For maintainers, reviewing AI-generated PRs is a losing proposition — they pay the time cost without receiving the return of community building.

The "Slop PR" Phenomenon: The Industry's AI Junk Contribution Problem

Notably, Zig is not the only project facing this dilemma. As AI programming tools become widespread, quality issues with AI-generated code are increasingly prominent. GitClear's research report notes that since Copilot's proliferation, "code churn" (the proportion of code modified or reverted within a short period) in codebases has risen significantly. Multiple open source project maintainers have publicly complained about receiving large volumes of low-quality AI-generated PRs that appear well-formatted on the surface but lack understanding of project context, actually increasing maintenance burden. The community has dubbed this phenomenon "slop PRs," analogous to "AI slop" (AI-generated junk content) on social media. Zig's blanket ban is, in some sense, an extreme response to this industry trend.

This Strategy Doesn't Apply to All Open Source Projects

Objectively speaking, Zig's strategy has its specific project context. As a programming language and compiler project, it possesses several key characteristics:

• Contributors need deep understanding of compiler internals
• Code quality and style consistency requirements are extremely high
• The long-term value of cultivating core contributors far exceeds the benefit of short-term code merges
• Project scale allows maintainers to invest personally in each contributor

For other types of open source projects — documentation-driven projects, utility projects, or rapidly iterating application-layer projects — a complete ban on AI assistance may be neither realistic nor reasonable. A documentation project requiring extensive localization and translation might see progress seriously hampered by banning AI-assisted translation.

But Zig's case provides a clear thinking framework: When evaluating AI-assisted contributions, you should consider not only the quality of the code itself, but also the long-term value of the review process for community building. Every project should find its own balance between efficiency and community investment based on its specific circumstances.

Conclusion: The Essence of Open Source Is a Community of People

In an era where AI tools permeate every aspect of software development, the Zig project's stance reminds us of something easily forgotten: open source is not merely an aggregation of code — it is a community of people.

When we focus excessively on efficiency and output, we may overlook the most precious asset in the open source ecosystem — real people who are willing to invest time learning, growing through code reviews, and eventually becoming pillars of their projects. Zig's "Contributor Poker" theory offers the entire open source community a unique perspective for reexamining the nature of collaboration in the AI age.

Whether or not you agree with Zig's approach, this question deserves serious consideration by every open source project maintainer: Is your project investing in code, or investing in people?