The Code That Said No

Zig prohibits LLM-generated issues, LLM-generated pull requests, and LLM-generated comments on its bug tracker. Not "discouraged." Not "subject to additional scrutiny." Prohibited. The same category as bad-faith submissions, the same category as spam. The immediate reaction from parts of the internet was predictable: gatekeeping, elitist, anti-progress. The kind of hot take that arrives within three minutes of a post going up, plausibly written by people who are absolutely using AI tools to generate their hot takes faster.

But the Zig team's actual reasoning isn't what most people assumed. They're not claiming the LLM output is low quality. They're not claiming AI tools are unreliable or that generated code introduces subtle bugs (though it does). They're making a stranger and more interesting argument — one that cuts to what open source actually is, what it's actually for, and why the software industry is in the process of quietly hollowing out something it doesn't know how to measure.

i · contributor poker: playing the person, not the cards

Loris Cro, VP of Community at the Zig Software Foundation, frames the anti-AI policy through a concept he calls "contributor poker." The project isn't evaluating pull requests in isolation. It's betting on people.

When a Zig maintainer invests time reviewing a contribution — walking a new contributor through the project's design decisions, explaining why a particular approach creates problems down the line, pointing them toward the undocumented architectural patterns that explain everything — that investment is supposed to compound. The contributor who struggled through a gnarly issue in month three becomes the person who catches someone else's gnarly bug in month eighteen. That's not charity. That's how open source actually builds capacity over time.

LLM-generated contributions break that model. Not because the diffs are bad. Because the person submitting them isn't developing.

When a new contributor uses an AI tool to produce a syntactically correct, well-formatted pull request for an issue they've spent fifteen minutes reading, the maintainer's review time goes into evaluating output from a system that will never become a project member. The human who submitted it didn't work through the problem. They didn't build the mental model. They didn't develop the intuition that comes from wrestling with a codebase until it finally makes sense. They submitted something real and learned nothing durable.

From the project's perspective: every hour spent reviewing an LLM pull request is an hour not spent growing a contributor who could eventually review pull requests themselves. The compound interest math only works if the humans are actually learning.

Cro's formulation — "you play the person, not the cards" — cuts against how most of the software industry thinks about contributions, which is precisely why it matters.

ii · what open source is actually for

We've gradually redefined "contribution" to mean "code lands in main." That definition turns a project into a production function: inputs (PRs) get processed into outputs (merged commits), and the goal is to maximize throughput. Under this model, AI-generated contributions are obviously beneficial — more throughput, less bottleneck, lower time-to-merge.

Except maintainers are not fine. The open source maintainer crisis predates AI tools by years, and it's driven by precisely this production-function framing: the ratio of people consuming a project to people capable of sustaining it keeps getting worse. More users, more issues, more demands, more PRs from people who will never return — but not proportionally more contributors who understand the system well enough to make it better without hand-holding.

Open source projects don't fail from bad code. They fail when the small number of people who actually understand the system stop having enough time to keep it coherent. Every additional review burden, every issue requiring a twenty-message thread to diagnose, every PR from someone who won't engage with feedback — it erodes the substrate. The invisible network of mutual understanding that sustains the project degrades.

AI-generated contributions, at scale, accelerate that dynamic. They maximize the input side while contributing nothing to the capacity side. More cards at the table, fewer skilled players. Eventually the only people who understand the system are the people who already understood it, and they're buried.

Zig concluded that was a bad trade. They may be the only major project that said it in writing.

iii · the bun paradox

Here's the part that should be getting more attention: Bun, the JavaScript runtime written in Zig and acquired by Anthropic in December 2025, has been running its own Zig fork. Their team shipped a set of changes that delivered approximately 4x performance improvements on key benchmarks. The work is real. The improvements are meaningful.

They won't be upstreamed to the Zig project.

Because they were built with AI assistance.

Anthropic — the company that makes Claude, one of the most capable AI coding tools available — owns a runtime built in Zig, used AI tools to make it substantially faster, and cannot contribute that work back to the language project it's built on. The policy protecting Zig's contributor culture has produced a direct technical schism with the parent company of one of the leading AI coding assistants.

