The Real Reason Zig Bans AI Code Contributions: Investing in People, Not Code

The Strictest Anti-AI Policy in Open Source

The Zig programming language project has recently sparked widespread discussion due to its implementation of the strictest anti-LLM (Large Language Model) policy in the open source community.

Zig is a systems-level programming language started by Andrew Kelley in 2015, positioned as a modern replacement for C. Its design philosophy emphasizes readability, debuggability, and precise control over low-level hardware, while avoiding the undefined behavior pitfalls common in C/C++. Zig doesn't use garbage collection, doesn't depend on libc, and can interoperate directly with C code. The Zig Software Foundation (ZSF) is a 501(c)(3) nonprofit organization responsible for maintaining and advancing the Zig language, with an operational model that relies heavily on community volunteer contributors — an important context for understanding its anti-AI policy.

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

This level of strictness is virtually unmatched among mainstream open source projects. What further intensified the discussion was a statement from the Bun JavaScript runtime — as the most prominent project written in Zig, Bun achieved a 4x compilation performance improvement on its Zig fork, yet explicitly stated it would not upstream the code, precisely because of Zig's strict ban on LLM-generated code.

Bun's 4x Performance Improvement and the Upstream Dilemma

Bun is a high-performance JavaScript runtime created by Jarred Sumner, designed to replace Node.js, with its core selling point being extreme startup speed and runtime performance. Bun chose Zig over C/C++ or Rust as its underlying implementation language precisely because of Zig's performance advantages in systems programming and seamless interoperability with C. In December 2025, AI company Anthropic (the developer of Claude) acquired Bun. This acquisition made it inevitable that the Bun team would heavily incorporate AI-assisted tools into their development workflow, directly intensifying the tension with Zig's upstream anti-AI policy.

The Bun team, in their maintained Zig fork, achieved a 4x improvement in Bun's compilation speed by adding "parallel semantic analysis and multiple code generation units" for the LLVM backend. This involves two key stages of the compilation pipeline: LLVM (Low Level Virtual Machine) is compiler infrastructure shared by many modern programming languages (including Rust, Swift, and Zig); semantic analysis is the stage where the compiler checks code for logical correctness, and code generation units (CGUs) are modules that convert intermediate representations into machine code. Traditional compilers typically process these stages serially, while parallelization means processing multiple compilation units simultaneously, fully utilizing the capabilities of modern multi-core CPUs. The Rust compiler previously achieved significant compilation speed improvements through a similar multi-CGU strategy, but such changes often involve deep constraints on language semantics.

However, the Bun team publicly stated: "We currently don't plan to upstream this because Zig strictly forbids LLM-generated contributions." This statement thrust Zig's anti-AI policy into the spotlight.

A detail worth noting: Zig core contributors later clarified 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, requiring advancement as a holistic language-level design rather than accepting an external partial implementation. But this doesn't diminish the value of the 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 explanation for a comprehensive ban on LLM-assisted contributions in his blog post Contributor Poker and Zig's AI Ban.

Investing in People, Not Code

Loris points out that successful open source projects eventually face the problem of PR volume exceeding processing capacity. On platforms like GitHub, external contributors participate by forking repositories, modifying code, and submitting PRs. A maintainer's review of a PR goes far beyond checking whether the code works — it includes code style consistency, architectural design soundness, edge case handling, performance impact assessment, and iterative discussion and revision with the contributor. For resource-constrained open source projects, every PR review represents a significant time investment. Large projects like the Linux kernel and Python receive far more PRs daily than maintainers can handle, so how to allocate review resources is itself a strategic decision.

Faced with this situation, the Zig project's choice is not to reject imperfect PRs to maximize return on investment, but rather to make every effort to help new contributors complete their work, even if they need some assistance to meet the standard.

This is not just "the right thing to do" — it's "the smart thing to do." Zig's primary goal in reviewing and accepting PRs is not to merge new code, but to cultivate new contributors — those who, over time, can become trusted, high-output core members.

Why LLMs Fundamentally Break This Model

LLM assistance fundamentally destroys this investment logic. Even if an LLM helps you submit a perfect PR, the time the Zig team spends reviewing your work cannot help them gain a new, capable, trustworthy contributor.

In Loris's words:

I call this "Contributor Poker" because, as people say about the real card game, "you play the player, not the cards." In Contributor Poker, you're betting on the contributor, not the content of their first PR.

This quote precisely encapsulates the underlying logic of Zig's AI contribution ban: the long-term health of an open source project depends on the growth of people, not the accumulation of code.

A Thought-Provoking Counter-Question

This philosophy raises a counter-question that is becoming increasingly common 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 their own LLM to solve the same problem?

This question cuts to the heart of the matter. Code review in open source projects has never been merely about quality control — it's a bidirectional process of learning and trust-building. While reviewers evaluate code, they're simultaneously assessing a contributor's thinking patterns, technical judgment, and communication skills. When an LLM becomes the intermediary layer, all of this becomes a review of machine output rather than an understanding of a person.

In other words, LLM-generated PRs strip code review of its "people assessment" function. The time maintainers invest cannot be converted into judgment about a contributor's capabilities, which for already resource-strapped open source projects represents a waste.

Not the Only Right Answer, But Internally Consistent

It's important to emphasize that Zig's anti-AI policy is not a universal solution applicable to all open source projects. Different projects have different goals and constraints:

• Projects focused on code output may welcome any tool that improves efficiency
• Projects focused on community building (like Zig) have compelling reasons to limit AI involvement
• Enterprise-led open source projects often prioritize feature delivery speed

What makes Zig unique is that it explicitly places contributor growth above code quality, and implements this priority at the policy level. This approach may mean missing out on quality code in the short term (such as Bun's 4x performance improvement), but in the long run, it protects the project's most core asset — a contributor community with capability and a foundation of trust.

Implications for the Open Source Community

As AI programming tools like Cursor and GitHub Copilot become ubiquitous, every open source project will have to face similar choices. As of 2025, AI-assisted programming tools have formed a vast ecosystem: GitHub Copilot is based on OpenAI's Codex model and can generate real-time code suggestions within IDEs; Cursor is an AI-native code editor deeply integrated with multiple large language models, supporting conversational programming and full-project context understanding; additionally, there are competitors like Codeium, Tabnine, and Amazon CodeWhisperer. These tools have evolved from simple code completion to understanding project architecture, generating complete feature modules, and even automatically fixing bugs. According to GitHub statistics, Copilot users accept approximately 30% of AI-suggested code, meaning a significant amount of code entering open source projects may contain AI-generated components — components that are nearly impossible to reliably identify during code review. This makes Zig-style "total ban" policies face practical challenges at the enforcement level.

Zig's case provides a clear thinking framework: Before formulating an AI policy, first clarify what your project values most.

If the answer is "code," then embracing AI tools is a reasonable choice. If the answer is "people," then limiting AI involvement isn't conservative — it's strategic.

Zig's "Contributor Poker" metaphor tells us: at the open source table, the most worthwhile bet is never on the quality of the current hand, but on the person sitting across from you.