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 …

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.

Maybe those developers will be welcome to share their ideas with the Zig team, but not welcome to share a PR with their implementation

0 reposts0 likes

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.

The main difference with a PR is that it represents a significant ask on the time of the maintainers Responding to a suggestion that has an attached proof-of-concept is massively less time consuming than meticulously reviewing, providing feedback on, merging and then maintaining a PR

And I'm going to push back a little bit on the "time of the maintainers concept". That's historically true. But a PR in the LLM era may become a detailed suggestion for change, not a literal patch. An LLM that understands my project priorities can evaluate it and write a real PR for me.

Fair enough. Perhaps we end up with something in the middle between issues/discussions and literal PRs. Or, with the price of coding being much cheaper now, we may see more forking or reimplementing. Fragmentation is also very bad for community. It's a real risk.