Post

The Zig project's rationale for their blanket ban on AI-assisted contributions makes a lot of sense to me - for them, time spent reviewing PRs isn't about the code, it's about growing new contributors for the future of the project simonwillison.net/2026/Apr/30/...

simonwillison.netThe Zig project's rationale for their firm anti-AI contribution policyZig 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 …

24 reposts190 likes

if llm-assisted contributions are reliably high quality, the relevant skill being demonstrated is prompt/harness engineering + judgment + verification. the contributor is demonstrating they can ship correct zig code.

It makes sense, but within a year they're going to have to make a tough decision on whether to fight back hackers with AI with humans, that's not a good idea.

I have mixed feelings here. In OSS infra projects, review time is often mostly about checking hidden edge cases and long tail maintenance, and AI PRs tend to spike both unless the author can explain every tradeoff.

I particularly appreciate how this rationale isn't based on the idea that LLM code is of poor quality compared to code written by hand - the quality of the code isn't the deciding factor at all here

I don't see this solution as a long term one, even though I respect the goals. There are great developers now with great ideas expressed through an AI mechanism. There will be more and more. We'll have to evolve the mutual human respect and community piece as we go, including AI.

I guess I don't see the natural way to draw hard lines, or why. Why is a PR specifically sacred? There's definitely something human and community-oriented we want to preserve. The common purpose of open source dev or many endeavors is intrinsically human. How to retain that is the question.

As ever the essential problem in the world is finding people who can think clearly to solve problems, see the larger complex picture and cut through it, maybe even find a simpler approach it. People who cannot do that will be poor supervisors of AI effort. There's a reason fizzbuzz cuts chaff.

For a project that already has a critical mass of devs contributing and real velocity, this seems reasonable. For other projects, where the vision outstrips the coding resources, or where the end products aren't tools for developers, this seems like a less viable option.

This argument is going to age poorly IMO. Are maintainers pairing with newbies to answer questions and show how to be successful in the project? Are the docs beautifully written for beginners in multiple languages? Moreover, if its the person who matters, why are we judging the tools?

They need self-starters, they're too thinly staffed to hold hands. Different needs apply to different projects and that's clearly their situation.

It’s expounded upon in one of the links, and IMO they’re quite rational in policing this way, at least for now. And I suppose it stands to reason that if s contributor successfully lies about significant LLM use but also is an excellent contributor who can be trusted, then the tech has made it!

But it’s definitely not true today and there’s many steps for AI yet to take before it could be used effectively like that. I would also posit that once (or if) we reach a state like that, software dev will be so different anyways that Zig itself may just go obsolete.

It is a context sensitive position and context is rapidly changing, but everyone has their own context. It makes me more likely to invest serious time contributing, if I were interested in the project. I see it as more a social construct than a technical one.

Death by fork is always a possibility in open source, and sometimes a necessity. The future is not preordained and will be different for different projects.

Maintainers invest real time engaging with the humans behind PRs, helping newcomers learn and feel part of the project. If the “contributor” is just a proxy for AI, that value disappears. This argument is only going to get stronger.

Nah, this response seems like something carefully crafted not to trigger stronger responses from pro-AI devs. They don't even allow using LLMs for translation, their position is clear

The translation thing struck me as a response to one of the most common objections to their blanket ban I don't like it, but I respect it as being consistent with their overall position

the last line… i’ve found that i prefer LLM bug reports, not PRs. Because a bug report lets me stay in control over the approach and design, and like you say, it’s about the same amount of time

A PR is a code centric, semi-structured artifact to propose and discuss changes to code: bug reports, code suggestions, etc. They contain strictly less information than bug reports. The issue is quality, no matter the author. Someone might have spent 1B tokens finding a corner case in your code.

I've landed a couple of small patches to the zig stdlib. They're easily the most friendly and helpful open source project I've encountered.