Why Zig Strictly Bans AI Contributions: Investing in Contributors, 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 most stringent anti-LLM (Large Language Model) contribution policy in the open source community. The project's 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 in bug tracker comments, including for translation

Zig is a systems programming language initially developed by Andrew Kelley in 2015, positioned as a modern replacement for C. It emphasizes the controllability of manual memory management while eliminating many bug-prone design flaws found in C/C++—such as implicit type conversions and undefined behavior. Zig's compiler is self-hosted (written in Zig) and can also serve as a cross-compilation toolchain for C/C++. The Zig Software Foundation (ZSF), a non-profit organization, is responsible for the project's long-term maintenance and direction, with a governance model that emphasizes strict control over code quality and project direction by a small, focused core team.

This policy is particularly notable in an era where AI-assisted programming is becoming increasingly common. This is especially striking when we consider that the most prominent project built with Zig—the Bun JavaScript runtime—was acquired by Anthropic in December 2025 and makes extensive use of AI-assisted development.

Bun is a JavaScript/TypeScript runtime created by Jarred Sumner, renowned for its extreme performance, with its core components written in Zig rather than traditional C/C++. Bun chose Zig for its seamless interoperability with the C ABI, compile-time computation capabilities, and a more controllable memory model compared to C++. Anthropic's acquisition of Bun is seen as a significant signal of AI companies investing in developer infrastructure—Anthropic aims to integrate Bun into its AI coding toolchain ecosystem, meaning Bun's development workflow will become more deeply embedded in AI-assisted workflows, forming a stark contrast with the Zig main project's philosophy.

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

The real-world impact of this policy has already materialized. The Bun team, in their maintained fork of Zig, achieved a 4x compilation speed improvement for Bun by adding "parallel semantic analysis and multiple code generation units to the LLVM backend." However, Bun officially stated:

We currently have no plans to upstream this because Zig strictly forbids LLM-authored contributions.

To understand the difficulty of this technical improvement, one needs to grasp the underlying compiler engineering principles. The semantic analysis phase of traditional compilers—checking type correctness, scope rules, lifetimes, etc.—is typically executed serially in a single thread because the symbol dependencies in code form complex directed graphs that are difficult to simply parallelize. Parallel semantic analysis means decomposing these dependency relationships into concurrently processable units, which is extremely challenging from an engineering perspective. LLVM is a widely-used compiler infrastructure framework whose backend is responsible for converting intermediate representation (IR) into target machine code. "Multiple code generation units" refers to splitting LLVM IR into multiple independent compilation units for parallel machine code generation, similar to the codegen-units strategy in the Rust compiler. This optimization can significantly reduce compilation time for large projects but may impact cross-unit inlining optimizations, requiring trade-offs between compilation speed and runtime performance.

You might not have noticed, but Zig core contributors later explained that even setting aside the LLM issue, this specific patch would not have been accepted—parallel semantic analysis is a long-planned feature with far-reaching implications for "the Zig language itself." But the LLM ban is undoubtedly a more fundamental blocking factor.

Core Philosophy: "Contributor Poker"

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

He introduced a concept called "Contributor Poker":

I call it "Contributor Poker" because, as people say about real card games, "you play the player, not the cards." In Contributor Poker, you bet on the contributor, not on what their first PR contains.

This metaphor precisely reveals the core logic of the Zig team: what the project truly values is the contributor themselves, not the code they submit.

The ROI of Code Review Gets Redefined

In successful open source projects, maintainers inevitably face a situation where the number of PRs exceeds their processing capacity. This phenomenon is known as the "maintainer bottleneck" and is a central topic in open source sustainability research. As a project's influence grows, the number of external contributions grows exponentially, but core maintainers' time and energy are finite. Large projects like the Linux kernel, Python, and Rust all face this challenge, and research shows that core maintainers of many prominent open source projects suffer from severe burnout. This is why "cultivating new trustworthy maintainers" is considered a key indicator of open source project sustainability—a project's "bus factor" (how many core members leaving would cause the project to stall) directly determines its long-term health.

