Why Zig Completely Bans AI Contributions: An Open Source Philosophy That Invests in People, Not Code

The Strictest Anti-AI Policy in Open Source

The Zig programming language project has recently sparked widespread discussion for having the most stringent anti-LLM (Large Language Model) contribution policy in the open source community. The policy explicitly states:

• Do not use LLMs to submit Issues
• Do not use LLMs to submit Pull Requests
• Do not use LLMs to post comments in the bug tracker, including translations

Zig is a systems programming language that Andrew Kelley began developing in 2015, positioned as a modern replacement for C. It emphasizes manual memory management, compile-time computation (comptime), and seamless interoperability with C/C++, deliberately avoiding the implicit behaviors and complex features common in C++ and Rust. The Zig project is managed by the non-profit Zig Software Foundation (ZSF), with core design decisions primarily led by Andrew Kelley himself. This highly centralized governance model allows the project to maintain exceptional design consistency, but it also means every external contribution must strictly align with the core vision—providing important organizational context for understanding the anti-AI policy.

This policy stands out particularly in an era where AI-assisted programming is becoming increasingly prevalent. As of 2025, AI-assisted programming has evolved from an experimental tool into mainstream development practice. GitHub Copilot has over a million paying users, AI-native IDEs like Cursor and Windsurf are rising rapidly, and over 70% of professional developers use some form of AI assistance in their daily work. Against this industry backdrop, Zig's comprehensive ban is especially striking.

The contrast becomes even sharper when we consider that the most prominent project written in Zig—the Bun JavaScript runtime—was acquired by Anthropic in December 2025 and heavily uses AI-assisted development. Bun is a JavaScript/TypeScript runtime released by Jarred Sumner in 2022, marketed for extreme performance, significantly outperforming Node.js and Deno in benchmarks for startup speed, package installation, and HTTP serving. Anthropic's acquisition of the Bun team has been widely interpreted as a strategic move in AI infrastructure—high-performance JavaScript runtimes are critical for server-side deployment of AI applications. The post-acquisition Bun team's heavy use of AI-assisted development tools creates a sharp contradiction with the upstream Zig project's anti-AI stance.

Bun's 4x Performance Improvement and the Upstream Dilemma

The Bun team recently achieved remarkable results on their maintained Zig fork: by adding "parallel semantic analysis and multiple code generation units" to the LLVM backend, they improved Bun's compilation speed by 4x.

To understand the technical significance of this achievement, one needs to understand the underlying compiler architecture. LLVM (Low Level Virtual Machine) is the most widely used compiler infrastructure framework today—Clang, the Rust compiler, the Swift compiler, and virtually all mainstream compilers are built on LLVM, and the Zig compiler likewise uses LLVM as its code generation backend. The optimization implemented by the Bun team involves two key aspects: first, changing semantic analysis (checking type correctness, resolving symbol references, etc.) from serial to parallel execution, fully utilizing modern multi-core CPUs; second, splitting compilation output into multiple independent code generation units, allowing the LLVM backend to generate machine code in parallel. In large projects, the compilation bottleneck is often in LLVM's code generation phase, making this optimization particularly impactful. A 4x compilation speedup means dramatically shorter iteration cycles for developers—a substantial productivity improvement for large Zig projects like Bun.

However, the Bun team explicitly stated:

We currently don't intend to upstream this because Zig has a strict ban on LLM-generated contributions.

This incident thrust Zig's anti-AI policy into the spotlight. As a detail worth noting, Zig core contributors also pointed out that even setting aside the LLM issue, this particular patch would not have been accepted—parallel semantic analysis is a long-planned feature with far-reaching implications for the Zig language itself, involving complex design decisions around compiler internal state management, error reporting order determinism, and a series of other concerns that cannot be covered by a simple performance patch. But this doesn't diminish the intensity of discussion the policy itself has generated.

Core Philosophy: Contributor Poker

Loris Cro, Vice President of Community at the Zig Software Foundation, provided what is arguably the most compelling articulation of the rationale for comprehensively banning LLM-assisted contributions in his article Contributor Poker and Zig's AI Ban.

Investing in People, Not Code

Loris's core argument can be summarized as: Zig values contributors more than contributions. Every contributor represents an investment by the Zig core team. The primary goal of reviewing and accepting PRs is not to acquire new code, but to cultivate new contributors—enabling them to become trusted, productive project members over time.

