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

The Strictest Anti-LLM 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. In its Code of Conduct, Zig explicitly states:

LLM usage is prohibited in Issues
LLM usage is prohibited in Pull Requests
LLM usage is prohibited in bug tracker comments, including for translations

Zig is a systems programming language created in 2015 by Andrew Kelley, positioned as a modern replacement for C. It emphasizes manual memory management, compile-time computation (comptime), and seamless interoperability with C, while eliminating many of the design flaws in C/C++ that easily lead to security vulnerabilities. The Zig project is managed by the non-profit Zig Software Foundation (ZSF) and follows a fully community-driven development model without direct corporate control. This governance structure is crucial for understanding its anti-LLM policy — ZSF's mission is to maintain the language's long-term health rather than pursue short-term feature delivery speed.

This policy stands out particularly in an era of increasingly widespread AI-assisted programming. The contrast becomes even more striking when we consider that the most well-known project written in Zig — the Bun JavaScript runtime — was acquired by Anthropic in December 2025 and makes heavy use of AI-assisted development. Bun is a high-performance JavaScript/TypeScript runtime released by Jarred Sumner in 2022, known for its extremely fast startup speed and execution performance, and is seen as a competitor to Node.js and Deno. Anthropic is an AI safety company founded in 2021 by former OpenAI Research VP Dario Amodei and Daniela Amodei, known for its Claude series of large language models. A company with AI as its core business taking over a key infrastructure project written in Zig creates a direct and thought-provoking tension between Zig's anti-LLM policy and Bun's development direction.

Bun Achieves 4x Compilation Performance Improvement, But Can't Merge Upstream

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

To understand the technical implications of this improvement, one needs to understand the compiler architecture behind it. LLVM (Low Level Virtual Machine) is a widely-used compiler infrastructure framework, and many modern programming languages (including Rust, Swift, and Zig) use LLVM as a backend to generate efficient machine code. "Parallel semantic analysis" refers to the compiler simultaneously processing multiple compilation units while analyzing source code meaning (type checking, scope resolution, etc.), while "multi-codegen units" means splitting the final machine code generation process into multiple parallel tasks. Traditionally, Zig's compiler uses single-threaded sequential processing, which becomes a bottleneck in large projects. The Bun team's improvement essentially parallelizes multiple stages of the compilation pipeline — a deep modification involving the compiler's architectural foundations, not a simple performance optimization patch.

However, Bun officially stated:

We currently have no plans to upstream this because Zig strictly prohibits LLM-generated contributions.

What you might not have noticed is that Zig core contributors also pointed out that even setting aside the LLM issue, this particular patch would not be accepted — parallel semantic analysis is a long-planned feature with far-reaching implications for "Zig the language itself." Technical decisions and policy positions converge at this point.

Core Philosophy: The "Contributor Poker" Approach

Loris Cro, Vice President of Community at the Zig Software Foundation, provided what is arguably the most compelling explanation for the comprehensive ban on LLM-assisted contributions in his blog post Contributor Poker and Zig's AI Ban.

Investing in People, Not Code

Loris's core argument can be distilled to one sentence: Zig values contributors over contributions.

In successful open source projects, maintainers inevitably face situations where the number of PRs exceeds their processing capacity. When confronted with this, Zig's chosen strategy is not to reject imperfect PRs, but to help new contributors refine their work. This is not only "the right thing to do" but also "the smart thing to do."

The essential purpose of every code review is not just to merge new code, but to cultivate new contributors — helping them gradually grow into trustworthy, productive core project members. This is a long-term investment strategy oriented toward the future. In mature open source projects, this layered trust system has a deep tradition: new contributors start by fixing small bugs, and through repeated PR submissions and reviews, gradually gain greater codebase access, potentially becoming core maintainers. The Linux kernel's "Web of Trust" and the Apache Foundation's "committer promotion" mechanism are typical representatives of this model. Each review is a maintainer's assessment of and guidance for a contributor's capabilities, and the tacit knowledge accumulated in this process — understanding of project architecture, alignment with design philosophy, internalization of code style — cannot be transmitted through documentation.

Why LLMs Break This Cultivation Model

LLM assistance fundamentally dismantles this cultivation mechanism. Even if an LLM helps you submit a perfect PR, the time the Zig team spends on review cannot yield them a capable, trustworthy new contributor. The review process becomes a one-directional resource drain rather than a bidirectional capability-building exercise.

The deeper problem is that LLM involvement makes the "trust signals" that open source communities rely on no longer reliable. Traditional open source communities depend on a series of signals to evaluate contributors: consistency of commit history, quality of discussions in code reviews, depth of responses to issues, and technical understanding demonstrated in mailing lists or forums. These signals collectively form a decentralized reputation system. LLM involvement significantly reduces the reliability of these signals — someone with no understanding of the project's architecture can submit seemingly professional PRs and comments with LLM assistance. This "signal pollution" problem means maintainers can no longer confirm whether the person they're interacting with truly possesses the capabilities they're demonstrating, and the entire trust assessment system faces the risk of failure.

Loris named this strategy "Contributor Poker":

Like the saying about poker, "you're playing the people, not the cards." In contributor poker, you're betting on the contributor, not the content of their first PR.

The Fundamental Contradiction Facing Open Source Collaboration in the AI Era

This policy raises a question worth deep consideration by the entire open source community: If a PR is primarily written by an LLM, why should project maintainers spend time reviewing and discussing it, rather than just launching an LLM themselves to solve the same problem?

This question touches on the fundamental contradiction of open source collaboration in the AI era. The traditional open source model is built on trust networks between people — building reputation through sustained contributions, transferring knowledge through code reviews, and forming consensus through community interaction. LLM involvement blurs these signals.

Embracing AI or Upholding Human-Centricity? Two Diverging Paths

The open source community is currently forming two distinctly different paths:

Embracing AI assistance: Represented by Bun/Anthropic, viewing AI as a productivity tool and pursuing maximum code quality and development efficiency
Upholding human-centricity: Represented by Zig, placing community building and talent cultivation above code output, maintaining the ecosystem for contributor growth

Both paths have their merits. Zig's choice may not apply to all projects, but it provides a clear thinking framework: Is the core asset of an open source project the codebase, or the talent network formed around it?

Conclusion: Sustainable Technical Communities Depend on People, Not Code

Zig's anti-LLM policy is not simple technological conservatism, but a strategic choice based on a deep understanding of how open source communities operate. In an era of increasingly powerful AI tools, this "people-first" commitment appears all the more precious. It reminds us that the sustainable development of technical communities ultimately depends on the growth of people, not the accumulation of code.

Key Takeaways

The Zig project has implemented the strictest anti-LLM policy in the open source community, prohibiting any LLM-generated content in Issues, PRs, and comments
The Bun team achieved a 4x compilation performance improvement on their Zig fork, but cannot merge the improvements upstream due to the LLM ban
Zig's core philosophy is "Contributor Poker" — investing in cultivating contributors rather than acquiring code; LLM assistance breaks this talent development mechanism
The policy raises a deep question: if a PR is written by an LLM, why should maintainers spend time reviewing someone else's AI-generated code rather than just using an LLM to solve the problem directly?
The open source community is diverging into two paths — embracing AI assistance versus upholding human-centricity — and Zig's choice represents long-term thinking about community sustainability