TL;DR
- Contribution Ban: The Zig Software Foundation reinforced its blanket prohibition on LLM-authored issues, pull requests, and bug-tracker comments.
- Downstream Cost: Bun does not plan to upstream a roughly 4x Bun-compile speedup because the LLVM-backend work used AI assistance Zig prohibits.
- Operational Precedent: An Anthropic-owned runtime now absorbs separate-fork maintenance rather than route around the rule, giving Loris Cro’s contributor-poker rationale its first concrete enforcement.
This week, the Zig Software Foundation reinforced its ban on LLMs for issues and pull requests. Anthropic-owned runtime Bun which joined Anthropic last December is already paying the cost. The maker of the JavaScript runtime says it does not currently plan to upstream a 4x improvement to its Bun-compile path because the work used the AI assistance Zig prohibits.
That decision turns an essay of Loris Cro, VP of Community at the Zig Software Foundation, from a cultural manifesto into operational precedent. An AI lab’s own runtime is now the first high-profile downstream project to publicly cite Zig’s rule as the reason for non-upstreaming, and that precedent gives the policy real operational weight rather than only a stated principle.
What Zig’s Code of Conduct Bans
Zig’s policy is categorical and, by design, leaves no room for interpretation.
“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.”
Non-English posts remain permitted when contributors translate their own words. Zig’s foundation draws its line at machine generation, not at machine assistance for non-native speakers expressing their own reasoning. Bug tracker comments, pull request bodies, and review threads must originate from a human, even if a translation tool helps the words cross a language barrier.
A reader can scan the rule in under a minute. Issues, pull requests, and bug-tracker comments fall under one surface area, and Zig refuses to carve out a permitted use even for the translation case that other projects often allow. For contributors used to LLM-assisted tooling, that breadth is the point: the rule covers the artifacts maintainers in practice have to read, not just the code that ships.
Comment translation, summary generation, and rewrite-this-PR-description workflows that pass for housekeeping elsewhere all fall out of scope under the same line. Burden of proof shifts with that breadth: contributors do not have to prove a patch was hand-written, but a maintainer who suspects LLM assistance can refuse the contribution under the same rule, without arguing technical merit.
Loris Cro’s Contributor-Poker Argument
Loris Cro, VP of Community at the Zig Software Foundation, set out the rationale in his essay titled Contributor Poker and Zig’s AI Ban. Cro starts from a familiar tipping point: successful open-source projects eventually take in more pull requests than maintainers can review, and the obvious response is to raise the acceptance bar to maximise reviewer ROI. Zig deliberately keeps that acceptance bar low and helps new contributors land their work, framed as the smart move for the project’s long-term health, not just the kind one.
A central metaphor sits at the heart of that argument.
“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.”
Loris Cro, VP of Community at the Zig Software Foundation (via kristoff.it)
A perfect LLM-authored patch, in that frame, yields nothing for the contributor pipeline because the maintainer’s review effort produces no new trusted human, only landed code that hardly any reviewer can vouch for. Reviewing a stranger’s first imperfect patch is, by Cro’s logic, a long-term bet on the contributor rather than on the patch itself; with a low bar a maintainer can spend hours teaching one new committer and expect a return measured in years, not in merged lines.
Reviewer time gets paid back when that contributor handles the next round of patches without needing the same scaffolding, and Zig gains an additional human whose judgement the rest of the team can trust on later, harder changes.
Against the prevailing open-source response to PR overload, Cro’s argument inverts the usual lever: rather than raising acceptance bars for individual patches, Zig keeps the bar low and removes the tool that produces unvouched volume. LLMs are, in that framing, not a productivity multiplier but the input that breaks the model: if review time is a fixed budget whose purpose is to grow trusted humans, code generated by a tool no human staked their reputation on consumes the budget without paying into it.
By the same logic, raising the bar would only filter for contributors who can already produce polished code on their first try, which the essay treats as the weakest of both worlds: it shuts out the very newcomers a project needs to reproduce its reviewer pool, while doing nothing to slow the LLM-authored throughput. A Lobste.rs discussion of the essay followed, surfacing it to a wider developer audience.
Bun’s Unupstreamed 4x Speedup
A first concrete cost of that policy landed the same week. Bun maintains its own fork of Zig and uses heavy AI assistance in its development. After adding parallel semantic analysis and multiple codegen units to the LLVM backend in that fork, Bun measured a roughly four-fold improvement on Bun-compile times, the build step that produces the standalone binaries Bun ships.
Bun does “not currently plan to upstream” the LLVM-backend work and cited Zig’s strict ban on LLM-authored contributions as the reason. Bun’s AI-assisted gains stay inside its fork while Zig’s contribution rule excludes them from upstream, and both positions sit beside each other without a public dispute. Bun’s acquisition by Anthropic was announced in December 2025. Bun’s restraint is unusual for an AI lab’s own runtime, since a firm that ships AI coding tools is now honouring an upstream rule that excludes its own contributions.
Bun now carries the maintenance cost of a separate compiler line. An LLM-friendly downstream project is not lobbying to soften the rule; it is treating that rule as binding and absorbing the maintenance burden. Every upstream Zig release Bun pulls in is a merge against work upstream cannot accept, and any future compiler-side improvement Bun makes with the same tooling has to be carried independently for as long as the policy holds.
A 4x speedup on this scale is also not an isolated patch: parallel semantic analysis and multiple codegen units are structural changes to the parts of the compiler many downstream consumers would want, so each refinement of those passes raises the diff cost of any future re-merge. For a systems language whose runtime layer is now part of an AI lab’s product portfolio, a public message lands: upstream contribution model and downstream productivity model can run on different rails.
Zig’s Wider Anti-AI Posture
Zig’s contribution rule extends a posture the project already established when it left GitHub in December 2025, citing Microsoft’s AI culture as part of its reason. Where the GitHub move was about platform governance, Zig’s LLM ban is about who and what gets to enter the codebase, and Bun’s non-upstreaming gives the policy its first concrete operational consequence rather than a hypothetical one.
Rather than raising the acceptance bar, the Zig Software Foundation removes the tool that would generate unvouched volume, and Bun has now publicly declined to upstream its 4x Bun-compile gain rather than route around the rule. The next concrete test is whether a second AI-tooling-heavy downstream project publicly cites Zig’s LLM ban for non-upstreaming before the next major Zig release lands in 2026, a step that would confirm the Bun episode as a settled cost of using Zig rather than a one-off.