This philosophy is consistent with the long-standing PR review culture in the open source community. Pull Request review goes far beyond checking code correctness—in mature open source projects, it's a multi-layered socialization process. Reviewers need to assess whether code style conforms to project conventions, whether architectural decisions are sound, whether test coverage is sufficient, and most importantly, whether the contributor understands the project's design philosophy. Long-lived projects like the Linux kernel and PostgreSQL have strict contributor advancement paths: starting with small patches, gradually earning trust, and potentially becoming subsystem maintainers. This "apprenticeship" model is key to the sustainable development of open source projects, and Zig's "Contributor Poker" philosophy is an explicit expression of this tradition.

In a successful open source project, you'll eventually reach a point where you receive more PRs than you can handle. In theory, you should stop accepting imperfect PRs to maximize return on effort, but that's not what the Zig project does. Instead, we try our best to help new contributors complete their work, even if they need some help to meet the bar. We do this not only because it's the right thing to do, but because it's the smart thing to do.

Why LLMs Break This Cultivation Model

LLM assistance fundamentally breaks this cultivation model. Even if an LLM helps you submit a perfect PR, the time the Zig team spends reviewing your work is nearly worthless toward the goal of adding a new, confident, trustworthy contributor to the project.

There's a deep "understanding gap" problem here. Research shows that AI-generated code has systematic weaknesses in security vulnerabilities, edge case handling, and long-term maintainability. More critically, developers may submit functionally correct code yet be unable to explain how it works or how it behaves in edge cases. In open source contributions, maintainers cannot reliably distinguish between "understood then written" and "generated then submitted" through code review alone. When maintainers spend hours reviewing a PR, suggesting changes, and explaining the project's design trade-offs, if the other party simply feeds the feedback into an LLM to generate a new version, the entire teaching process becomes completely ineffective.

Loris named this strategy "Contributor Poker":

I call this "Contributor Poker" because, like people say about actual card games, "you play the player, not the cards." In Contributor Poker, you bet on the contributor, not the content of their first PR.

Fundamental Questions About Open Source Collaboration in the AI Era

This philosophy raises a deeper question increasingly discussed in the open source community: If a PR is primarily written by an LLM, why should project maintainers spend time reviewing and discussing it, rather than spinning up an LLM themselves to solve the same problem?

This question touches on the essence of open source collaboration in the age of AI-assisted programming. When the cost of generating code approaches zero, what is the truly scarce resource? Zig's answer is clear: it's people—the human contributors who understand the project's design philosophy, can exercise judgment, and take on long-term maintenance responsibilities.

This question also exposes intellectual property concerns around AI-generated code. AI model training data may contain code under various licenses, and the copyright ownership of generated content still has no clear legal resolution. For projects that strictly follow open source licenses, accepting AI-generated code of unclear provenance may introduce additional legal risks—a dimension worth serious consideration for open source projects beyond contributor cultivation.

Implications for the Open Source Ecosystem

Not All Projects Should Follow the Same Strategy

Zig's strategy has its unique context. As a programming language project still in rapid development with a limited core team, every code review is a precious opportunity for teaching and screening. For more mature, larger-scale projects, completely banning AI assistance may be neither realistic nor optimal.

In fact, AI policies in the open source community have already formed a complete spectrum. Zig's comprehensive ban sits at one extreme; at the other end, some projects explicitly welcome AI-assisted contributions, only requiring that contributors can explain and maintain their submitted code. The middle ground contains various compromises: the Linux kernel requires all code to be reviewed by humans and signed with a "Developer Certificate of Origin"; the Python community requires contributors to take full responsibility for AI-generated code; FreeBSD prohibits AI-generated content in copyright-sensitive areas. Every project needs to find its own balance point based on its scale, governance model, and development stage.

The Trust and Verification Dilemma

Even without adopting a comprehensive ban like Zig's, all open source projects face a common challenge: how to build and maintain contributor trust in the AI era? When you can't determine whether a contributor truly understands the code they've submitted, both the meaning and methods of code review need to be reconsidered.

The Value of Long-Termism

Zig's approach is fundamentally a long-termist strategy. In the short term, it may miss some high-quality code contributions (such as Bun's 4x compilation speedup). But in the long term, it ensures organic growth of the project's core team and deep understanding of the codebase by every contributor.

In an era of rapidly advancing AI capabilities, Zig's choice reminds us: the sustainable development of technical projects ultimately depends not on the quantity or quality of code, but on the human community behind it—people who understand, maintain, and drive the project forward. This is perhaps one of the most counterintuitive yet thought-provoking insights of the AI era.