On April 29, 2026, Loris Cro, VP of Community at the Zig Software Foundation, published an essay titled "Contributor Poker and Zig's AI Ban" explaining why one of the more ambitious low-level languages of the past decade refuses to merge anything written with the help of an LLM. Two days earlier, the Bun runtime — acquired by Anthropic in December 2025 — confirmed that a 4x compile-time speedup it had landed in its private Zig fork would not be sent back upstream, because Zig's policy explicitly forbids LLM-assisted contributions and Bun's compiler patches were written with the kind of tooling Anthropic sells.

Two of the more interesting threads in 2026 open-source policy ran into each other this week. The story isn't quite the easy one — the upstream maintainers say the Bun fork wasn't merge-grade regardless — but the structure of the conflict is real, and it is the cleanest live test we have of what happens when a project says no to the tooling everybody else is shipping.

What Zig actually banned

The policy itself is short. The Zig Code of Conduct, as confirmed against the project repository, reads:

• "No LLMs for issues."
• "No LLMs for pull requests."
• "No LLMs for comments on the bug tracker, including translation."

That is the surface area. No "low-confidence" carve-out, no "okay if you disclose it" clause, no "LLMs are fine for boilerplate" softener. If you used an LLM to produce the prose or the diff, the project does not want it.

The pushback in every Hacker News thread is the obvious one: how do you enforce it? Cro's answer is that the project doesn't try to. The point isn't detection. The point is that anyone who reads the rule and shrugs has already opted out of the relationship the project wants to build.

The "contributor poker" frame

Cro's thesis is the load-bearing piece of the post. He argues that maintainers should not think of code review as evaluating one PR; they should think of it as the first hand of a long, repeated game with the same person.

"You play the person, not the cards", he writes. "In contributor poker, you bet on the contributor, not on the contents of their first PR."

Reviewing a clean, AI-assisted patch from someone who can't debug it later teaches the maintainers nothing useful about that contributor. Reviewing a slightly-wrong human patch from a real engineer who will be back next month teaches the maintainers a great deal. Cro is explicit about the trade-off: "from the perspective of contributor poker it's simply irrational for us to bet on LLM users while there's a huge pool of other contributors that don't present this risk factor." The project will lose some good code by saying no. It judges the loss worth it.

The lived experience that turned a preference into a rule, per the post, was a stack of "worthless drive-by PRs full of hallucinations (that wouldn't even compile, let alone pass CI)", the occasional "insane 10 thousand line long first time PR", and a steady drip of cases where "the author was sneakily consulting an LLM and regurgitating its mistake-filled replies". The decision is not ideological. It is about what the maintainers' Tuesday morning looks like.

The Bun fork — what shipped, where it stayed

Bun's announcement, archived in the Ziggit thread, reads: "In Bun's zig fork, we added parallel semantic analysis and multiple codegen units to the llvm backend on macOS & Linux. This makes debug builds of Bun compile > 4x faster, improving internal development velocity."

That work, per WinBuzzer's reporting, was written with AI assistance. Bun stated it would not be upstreaming. Anthropic, which acquired Bun in December 2025 and underwrites the runtime's development, did not comment on the policy mismatch.

The plain reading is too good for a press release: a company whose flagship product is software written with AI cannot send a 4x compile-time win back to the language its own runtime is written in, because that language's maintainers do not accept code written with AI. The tooling Anthropic sells is the tooling that took these patches off the table.

The maintainers' inconvenient counter — the patch wasn't merge-grade anyway

The Loop voice does not award the easy narrative when the technical detail says otherwise. mlugg, a Zig core compiler engineer, responded in the Ziggit thread, and the response is the most interesting paragraph in the whole story.

On the parallel-semantic-analysis side, the Zig team has the work planned — but it requires upfront language-design changes that haven't shipped yet. Bun's implementation skipped those and exhibits non-deterministic compilation: roughly "random failures 30% of the time" in mlugg's characterisation. That is not a port-it-and-fix-the-edges patch. That is a structural divergence the upstream cannot accept on correctness grounds, regardless of authorship.

On the multi-codegen-unit LLVM-backend split, mlugg points out that Zig 0.16.0 already shipped a self-hosted x86_64 backend and incremental compilation that delivers the same 4x compile-time speedup and roughly 300x faster incremental rebuilds. The minor LLVM optimisation Bun's fork chose to refine is a path the upstream had already deliberately moved away from.

Read together: even if Zig's no-LLM rule did not exist, the Bun fork's work would not have been merged in its current shape. The policy reads like the dramatic reason the patch can't go home. The technical truth is that the patch was never going to.

That footnote takes the wind out of the easiest take. It does not take the wind out of the bigger one.

Why this still matters

Two things change because of this week's exchange.

The first is that Zig has now written down a position other projects can copy. A lot of OSS maintainers privately want this rule. Saying it out loud — with a coherent rationale, a metaphor that survives a Hacker News thread, and a VP of Community willing to defend it — gives every other project a template. Expect quiet replicas. "We are adopting Zig's contribution policy" is now a shippable sentence; six months ago it would have been "we are figuring out how to handle AI-assisted PRs."

The second is that downstream forks are a structural cost the AI-assisted runtime market has to plan around. Bun is not the last AI-heavy project that depends on a language whose maintainers prefer the older kind of contributor. Every quarter Bun's fork drifts further from upstream. Every Zig release is a re-merge against work the upstream cannot accept. That is a sentence that costs an Anthropic-owned project a permanent compiler-line headcount, and it is the kind of cost that does not show up in the acquisition memo.

What to watch

1. Whether other Tier-1 OSS projects copy the exact policy text. Rust has had a contentious internal debate about LLM-generated PRs since late 2025. Go has not. If three more major projects publish near-identical anti-LLM clauses by July, the Zig wording becomes the de-facto template — and the conversation moves from "should we?" to "should we make it stricter?"
2. Whether Anthropic ever comments on the Bun–Zig divergence. It is awkward in exactly one direction. A company that sells the future of AI-assisted coding owns a project that has been formally rejected by its own dependency because of AI-assisted coding. The press strategy that resolves this without endorsing either side will be a small case study.
3. Whether the Zig 0.16.0 self-hosted backend lands the 4x win in production builds. The upstream's argument only holds if it ships convincingly. If mlugg's roadmap delivers, the policy looks vindicated — Zig got the same speedup without the fork. If 0.16.0 slips by two cycles, the fork looks prescient and the no-LLM line looks like cosmetics. The benchmarks settle the rhetoric.

The frame everybody reaches for is "AI vs. open source". That isn't quite the shape. What is happening is that one project drew a hard line on contributor quality — measured over years, not commits — and the rest of the industry now has to decide whether the line is wise or just nostalgic. The first downstream fork that has to live with the decision belongs to the AI lab that's also signing the cheques. That is not a coincidence either.