The Zig team's response strategy isn't simply rejecting imperfect PRs, but doing their best to help new contributors refine their work. Loris explains:

We try our best to help new contributors get their work merged, even when they need some help to get there. We do this not only because it's the "right" thing, but because it's the smart thing.

Every code review is an investment in the contributor. The primary goal of the core team spending time reviewing and guiding PRs is not to merge new code, but to cultivate new contributors—helping them gradually grow into trustworthy, productive long-term project members.

Why LLM Contributions Fundamentally Break This Model

LLM-assisted contributions are seen as a threat not because of code quality issues. Even if an LLM helps you submit a perfect PR, the time the Zig team invests in the review process cannot help them cultivate new contributors capable of working independently.

The logical chain here is very clear:

1. Review costs are fixed: Regardless of the PR's origin, the core team needs to invest time in review
2. Under the traditional model, there's a double return: Code gets merged + the contributor's abilities improve
3. Under the LLM model, there's only a single return: Code gets merged, but the contributor's real abilities haven't been verified or improved
4. ROI drops dramatically: The team cannot judge whether this contributor can independently take on more complex tasks in the future

As Simon Willison pointed out in a sharp comment: 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?

Simon Willison is the co-creator of the Django web framework and a well-known developer in the open source community who maintains an open attitude toward AI tools. He has created multiple AI-related open source tools (such as the LLM command-line tool, Datasette, etc.) and has long written in-depth blog posts about LLM applications in software development. His comment carries special weight precisely because he is an active advocate for AI-assisted programming, yet can still understand the reasonableness of the Zig team's position—this acknowledgment from the "opposing camp" makes Zig's argument more persuasive and demonstrates that this issue's complexity far exceeds a simple "embrace AI vs. resist AI" binary.

Deeper Implications for Open Source Community Governance

Zig's policy represents an extreme but logically consistent stance. It forces us to rethink the nature of open source contributions: the sustainability of open source projects depends not only on the quantity and quality of code, but even more on the number of capable, responsible contributors in the community.

Of course, this policy also faces real-world challenges. As AI-assisted programming becomes an industry norm, the boundary between "LLM-written" and "LLM-assisted" will become increasingly blurry. There is a vast gray area between a developer using an LLM to generate a code skeleton and then deeply modifying and understanding it, versus simply copying and pasting LLM output. The Bun case already demonstrates that a strict ban may prevent valuable technical improvements from being contributed upstream, creating a de facto project split.

It's worth noting that other open source projects have adopted very different strategies on this issue. For example, the Linux kernel community allows AI assistance but requires contributors to take full responsibility for the code; the Rust project focuses more on code quality itself rather than how it was generated. Zig's choice sits at the strictest end of the spectrum, closely related to its project scale (small core team), language characteristics (systems-level programming demands extreme correctness), and development stage (has not yet reached a 1.0 stable release).

But the Zig team's choice at least reminds the entire open source community of an easily overlooked truth: code is temporary; contributors are the permanent asset. In the AI era, how to balance tool efficiency with community building is a question every open source project needs to seriously consider.

Key Takeaways

• The Zig project has implemented the strictest anti-LLM policy in the open source community, banning any LLM tool usage in Issues, PRs, and comments
• The Bun team achieved a 4x compilation performance improvement on their Zig fork, but cannot upstream the improvement to the Zig main project due to the LLM ban
• Zig's core philosophy is "Contributor Poker"—investing in contributors rather than code, where the primary goal of every PR review is to cultivate long-term trustworthy community members
• LLM-assisted contributions fundamentally break this investment model: even with perfect code, maintainers cannot assess a contributor's real abilities and growth potential
• The policy has sparked deeper discussions in the open source community about how to balance efficiency and community building in the AI era