Why the Zig Project Strictly Bans AI Contributions: Investing in People, Not Code

The Strictest Anti-AI Policy in Open Source

The Zig programming language project has the strictest anti-LLM policy among major open source projects today. Its code of conduct explicitly states:

LLMs must not be used to submit Issues
LLMs must not be used to submit Pull Requests
LLMs must not be used to post bug tracker comments, including translations

Zig is a systems-level programming language created in 2015 by Andrew Kelley, positioned as a "better C." Its design philosophy emphasizes readability, debuggability, and precise control over low-level hardware, while eliminating the implicit behaviors in C/C++ that easily lead to security vulnerabilities (such as implicit type conversions and undefined behavior). Zig doesn't use garbage collection, can directly call C's ABI and header files, and ships with a toolchain capable of compiling C/C++ code. It's precisely because of this ambition to "rethink systems programming from the ground up" that the Zig project demands an extremely high level of technical depth and philosophical understanding from its contributors — an important prerequisite for understanding its anti-AI policy.

In an era where AI-assisted programming is increasingly prevalent, this policy stands out remarkably. Recently, Loris Cro, Vice President of Community at the Zig Software Foundation, published the article Contributor Poker and Zig's AI Ban, detailing the deep logic behind this strict prohibition.

Bun's 4x Performance Improvement and the Awkwardness of Being Unable to Upstream

The most well-known project written in Zig is the Bun JavaScript runtime. Bun is a full-stack JavaScript/TypeScript runtime aimed at replacing Node.js, released by Jarred Sumner in 2022. It chose Zig over C++ for its core engine precisely because of Zig's balance between performance and memory safety — Bun's HTTP server performance significantly surpasses Node.js and Deno in multiple benchmarks, largely thanks to Zig's fine-grained control over low-level resources.

Bun was acquired by Anthropic in December 2025 and naturally makes heavy use of AI-assisted development. Anthropic is the developer of the Claude large language model and one of OpenAI's primary competitors. The Bun acquisition was widely interpreted as a strategic move by Anthropic in AI infrastructure — a high-performance JavaScript runtime is critical for building server-side infrastructure for AI applications. This acquisition also made the relationship between the Bun team and the Zig project delicate: a project owned by an AI company that heavily uses AI-assisted development depends on an upstream language that explicitly bans AI contributions.

Bun maintains its own fork of Zig and recently achieved a 4x compilation speed improvement by adding "parallel semantic analysis and multiple codegen units" to the LLVM backend.

Several key technical concepts need explanation here. LLVM (Low Level Virtual Machine) is one of the most important compiler infrastructures today, used as a backend by compilers for numerous languages including Clang (C/C++), Rust, and Swift — it's responsible for converting high-level language intermediate representations into machine code optimized for specific CPU architectures. "Semantic analysis" is a critical stage in the compilation pipeline, occurring after lexical and syntactic analysis, responsible for checking type correctness, variable scoping, function call validity, and other deep logic. Traditional compilers typically complete semantic analysis serially in a single thread, while "parallel semantic analysis" means splitting this process across multiple CPU cores for simultaneous execution. "Multiple codegen units" parallelizes the final machine code generation stage as well. These two optimizations combined can deliver near-linear compilation speed improvements on multi-core processors — this is the technical foundation for Bun's 4x performance gain.

However, the Bun team explicitly stated:

We do not currently plan to upstream this because Zig strictly prohibits LLM-generated contributions.

Interestingly, Zig core contributors also noted that even setting aside the LLM issue, this particular patch wouldn't have been accepted — parallel semantic analysis is a long-planned feature with far-reaching implications for the Zig language itself. The compiler's semantic analysis stage is tightly coupled with the language's type system, generics implementation (called comptime in Zig), error handling model, and other core designs. Any parallelization refactoring requires extremely careful handling of data dependencies and execution ordering, otherwise it could introduce hard-to-reproduce concurrency bugs or alter the language's semantic behavior. But this incident still vividly demonstrates the real-world tension created by the AI ban in practice.

Core Logic: The "Contributor Poker" Philosophy

Investing in People, Not Code

Loris Cro's explanation reveals a profound project management philosophy: The Zig team values the contributors themselves, not the code they submit.

In successful open source projects, maintainers eventually face a situation where the number of PRs exceeds their processing capacity. This phenomenon is known in the open source community as "maintainer burnout" and is a systemic problem plaguing the entire open source ecosystem. The Linux kernel receives over ten thousand patches per development cycle, the Kubernetes project regularly has hundreds of backlogged PRs, and even medium-sized projects often face ever-growing PR review queues. Reviewing each PR requires not only understanding the code's correctness but also evaluating its long-term impact on project architecture, compatibility with other ongoing work, and whether the contributor understands the project's design principles.

Zig's strategy isn't to only accept perfect PRs to maximize return on investment, but rather to help new contributors refine their work as much as possible. This isn't just "the right thing to do" — it's "the smart thing to do."

