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 https://simonwillison.net/2026/Apr/30/zig-anti-ai/
Post
Replies:
7
@simon I love your last sentence about the idea: "if a PR was mostly written by an LLM, why should a project maintainer spend time reviewing and discussing that PR as opposed to firing up their own LLM to solve the same problem?"
So good! I think I put it into the contributors.md of my projects.
@simon This looks like a special case of the principle that "people without LLMs" and "people with LLMs" cannot collaborate in the long run.
Different priorities, different skills, different time scales.
@simon If you haven't already seen it, in this thread members of the Zig core team explain why they think their strategy of incremental compilation and backend improvements is better than Bun's changes in the long-term: https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilation-times/15183
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
@simon I don’t think it’s *totally* decoupled from code quality.
Growing a talent pool of people with good judgment has always been more important long-term than the code produced in the short term.
I think this remains true whether the code is written by hand or churned out by LLMs. Arguably *more* important in the latter case.
@simon IMO,
the problem with LLM code isn’t that its quality is *poor* but that it’s *indeterminate* in the absence of review by a skilled person.
I’d say that for engineering purposes though, “poor” and “indeterminate” are close to the same thing.
There’s that old principle that the cost of a bug increases the later it’s discovered. If“writing the code” is also the first review pass, then LLMs seem likely to push more bug discovery to further on in development.
@simon
I had this discussion/reflexion with my colleagues. We miss understood some important details of software practices. One important part was that PR review is much more about sharing knowledge and building collective know-how than "make the code better".
With LLM assistants as a new tool in knowledge workers belt, this pattern of reflecting on what is the work and where are the core values is shifting (for the better I think).
