I have sympathy for the OSS maintainers, and I don’t see it purely as a “Luddite” behaviour.
I expect the problem isn’t necessarily the AI generation itself, but the difficulty to distinguish between someone that’s really understood the problem domain versus someone with LLM-induced “Dutch courage”.
That in combination with a large uptick in volume of community interactions (issues, PRs, …) risks burning out OSS maintainers.
Perhaps giving it a few months/years for the flurry to die down, and for people to establish better best-practices for using these tools is the motive.
I agree 100%. If you open a PR, you need to add value somehow - having thought about the problem, understanding the code base deeply or just your time by thinking about a solution you can't otherwise get easily.
The problem is that the last part changed drastically with LLMs. You can get a lot of solutions easily by prompting an LLM. But that also means you don't need outside PRs for that anymore, and just prompt the LLM yourself.
That means two things in my opinion:
1) People haven't internalized that yet. For a lot of people, a functioning solution to a problem with often quite a bit of source code is equivalent to "adding value" - because in the past it was. It meant you thought about the problem, understood it and found a solution. But it was that thinking that added the value.
2) The minimum threshold for adding this "quality" rises quite a bit. A lot of problems can now be solved very fast with an LLM by someone who understands the code base well enough. You don't need a PR for that.
I suspect, that means in the future you could both get and need less contributions to OSS projects in general.
If this means that the signal of valued contribution swings from "PRs merged" to "Issues raised with PRs merged" then I'm all for it.
In LLM-friendly repositories it saves everyone's time if the maintainers are the ones steering the machines, and in LLM-unfriendly ones it saves everyone's time by not having generated PRs thrown at the maintainers.
I noticed some of them don't allow *external* AI contributions. Which makes sense -- you can trust the AI code more if it's signed off by someone who knows the project. The main problem is with AI contributions generated by people who are not familiar with the project, who don't understand their goals, architecture and design decisions.
> I expect the problem isn’t necessarily the AI generation itself, but the difficulty to distinguish between someone that’s really understood the problem domain versus someone with LLM-induced “Dutch courage”.
Some of that. Also sometimes there isn't even a person, just a bot opening a pull request that doesn't hear feedback.
There's also the problem that many projects put disproportionate effort into mentoring new contributors and helping them get things right, and that's valuable when there's a human learning something, but not when you're just correcting someone's LLM slop.
And that's leaving aside all the other problems, like "these things took all our FOSS code, ignoring its licenses, and then used it to compete with us and drown us out", or "these things are going to turn us all into paperclips".
Personally, I'd say the right way to use an LLM is to let it review your code, or be your rubber duck helping you design the architecture or evaluate the security model or similar, but not let it write the code for you. (Unless it's truly throw-away code, like "write me some code to benchmark X vs Y to evaluate which is better for my use case". In which case, the point wasn't the code, it was the numbers.)
This is super helpful to pick projects. I really care about human-authored code, quality, and I avoid when possible using tools that are vibe coded. OpenSource projects have always been about sharing knowledge and building things together, and I am a little sad to see that AI and LLMs are taking over.
Recently I was picking a self-hosted tool for planning trips, and I deleted it after a day, because it was extremely vibe-coded and none of the security issues reported in GitHub were ever fixed. It can be a prompt away to fix those! I noticed this way too often in OSS that is vibe coded, people focus on looks, feels and code does not get reviewed enough, because it "looks good with the CSS gradients" and "an LLM is always right".
So I understand why they would ban and forbid AI / LLM contribution, and I am happy they are banning them, I assume mostly for the mental sanity of maintainers and for making sure that knowledge share and somewhat better PR reviews happens. I will always pick a human-made project over an AI / LLM coded one.
Projects like Servo or Redox OS are community-driven and already lack funding. Blocking AI-assisted code will only drive potential contributors away.
Some projects have built strong communities around AI-assisted development. The T3 Code community [0], for instance, is very active, and most PRs are created with LLM assistance.
The real issues are disclosure and taking responsibility for your submissions, including carefully reading and testing your own code. Code written by humans isn't inherently better in any sense.
If someone is only willing to contribute to a project if they are allowed to use LLMs, then I think they don't really care about the project and only about the thrill of being seen as a "contributor"
Some of these are misleading. Immich, for example, doesn't accept PRs created using an LLM, but the project has an agents file and there are Claude co-authored commits in the history.
"Rules for thee, but not for me" makes some sense for OSS maintainers. The maintainer may be comfortable using AI themselves but isn't interested in slop grenade PRs, especially if they accepted PRs fairly begrudgingly in the first place.
And I think that's doing the maintainers a disservice.
"Random strangers, please don't have your agent send us PRs, we don't want to review it" -> yeah, totally reasonable open source maintainer behaviour, doesn't update my perception of the project at all.
"All code in this repo must be written by hand" -> This is probably not a serious project and I'll make a mental note not to depend on it.
If servo is really in the latter camp I'd actually say that's negligent at this point. A browser engine that doesn't have agents scanning for and fixing vulns is totally unacceptable.
"Code must be written by hand" is not at all incompatible with "use agents to scan for vulnerabilities", or for that matter "use agents to find bugs", "use agents to help with profiling to give you data for optimization", or any number of things that aren't writing the code for you.
I believe this will mean that established FOSS software will significantly improve thanks for using AI for catching bugs & human-reviewed code, while commercial programs will become significantly more unreliable due to being 100% AI generated, with a focus on LOC/token quotas instead of any metric of quality.
Silly initiative. All it puts is a target on the repo, and no benefit at all. Atleast let the projects have the option of changing later, rather than publicly branding them.
Author here. This is an early project. I've seen projects banning AI pop up quite a few times on HN and was curious in seeing how large the trend is.
Yes, this is a vibe coded project, I'm simply curious to see how large the trend is, and also look into how people handle writing about AI contributions in their projects.
I do not intend to make any conclusions our of this. The domain name is mostly a pun on "computer says no"
Yes, for good or bad, the entire project itself is vibe coded. I'm only reviewing the ban list manually to ensure correctness.
My main question was how large the trend is, and how it looks like.
Given that LLMs will be increasingly used to make their job harder, it's an odd policy. OTOH, if a core team was inundated with slop PRs and issue reports, it's an understandable response.
I'd expect them to increasingly use AI to figure out the latest obfuscations regardless.
Try clicking on "All projects", the vast majority of projects that this website lists are labelled "restricted". The conclusion that open source "says no" seems somewhat dishonest.
I feel like this is maybe a good thing but for the wrong reasons.
It's pretty clear at this point that AI coding works and is here to stay. But accepting external AI means you have way less knowledge about how it was generated, what models were used, were they given correct instructions etc. And also there's less benefit to accepting AI contributions because you're really receiving just a few minutes of contributor effort, which you could have easily done yourself.
There was a project highlighted recently that doesn't accept PRs at all and the maintainers just run the AI themselves. I expect that's where we're heading. If you want to contribute to open source projects in future it's going to be in the form of money for tokens.
Maybe submit a feature request/bug (prompt) and also pay some money to run the agent.
While limiting AI can make sense and it's particularly important to keep contributors responsible (for example, not allowing pull requests submitted directly by AI), it's outright dangerous to ban the use of AI altogether. Not using AI for vetting code and bug hunting is going to make your software very vulnerable. AI can find bugs in your open source repo that no human might find and you can bet your ass that attackers will use AI to find exploits.
It's only a matter of time until code only written by humans is widely going to be considered unsafe. Sorry if that hurts anyone's feelings but that should be crystal clear to anyone working in the industry.
Is that a bad thing? MANY of these projects ban PRs made with LLMs, without explicitely mentioning being against AI in general. Since AI drastically increases how much code you can write, they might not need LLM contributions from outside - they can just prompt themselves.
In that case, only getting a few, hand written PRs could mean getting fewer, but higher quality contributers.
Other projects might not care about getting many contributers, many stars or being widely used. It might simply be a small project someone wants to code by hand. That's absolutely valid, many people still have fun coding by hand.
The truth is just that there are a lot of slop PRs currently, where ppl just sicced an LLM on a problem, did not validate any findings, did not check the code, did not read the output and just acted as a meat proxy. In many cases, these bans on LLM PRs are simply a reaction to this flood of PRs. After all, as I said above - everyone can do those prompts themselves, they don't need a PR for that.
I get the feeling that banning AI code from a project nowadays ends up with people lying about their AI usage. I think the approach other projects take where AI may be used, but the contributor holds the responsibility for it is more appropriate
Why is this a thing? There is AI code slop where no one reviews the code, and then there is closely human-guided agentic coding... maybe they got too much slop as pull requests?
They 100% got too much slop PRs. I can't speak for all OSS projects but in the case of Rust, it definitely got way out of hand. As a maintainer, there is no easy way to tell whether it was "AI code slop" or "closely human-guided agentic coding", you actually have to go in and understand the stuff. But making careless slop PRs takes 1% or less of the effort, and so the garbage PRs vastly outnumber everything else.
AI has ruined all of our previous signals for high-effort work, it is effectively running a sybil attack on FOSS.
That's probably one motive: a project notices a significant number of AI contributions, and determines they are of a lower average quality than the average non-AI contribution. Alternatively, there's an ideological motive.
Maybe it isn't about quality. I'd imagine with so many effortless pull requests about everything, you lose the ability to steer the project. The loss of agency and slaving to comprehend and merge everything leaves you witless and drone-like which sucks the joy out of things.
Maybe the requests should be focused on one or two areas at a time so you can see some improvement over time instead of "everything at once".
I'm not sure this website itself is even Anti-AI. The about page says "It is informational and takes no position on whether those policies are right". It also uses red for "banned" and green for "allowed". If it was Anti-AI, you'd expect the opposite, no?
I expect the problem isn’t necessarily the AI generation itself, but the difficulty to distinguish between someone that’s really understood the problem domain versus someone with LLM-induced “Dutch courage”.
That in combination with a large uptick in volume of community interactions (issues, PRs, …) risks burning out OSS maintainers.
Perhaps giving it a few months/years for the flurry to die down, and for people to establish better best-practices for using these tools is the motive.
The problem is that the last part changed drastically with LLMs. You can get a lot of solutions easily by prompting an LLM. But that also means you don't need outside PRs for that anymore, and just prompt the LLM yourself.
That means two things in my opinion:
1) People haven't internalized that yet. For a lot of people, a functioning solution to a problem with often quite a bit of source code is equivalent to "adding value" - because in the past it was. It meant you thought about the problem, understood it and found a solution. But it was that thinking that added the value.
2) The minimum threshold for adding this "quality" rises quite a bit. A lot of problems can now be solved very fast with an LLM by someone who understands the code base well enough. You don't need a PR for that.
I suspect, that means in the future you could both get and need less contributions to OSS projects in general.
We'll see
In LLM-friendly repositories it saves everyone's time if the maintainers are the ones steering the machines, and in LLM-unfriendly ones it saves everyone's time by not having generated PRs thrown at the maintainers.
Some of that. Also sometimes there isn't even a person, just a bot opening a pull request that doesn't hear feedback.
There's also the problem that many projects put disproportionate effort into mentoring new contributors and helping them get things right, and that's valuable when there's a human learning something, but not when you're just correcting someone's LLM slop.
And that's leaving aside all the other problems, like "these things took all our FOSS code, ignoring its licenses, and then used it to compete with us and drown us out", or "these things are going to turn us all into paperclips".
Personally, I'd say the right way to use an LLM is to let it review your code, or be your rubber duck helping you design the architecture or evaluate the security model or similar, but not let it write the code for you. (Unless it's truly throw-away code, like "write me some code to benchmark X vs Y to evaluate which is better for my use case". In which case, the point wasn't the code, it was the numbers.)
Recently I was picking a self-hosted tool for planning trips, and I deleted it after a day, because it was extremely vibe-coded and none of the security issues reported in GitHub were ever fixed. It can be a prompt away to fix those! I noticed this way too often in OSS that is vibe coded, people focus on looks, feels and code does not get reviewed enough, because it "looks good with the CSS gradients" and "an LLM is always right".
So I understand why they would ban and forbid AI / LLM contribution, and I am happy they are banning them, I assume mostly for the mental sanity of maintainers and for making sure that knowledge share and somewhat better PR reviews happens. I will always pick a human-made project over an AI / LLM coded one.
Projects like Servo or Redox OS are community-driven and already lack funding. Blocking AI-assisted code will only drive potential contributors away.
Some projects have built strong communities around AI-assisted development. The T3 Code community [0], for instance, is very active, and most PRs are created with LLM assistance.
The real issues are disclosure and taking responsibility for your submissions, including carefully reading and testing your own code. Code written by humans isn't inherently better in any sense.
[0]: https://github.com/pingdotgg/t3code/pulls
Well, this seems to be the point of it? To drive away contributors that maintainers regard as more trouble than worth.
"Random strangers, please don't have your agent send us PRs, we don't want to review it" -> yeah, totally reasonable open source maintainer behaviour, doesn't update my perception of the project at all.
"All code in this repo must be written by hand" -> This is probably not a serious project and I'll make a mental note not to depend on it.
If servo is really in the latter camp I'd actually say that's negligent at this point. A browser engine that doesn't have agents scanning for and fixing vulns is totally unacceptable.
They're doing it because they already are targets.
Yes, this is a vibe coded project, I'm simply curious to see how large the trend is, and also look into how people handle writing about AI contributions in their projects.
I do not intend to make any conclusions our of this. The domain name is mostly a pun on "computer says no"
I'd expect them to increasingly use AI to figure out the latest obfuscations regardless.
It's pretty clear at this point that AI coding works and is here to stay. But accepting external AI means you have way less knowledge about how it was generated, what models were used, were they given correct instructions etc. And also there's less benefit to accepting AI contributions because you're really receiving just a few minutes of contributor effort, which you could have easily done yourself.
There was a project highlighted recently that doesn't accept PRs at all and the maintainers just run the AI themselves. I expect that's where we're heading. If you want to contribute to open source projects in future it's going to be in the form of money for tokens.
Maybe submit a feature request/bug (prompt) and also pay some money to run the agent.
It's only a matter of time until code only written by humans is widely going to be considered unsafe. Sorry if that hurts anyone's feelings but that should be crystal clear to anyone working in the industry.
In that case, only getting a few, hand written PRs could mean getting fewer, but higher quality contributers.
Other projects might not care about getting many contributers, many stars or being widely used. It might simply be a small project someone wants to code by hand. That's absolutely valid, many people still have fun coding by hand.
The truth is just that there are a lot of slop PRs currently, where ppl just sicced an LLM on a problem, did not validate any findings, did not check the code, did not read the output and just acted as a meat proxy. In many cases, these bans on LLM PRs are simply a reaction to this flood of PRs. After all, as I said above - everyone can do those prompts themselves, they don't need a PR for that.
AI has ruined all of our previous signals for high-effort work, it is effectively running a sybil attack on FOSS.
Maybe the requests should be focused on one or two areas at a time so you can see some improvement over time instead of "everything at once".