Every contributor represents an investment by the Zig core team. The primary goal of reviewing and accepting PRs is not to merge new code, but to cultivate new contributors — helping them become trustworthy and productive project members over time. This model isn't unique to Zig in the open source world — the Linux kernel's "subsystem maintainer" hierarchy and the Apache Foundation's "committer promotion" mechanism are essentially about identifying and nurturing core contributors through long-term interaction. But Zig takes this philosophy to its extreme, using it as the core justification for rejecting AI contributions.

Why LLMs Break This Model

LLM assistance fundamentally breaks this investment model. Even if AI helps you submit a perfect PR, the time the Zig team spends on review does nothing to cultivate a confident, reliable contributor.

This is the meaning of "Contributor Poker" — just as in real poker where they say "you play the player, not the cards." In Contributor Poker, you're betting on the contributor themselves, not the content of their first PR.

The Deep Impact of AI-Assisted Programming on Open Source Collaboration

This policy raises a thought-provoking question: If a PR is primarily written by an LLM, why should project maintainers spend time reviewing and discussing it, rather than using their own LLM to solve the same problem?

Current AI-assisted programming tools have deeply penetrated every aspect of software development. GitHub Copilot has over a million paying users, the Cursor editor is rapidly gaining popularity in the developer community, and general-purpose large models like Claude and ChatGPT are widely used for code generation and debugging. According to GitHub's 2024 data, more than a quarter of PRs on their platform contain AI-generated code. Facing this trend, different open source projects have taken starkly different stances: the Linux kernel requires all contributors to take personal responsibility for code but hasn't explicitly banned AI tools, Gentoo Linux explicitly prohibits AI-generated code contributions, while some newer projects actively embrace AI assistance. Zig's position sits at the strictest end of this spectrum.

This chain of logic reveals a fundamental contradiction of AI-assisted programming in open source collaboration:

Broken trust-building: Trust in open source communities is built through repeated interpersonal interactions, and LLMs mediate this process. In traditional open source collaboration, maintainers gradually build trust in a person's technical judgment and reliability by observing how a contributor responds to code review comments, how they articulate design decisions in discussions, and how they handle edge cases. When LLMs intervene in this process, maintainers are actually interacting with an algorithm's output rather than a growing engineer.
Failed skill assessment: Maintainers cannot judge a contributor's true capabilities by reviewing AI-generated code. This is particularly critical in systems-level programming — someone who can get an LLM to generate correct Zig code may not understand the deeper implications of that code regarding memory layout, compile-time evaluation (comptime), or cross-platform compatibility. Yet these deep understandings are precisely what's needed to become a reliable long-term contributor.
Devalued community investment: Time spent on mentoring and feedback fails to translate into actual contributor growth. If a contributor, after receiving review comments, simply feeds the feedback to an LLM to generate revised code, then the maintainer's carefully crafted technical guidance is effectively "training" a large language model's prompts rather than cultivating a human engineer's technical intuition.

Not All Open Source Projects Should Follow Suit

It's worth noting that Zig's strategy has its specificities. As a programming language project still in rapid development, cultivating core contributors who deeply understand the language's design philosophy is crucial. Programming language projects are fundamentally different from typical application software projects: every design decision in a language affects tens of thousands of downstream users, and an ill-considered syntactic sugar or type system change could create irreversible technical debt for years to come. Zig has not yet released a 1.0 stable version (still at 0.x as of 2025), meaning the language's core design is still evolving, and every contribution could have a profound impact on the language's final form.

For other types of projects — such as application-layer projects primarily focused on rapid feature delivery — AI-assisted contributions may be entirely reasonable. For example, a frontend component library for a web application, a CLI tool for data processing, or a documentation translation project derives its core value more from feature completeness and delivery speed than from contributors' deep understanding of underlying principles. In these scenarios, AI assistance can significantly lower the contribution barrier and accelerate project iteration.

But Zig's case provides a clear thinking framework: When an open source project's core value lies in community building and talent cultivation, AI assistance may not only be unhelpful but actually harmful. This isn't technological conservatism — it's a profound understanding of the essence of open source collaboration. It forces the entire open source community to re-examine a fundamental question: Does the value of open source lie in the code itself, or in the people who create it and the collaborative networks they form?

Key Takeaways

The Zig project enforces the strictest anti-LLM policy among major open source projects, banning AI use in Issues, PRs, and comments
Bun (acquired by Anthropic) achieved a 4x compilation performance improvement in its Zig fork, but cannot upstream it due to the AI ban
Zig's core philosophy is "Contributor Poker" — investing in people rather than code, cultivating long-term contributors through PR review
LLM assistance breaks the open source community's trust-building model: maintainers cannot assess a contributor's true abilities through AI-generated code
This policy raises a deeper question: if a PR is written by AI, why wouldn't maintainers just use their own AI to solve the problem