The Zig project’s rationale for their anti-AI contribution policy

Zig 项目为何推行反 AI 贡献政策

Zig has one of the most stringent anti-LLM policies of any major open source project: No LLMs for issues. No LLMs for pull requests. No LLMs for comments on the bug tracker, including translation. English is encouraged, but not required. You are welcome to post in your native language and rely on others to have their own translation tools of choice to interpret your words.

Zig 拥有主流开源项目中最为严格的反大语言模型（LLM）政策之一：禁止在 Issue 中使用 LLM，禁止在 Pull Request 中使用 LLM，禁止在 Bug 追踪器中使用 LLM 进行评论（包括翻译）。虽然鼓励使用英语，但这并非强制要求。欢迎使用母语发帖，并依靠他人使用各自选择的翻译工具来解读你的内容。

The most prominent project written in Zig may be the Bun JavaScript runtime, which was acquired by Anthropic in December 2025 and, unsurprisingly, makes heavy use of AI assistance. Bun operates its own fork of Zig, and recently achieved a 4x performance improvement on Bun compile after adding “parallel semantic analysis and multiple codegen units to the llvm backend”. Here’s that code. But @bunjavascript says: We do not currently plan to upstream this, as Zig has a strict ban on LLM-authored contributions. (Update: here’s a Zig core contributor providing details on why they wouldn’t accept that particular patch independent of the LLM issue - parallel semantic analysis is a long planned feature but has implications “for the Zig language itself”.)

用 Zig 编写的最著名项目或许是 Bun JavaScript 运行时，该项目于 2025 年 12 月被 Anthropic 收购，不出所料，它大量使用了 AI 辅助。Bun 维护着自己的 Zig 分支，最近在向 LLVM 后端添加“并行语义分析和多个代码生成单元”后，Bun 的编译性能提升了 4 倍。代码在此。但 @bunjavascript 表示：“我们目前不打算将其合并回上游，因为 Zig 严格禁止 LLM 编写的贡献。”（更新：一位 Zig 核心贡献者详细说明了为何即便不考虑 LLM 问题，他们也不会接受该补丁——并行语义分析是一项长期规划的功能，但它对“Zig 语言本身”有深远影响。）

In Contributor Poker and Zig’s AI Ban (via Lobste.rs) Zig Software Foundation VP of Community Loris Cro explains the rationale for this strict ban. It’s the best articulation I’ve seen yet for a blanket ban on LLM-assisted contributions:

在《贡献者扑克与 Zig 的 AI 禁令》（通过 Lobste.rs）一文中，Zig 软件基金会社区副总裁 Loris Cro 解释了这一严格禁令背后的逻辑。这是我目前见过的关于全面禁止 LLM 辅助贡献的最佳阐述：

In successful open source projects you eventually reach a point where you start getting more PRs than what you’re capable of processing. Given what I mentioned so far, it would make sense to stop accepting imperfect PRs in order to maximize ROI from your work, but that’s not what we do in the Zig project. Instead, we try our best to help new contributors to get their work in, even if they need some help getting there. We don’t do this just because it’s the “right” thing to do, but also because it’s the smart thing to do.

在成功的开源项目中，你最终会达到一个临界点，即收到的 PR 数量超过了你的处理能力。鉴于我目前所说的，为了最大化工作投入产出比（ROI），停止接受不完美的 PR 是合理的，但这并不是我们在 Zig 项目中的做法。相反，我们尽最大努力帮助新贡献者完成他们的工作，即使他们需要一些帮助才能达成目标。我们这样做不仅是因为这是“正确”的事，更是因为这是“明智”的事。

Zig values contributors over their contributions. Each contributor represents an investment by the Zig core team - the primary goal of reviewing and accepting PRs isn’t to land new code, it’s to help grow new contributors who can become trusted and prolific over time. LLM assistance breaks that completely. It doesn’t matter if the LLM helps you submit a perfect PR to Zig - the time the Zig team spends reviewing your work does nothing to help them add new, confident, trustworthy contributors to their overall project.

Zig 看重贡献者胜过贡献本身。每一位贡献者都代表了 Zig 核心团队的一项投资——审查和接受 PR 的主要目的不是为了合并新代码，而是为了培养能够随着时间推移变得值得信赖且高产的新贡献者。LLM 辅助完全破坏了这一点。即便 LLM 帮你向 Zig 提交了一个完美的 PR 也无济于事——Zig 团队花在审查你工作上的时间，对于帮助他们为整个项目增加新的、自信的、值得信赖的贡献者毫无帮助。

Loris explains the name here: The reason I call it “contributor poker” is because, just like people say about the actual card game, “you play the person, not the cards”. In contributor poker, you bet on the contributor, not on the contents of their first PR. This makes a lot of sense to me. It relates to an idea I’ve seen circulating elsewhere: if a PR was mostly written by an LLM, why should a project maintainer spend time reviewing and discussing that PR as opposed to firing up their own LLM to solve the same problem?

Loris 在文中解释了这个名称的由来：“我之所以称之为‘贡献者扑克’，是因为就像人们评价真正的扑克游戏时所说的那样，‘你玩的是人，而不是牌’。在贡献者扑克中，你押注的是贡献者，而不是他们第一个 PR 的内容。”这对我来说非常有道理。它与我在其他地方看到的一个观点不谋而合：如果一个 PR 大部分是由 LLM 编写的，那么项目维护者为什么要花时间去审查和讨论这个 PR，而不是直接启动他们自己的 LLM 来解决同样的问题呢？