Bun, the fast JavaScript runtime built on a fork of Zig, achieved 4x improvements on compile times. Those gains will not make it back into the main Zig project. The reason: Zig's outright ban on LLM-generated contributions.
The Zig Software Foundation prohibits using large language models for issues, pull requests, and bug tracker comments. Contributors can write in any human language, but AI-assisted text or code is off the table entirely. Loris Cro, VP of Community at the Zig Software Foundation, explained the thinking in a post analyzed by Simon Willison: "you play the person, not the cards."
The logic behind that phrase is worth unpacking. Zig's maintainers are not primarily trying to land the best individual patch. They're trying to grow people who understand the codebase well enough to maintain it for years. Every hour a reviewer spends on a contribution is, in their view, an investment in that contributor's development. When an LLM writes the code, that investment yields nothing - the contributor didn't learn, and the maintainers could have generated the same code themselves in less time.
Cro frames it as a capacity problem. Maintainer time is the scarce resource. Reviewing AI-written submissions burns that time without building the pool of trusted contributors who can take on more responsibility later. The policy isn't about code quality in isolation - it's about what reviewing contributions is actually for.
The Real Cost Shows Up in Bun
Bun's situation makes the trade-off concrete. The Bun team runs its own Zig fork and has pushed significant performance work, including those compile-time gains. But because Bun's development process doesn't conform to Zig's LLM ban, those improvements won't be contributed upstream. Zig's main codebase misses out on real engineering work because of where the policy draws its line.
This is the tension the policy creates: it filters contributions based on process rather than output quality. A perfectly correct, well-documented patch gets rejected if any part of it touched an LLM. A messy but entirely human-written patch gets reviewed and worked through.
That's a defensible position, but it's worth being honest that it comes with a cost beyond philosophical purity. Projects that don't align with the policy will either fork permanently or not contribute back at all.
What Other Projects Are Watching
Zig is not alone in thinking about this. Open-source maintainers across ecosystems are seeing an increase in AI-assisted pull requests, many of which are plausible-looking but wrong in subtle ways that take expert review to catch. The complaint isn't that AI code is always bad - it's that the review burden increases without a proportional increase in human understanding on the submitting side.
For developers who use AI coding tools like Aider or Claude Code to help write contributions, this is a signal worth taking seriously. Check a project's contribution guidelines before submitting. Some projects will welcome the help. Others, like Zig, have made a principled decision that the process of writing the code matters as much as the code itself.
The Zig policy is an extreme version of a conversation that's just getting started across open source. How projects answer it will shape both who contributes and what gets built.