Post

@simonwillison.net

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 …

@simonwillison.net

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

30/4/26, 1:39 am1 repost69 likes

mhalle.bsky.social

@mhalle.bsky.social

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.

@simonwillison.net

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

mhalle.bsky.social

@mhalle.bsky.social

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.

@simonwillison.net

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

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.

@jeffme.bsky.social

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.

@phillipcarter.dev

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!

@phillipcarter.dev

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.

Axe Ghost. On Steam!

@axeghostgame.bsky.social

I don't know that this is not true today. a completely AI authored pr was accepted into the linux kernel. and we have no way of knowing how many AI contributions are not detected as such.

May be rational in the short run, but the proportion of developers using zero AI tools is rapidly dwindling. You can absolutely set high expectations for contributions without being absolutist and potentially driving away the next generation of contributors.

@xovemnormie.chai.lat

This response is worded like a corporate memo carefully written to hide what they actually belive in

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.

I'm thinking of this very broadly now, relating it to the social and technical and corporate interplays in the early days of @apache.org (apache, fork of NCSA) history and pre-history that I was involved with. Then a big split ended up being licensing. There are opportunities for new licenses here?

@sergio.bsky.col.social

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.