Zig's AI ban isn't about code—it's about investing in contributors

In December 2025, Anthropic’s acquisition of Bun—the JavaScript runtime built with Zig—triggered unexpected debate over Zig’s contribution policies. By April 2026, the Bun team announced a fourfold speedup in their Zig compiler fork, touting parallel semantic analysis and multiple LLVM backend codegen units. However, their explanation that Zig’s "strict ban on LLM-authored contributions" prevented upstreaming the changes missed a critical detail: even without the policy, the upstream team had already planned parallel semantic analysis for future releases. The AI ban, in this case, was a convenient excuse to avoid airing technical disagreements publicly.

But the real story behind Zig’s policy runs deeper than a single PR. The project’s stance on AI isn’t about code quality—it’s about preserving the human relationships that sustain open-source development.

The policy’s core principle: communication channels have purpose

Zig’s code of conduct explicitly prohibits LLMs in issues, pull requests, and even translations. The translation clause, in particular, stands out. It’s not about whether AI tools produce better code; it’s about what the project’s communication channels are for.

Loris Cro, Zig Software Foundation’s VP of Community and author of the policy’s rationale, frames this as a core tenet of contributor cultivation. "In contributor poker," Cro writes, "you bet on the contributor, not the cards in their hand." The metaphor underscores a critical insight: even a flawless AI-generated PR doesn’t build a relationship between a maintainer and a new contributor. It only consumes review time.

Why AI-mediated contributions erode long-term value

Cro’s argument hinges on three observations:

• Noise amplification: AI tools encourage low-effort, high-volume contributions—like PRs that fail to compile or 10,000-line patches filled with hallucinations.
• Deceptive practices: Some contributors claim not to use LLMs but rely on them covertly, regurgitating flawed AI responses in discussions.
• Review investment mismatch: The time spent reviewing an AI-generated patch doesn’t translate into mentorship or future collaboration. It’s a sunk cost.

Zig’s approach is the opposite of raising barriers. The project actively lowers thresholds for new contributors, offering guidance even when patches aren’t perfect. But AI tools disrupt that model. A maintainer’s time is finite, and it’s better spent shaping a human contributor than reviewing an AI’s output.

How other projects balance AI and contributor growth

Zig’s stance is extreme but not unique. Several projects have adopted similar policies, reflecting varied priorities:

• NetBSD bars LLM-generated code unless approved by the core team, citing license-compatibility risks from training data exposure.
• Gentoo forbids contributions created with AI tools, citing copyright and ethical concerns—even preemptively, before incidents arose.
• curl blocked AI-generated security reports entirely in 2026 after finding zero valid vulnerabilities in AI-submitted reports over six years.
• Apache Software Foundation allows AI-assisted contributions but mandates disclosure, prioritizing license clarity over outright bans.

These positions reveal a spectrum. Projects with high per-contributor review costs (like Zig or NetBSD) lean toward strictness, while larger ecosystems (like Apache) opt for pragmatic neutrality.

The future of AI in open-source governance

Zig’s policy isn’t about rejecting technology—it’s about defending the social fabric of open source. As AI tools become more pervasive, projects will increasingly face a choice: treat contributors as collaborators or as disposable patch factories.

The real test will come as AI-generated contributions grow more sophisticated. Will maintainers adapt their policies, or will the human element of open-source development become an endangered species? One thing is clear: the projects that survive won’t just optimize for code—they’ll optimize for community.