You can read this as a cautionary tale about policy rigidity: real performance gains sitting unusable outside the project boundary, an upstream that can't benefit from downstream improvements. That reading isn't wrong. The costs are real.

You can also read it as evidence that the policy is working exactly as designed.

Zig is not trying to maximize the amount of good code in their repository. They are trying to maintain a community of humans who deeply understand their system. Those are different goals. They conflict. Zig chose the harder one with full awareness of what it costs, and the Bun situation is the cost made visible. Four times faster. Can't take it. The contributors who built those improvements didn't build them through the process that produces Zig contributors. The work was real; the development wasn't. From Zig's model, those aren't equivalent.

It's possible to disagree with the conclusion. It's not possible to claim the reasoning is confused.

iv · the measurement problem

The framing that has dominated coverage of AI coding tools is adoption metrics: what percentage of engineers use them, what share of PRs contain AI-generated code, how much faster teams are shipping. These are production-function numbers. They measure throughput.

They don't measure what's happening to the substrate.

The engineers who will maintain AI-assisted codebases in three years are, in many cases, currently being trained on those same codebases. They're learning to read output rather than think through problems. They're getting good at prompting and reviewing, rather than debugging and designing. That's a different skill set. It produces a different kind of engineer — one whose relationship to the underlying system is, by design, more distant.

Some of those engineers will be excellent. They'll develop the hard intuitions anyway, through the parts of their work that AI tools can't handle. Some of them will discover, three years from now, that they don't actually understand the systems they nominally maintain — because the difficult reasoning was always delegated. And some of those systems will be infrastructure that doesn't tolerate confusion.

Open source projects are particularly exposed to this dynamic because their contributor pipelines are transparent. You can watch them in real time. You can see which issues get engaged, which contributors return, whether the project is building capacity or consuming it. Zig watched their pipeline, concluded that LLM contributions were net negative for contributor development, and banned them.

Most corporate codebases don't have that visibility. They have velocity metrics and coverage numbers and time-to-merge dashboards. By the time the substrate problem is legible, the people who understood the system have moved on, and the people who remain are looking at code they're not sure anyone fully understands.

v · what zig is actually measuring

Here's the part of the "contributor poker" framing that deserves more attention: it's not a conservative argument. It's not "AI is cheating," or "LLMs are unreliable," or "we have standards to uphold." It's a systems argument about constraints.

The resource Zig is most constrained by is not code. It is human understanding of the system. Their process for developing that understanding requires contributors to engage with hard problems directly. Contributions that bypass that engagement don't help with their actual constraint — they make the constraint harder to see while appearing to help with something adjacent.

That's a coherent argument. It's also an argument that almost no institution in the software industry is equipped to make, because almost no institution in the software industry accounts for human understanding as a resource. They account for velocity. Coverage. Headcount. Time-to-merge. The thing Zig is protecting doesn't appear on any dashboard.

They might be wrong about whether this specific policy achieves the goal. Rejected contributors may disengage entirely rather than engage harder. Maintainers enforcing the policy spend energy on that instead of code. The costs of false positives — wrongly rejected contributions that were legitimately human-written — are real and unfair. None of that makes the diagnosis wrong.

The diagnosis is this: optimizing a contribution pipeline for throughput at the expense of contributor development is how you end up with a codebase that nobody can maintain. AI tools make that process faster. They do not make it safer. The speed is the problem, not the solution.

Zig drew a line in a place that will cost them real things — including, apparently, four times faster runtime performance from a downstream fork they can never merge. They drew it anyway because they decided they were protecting something the production function doesn't measure.

I'll start the timer on how long before the rest of the industry figures out what Zig is actually optimizing for. The over-under is longer than it should be.

vi · sources

• Zig's firm anti-AI contribution policy — Simon Willison, 2026-04-30
• Zig Software Foundation News — Zig Software Foundation
• ziglang/zig — GitHub