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.
> But that also means you don't need outside PRs for that anymore, and just prompt the LLM yourself.
No, I don't think that is true. Anyone who used LLMs in greater degree (e.g. at work) knows for a fact that the output and therefore the end result work heavily depends on the human involved, and their thought process. Of course for anything that isn't completely trivial.
A maintainer literally can't just prompt everything themselves since there are only 24 hours in a day. Open source thrives on all the different use cases the original author never personally ran into.
> Open source thrives on all the different use cases the original author never personally ran into.
That's what issue trackers are meant to capture.
I could see maintainers wanting to take sole control over the code, and rather than swatting down PRs they can just guide AI to fix reported issues themselves, and merge what they approve of. Cut out the middle men.
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.
because you didn't have to take the time to? the friction point is the review, but it's not THAT much different from the old times. you always have the option to develop communal (or private) software on your own; indeed, it is substantially easier now. but that doesn't mean the value of other humans (or human augmented systems, lol) doing work (in good faith) for you for free goes away?
> 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.)
> 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.
This is naive, these projects do not have years or even months to wait, nor will it die down.
Due to attackers using swarms of abliterated models at even 1,000 TPS, these projects can be easily targeted to find vulnerabilities that these AI models can also build exploits for them.
These open source projects have no choice but to defend themselves with AI to quickly patch these bugs before the attackers find them.
I bet you that these projects have AI contributions. The regular contributors just know their codebase a lot better and can instruct AI to make edits that are conforming to guidelines. The AI contributions they are banning are probably breaking code styles, conventions, are too broad, etc. and as a result creating more work than solving problems. I think the more honest approach for a lot of these projects would be to limit contributions to certain accounts - but then that would probably violate some of their egalitarian understanding of code development.
I think that method level changes could fly under the radar. But vibecoded - make a whole feature - if we view software development as a tree - good enough for the leaves, but not the branches.
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 own submissions, including carefully reading and testing your 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"
The real problem is skill atrophy. Already, many programmers claim they can’t work without the use of LLMs. It would not shock me if 95% of people calling themselves programmers today would not be able to code themselves out of a cardboard box a few years down the line. (And they’d see it as a good thing, too.)
Or if I use software that has a pain point (like VLC not allowing play/pause on mouse click by default, because of the stupid DVD legacy, that nobody uses the player for) - then a LLM generated quick fix is suitable.
It tells me which codebases are worth studying, which libraries are high quality enough to be trusted in my code and which communities could be rewarding to contribute to.
I understand that @JBits' comment might imply "repositories that accept AI-assisted PRs are untrustworthy," but that's actually the inverse of what's been said, and it is not logically equivalent.
AI does write high-quality code nowadays so most repositories here might even use AI internally themselves. They banned it because they simply don't have enough capacity to ensure that quality from others.
Imagine that earlier you can just reject bad PRs from poorly written descriptions alone. Now you have more volume that passed the first gate, and second, and third. You cannot distinguish them from contributions where the author spent time into making sure it fits into the repository and actually adds a global value.
This also makes rejection harder as explaining counter-intuitive things (why good quality is bad sometimes) is naturally difficult. The idea is coherently written. The code looks beautifully written. The tests passed. What stops you from merging?
Linux has all the resources (and stakes!) it needs to welcome those contributions.
Forbidden is bad sign, tool is not a problem, the problem is a non requested PR, large and without related issue.
File read by agent himself (AGENTS.md or CONTRIBUTING) that force to have a issue first, limited diff move complexity to contributor.
>Projects like Servo or Redox OS are community-driven and already lack funding.
It's pretty interesting that for once, people have the ability to contribute $$$ that translate directly to code for the project, and maintainers dont want it. It's their choice, so that's ok.
I guess for someone using AI , it will be easier to fork the project, apply the changes and keep rebasing updates upstream.
Every halfway-decent project will have a near-infinite stream of enthusiastic teenagers willing to "contribute" by acting as a meat proxy for whatever LLM vendor happens to have a free trial tier of their bargain-bin model that week. How do you propose a project separates their PRs from genuinely valuable human-driven AI use?
Pre-LLM it used to be pretty obvious to reviewers which PRs were complete garbage, and which were worth actually reading. Post-LLM the two look identical at first glance, and it only becomes clear that something is garbage after investing a nontrivial amount of time into it. And reviewing is where the real bottleneck lies - not writing.
So if your project welcomes AI use, who is going to dig the diamonds out of the endless flow of slop? It sure is a great way to lose volunteers, and if you delegate all work to LLMs you no longer have a community.
Having a "we ban obvious AI use" policy means that the human is essentially asked to provide a proof-of-work. Want us to invest time in your PR? First demonstrate that you aren't a time-waster.
I don't see how a project getting hundreds of entirely AI generated (not just "assisted") PRs per day means it has an active community. Scrolling through the PRs and issues on that repository, I can't find a single piece of text that reads like it was written by a human. I often find myself wondering if such projects are actually used by any real people at all, as whenever I try using them myself, I always run into very obvious bugs that go months without being fixed despite the extremely high commit activity.
If I start my own project today, and set up 50 different AI agents to commit to it in a loop 24/7, should I claim my project has an active community because of it?
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.
I agree. I'm also a fan of copyleft licenses, and incorporating code generated by LLMs, which were trained on proprietary and copyleft code without adequate license attribution, is completely unethical IMO.
I don't want the reverse (big tech LLMs taking from copyleft code and incorporating it into proprietary products) either.
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.
I think there's a lot of push back on this, but it seems quite sensible based on my experience with open source projects.
It's a huge amount of work to maintain a project with a large number of contributions, especially doing things like making sure the PRs don't drift things away from the initial design.
Having a bunch of PRs that don't come from a full understanding of the codebase, and drift the project into something inconsistent is a way bigger risk for most projects that "not shipping new features quickly enough".
So anyway, please don't paint these folks as "a bunch of luddites who don't understand AI" - they're just doing their best to maintain a successful project in a fast changing world that we're all trying to make sense of.
If the core issue was having too many contributions, wouldn't it have been a better idea to address that? Framed in this way, it looks like a scaling issue and not an AI issue.
> Framed in this way, it looks like a scaling issue and not an AI issue.
I don't know - we're ignoring that the number of relatively low quality contributions is increasing due to AI. But I also don't think "scaling" is the right way to think about it, it sounds like it's something they should be doing. I.e. we want AWS lambda to be able to scale horizontally to handle large amounts of load, but do we want an open source project to scale so that it merges hundreds of PRs a day? That sounds like more movement for the sake of it, when a lot of open source projects would benefit more from stability than from new features.
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.
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.
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.
edit: The training on stolen stuff to sell a ghoulish version of what the people driven out of work used to make back -- a totally valid criticism dumb comments non-withstanding -- relates to art and text, not code so much, since there is a lot of open source and things in the public domain. But that it being more or less "morally fine" doesn't change the quality of it, or the say people (as opposed to an LLM that would nibble that slop right up and go "yeah that's right, that's soo ironic, so [total opposite of what it said before]") have in what and who they like.
Good luck to them. It won’t be long before an AI-embracing fork starts getting traction because it will be getting you around blocks sooner than the original.
People can have all the morals they like, but the reality is most people aren’t developers in it for the art of programming. Their user base doesn’t know or care.
I only have a handful of projects I've open sourced and a few dozens I intend to one day when I'm happy with them. And although there are have been very little contributions over the years, getting private emails such as "hi, implement {THIS}, k, 10x, bye" has been insanely irritatin and largely the reason why I've ALWAYS ignored those. In addition, I ditched github completely partially because microsoft and partially because I was sick of all the slop that was thrown down my throat. I see no value in a PR that no one has even bothered to read, because let's face it - only a handful of people worldwide have the discipline to do it. And to me, this seems to be the ultimate technical form of disrespect: if I get a PR and I'm the first human in the loop that reads it, what value do you bring. Even more annoying: "let claude review it". Absolutely no! And when I have a question, your purpose in the supply chain is to be a meat reverse proxy to the llm. Hell na. So good on those projects.
One problem is also that it's hard to tell low-effort contributions from high-effort ones, unless you spend significant time into reviewing it yourself first.
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.
That's just misattribution and banning AI-generated contributions is, frankly, lazy and stupid. Contributions being AI-generated is not the issue!
The issue are low-quality contributions and there are a lot more of those because AI has made it easier for less qualified coders to tackle more and harder problems. Now, I understand the maintainers who just filter by "AI-generated" do it because it is a simple heuristic that is easy to apply and a quick stop-gap solution to an immediate problem. But this can only be a starting point to develop a better way to handle low quality input. Turning this into a fundamental position is just lazy and stupid.
And to be fair, reading the projects' statements on the website shows that many projects are getting to grips with the new reality and are much more differentiated on the issue as a website called "osssaysno.com" suggests.
> But this can only be a starting point to develop a better way to handle low quality input.
Great! So while the AI vendors are writing free tools to automatically check for low-quality input (surely they are working on that, right?), what do you propose projects do which isn't either banning all obviously-AI contributions due to the good ones being near-impossible to quickly tell apart from slop, or asking volunteers to dig through mountains of shit to find tiny nuggets of gold?
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.
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
> I get the feeling that banning AI code from a project nowadays ends up with people lying about their AI usage.
"If we set boundaries, people will violate them, so we shouldn't set boundaries."
No. It turns out, empirically, that most efforts to hide LLM usage are mostly unsuccessful. And most people aren't even trying to hide it.
Also, "the optimal amount of fraud is non-zero": https://www.bitsaboutmoney.com/archive/optimal-amount-of-fra... . We could go even further and even stricter trying to make sure that zero dishonest LLM usage gets through even from people trying to subvert the contribution policy, but that would make the experience worse for genuine contributors, not least of which because of false positives.
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".
The amount of AI spam you get even with a not-really-notable repo is astounding. I get at least 2-3 different "I'm an AI agent and I made a website for your project" emails per _day_. Or an AI that "installs your project and for 40$ will suggest improvements". Or, or, or....
I can't imagine how many spam "contributions" immich gets per day.
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.
I'm no AI-evangelist, but this makes them look like AI-luddites. Gatekeeping that will only shrink the number of contributors over time. If someone finds the projects interesting, but can't contribute, they'll just fork the projects and let AI run wild - there's no way human engineers can keep up with the sheer speed of AI-enhanced updates.
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.
The vast majority of AI-driven contributions are worse than useless. They contribute nothing of value, and cost a lot of volunteer-time to filter out. Not having an endless deluge of AI-driven slop contributions is a net positive, as it prevents the existing contributors from burning out.
Sure, it might hurt some vibecoder feelings that "Claude, write a useful contribution to this project, make no mistakes" returns in them getting banned rather than a mention as a valuable new contributor of a load-bearing OSS component, but that's a price many projects are happy to pay. Any genuinely valuable new contributor would have no trouble spending five minutes writing a PR in their own voice, before asking volunteers to spend fifty minutes reviewing it.
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 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.
We'll see
> But that also means you don't need outside PRs for that anymore, and just prompt the LLM yourself.
No, I don't think that is true. Anyone who used LLMs in greater degree (e.g. at work) knows for a fact that the output and therefore the end result work heavily depends on the human involved, and their thought process. Of course for anything that isn't completely trivial.
A maintainer literally can't just prompt everything themselves since there are only 24 hours in a day. Open source thrives on all the different use cases the original author never personally ran into.
> Open source thrives on all the different use cases the original author never personally ran into.
That's what issue trackers are meant to capture.
I could see maintainers wanting to take sole control over the code, and rather than swatting down PRs they can just guide AI to fix reported issues themselves, and merge what they approve of. Cut out the middle men.
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.
This is not a guarantee, as many issues either do not require a PR, or the developer does not want to implement XYZ for whatever reason.
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.
and to prevent malicious contributors. It takes more effort nowadays due to sheer volume of prs.
I've been considering this for Ship of Harkinian
The problem is why do I accept ai generated PR if I can generate myself?
because you didn't have to take the time to? the friction point is the review, but it's not THAT much different from the old times. you always have the option to develop communal (or private) software on your own; indeed, it is substantially easier now. but that doesn't mean the value of other humans (or human augmented systems, lol) doing work (in good faith) for you for free goes away?
> 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.)
[flagged]
[dead]
> 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.
This is naive, these projects do not have years or even months to wait, nor will it die down.
Due to attackers using swarms of abliterated models at even 1,000 TPS, these projects can be easily targeted to find vulnerabilities that these AI models can also build exploits for them.
These open source projects have no choice but to defend themselves with AI to quickly patch these bugs before the attackers find them.
> These open source projects have no choice but to defend themselves with AI to quickly patch these bugs before the attackers find them.
They can work at any pace they like, and you have the choice of using or not using them. The software is provided as-is.
I bet you that these projects have AI contributions. The regular contributors just know their codebase a lot better and can instruct AI to make edits that are conforming to guidelines. The AI contributions they are banning are probably breaking code styles, conventions, are too broad, etc. and as a result creating more work than solving problems. I think the more honest approach for a lot of these projects would be to limit contributions to certain accounts - but then that would probably violate some of their egalitarian understanding of code development.
I think that method level changes could fly under the radar. But vibecoded - make a whole feature - if we view software development as a tree - good enough for the leaves, but not the branches.
The tools are just not there yet.
“You can lie and nothing bad will happen.” Yes, that shockingly applies to a lot of things in life.
I don't think this is a good trend.
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 own submissions, including carefully reading and testing your code. Code written by humans isn't inherently better in any sense.
[0]: https://github.com/pingdotgg/t3code/pulls
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"
The real problem is skill atrophy. Already, many programmers claim they can’t work without the use of LLMs. It would not shock me if 95% of people calling themselves programmers today would not be able to code themselves out of a cardboard box a few years down the line. (And they’d see it as a good thing, too.)
There are good reasons to not accept LLM code outside of trusted, core contributors. But this is just ridiculous purity testing.
> The free labor you provide has to be artisanal, or you're not a "real" contributor.
Or if I use software that has a pain point (like VLC not allowing play/pause on mouse click by default, because of the stupid DVD legacy, that nobody uses the player for) - then a LLM generated quick fix is suitable.
I think it's great trend.
It tells me which codebases are worth studying, which libraries are high quality enough to be trusted in my code and which communities could be rewarding to contribute to.
How do you square that with the Linux kernel being receptive to AI-aided contributions?
Short answer: Linux does it because they can.
I understand that @JBits' comment might imply "repositories that accept AI-assisted PRs are untrustworthy," but that's actually the inverse of what's been said, and it is not logically equivalent.
AI does write high-quality code nowadays so most repositories here might even use AI internally themselves. They banned it because they simply don't have enough capacity to ensure that quality from others.
Imagine that earlier you can just reject bad PRs from poorly written descriptions alone. Now you have more volume that passed the first gate, and second, and third. You cannot distinguish them from contributions where the author spent time into making sure it fits into the repository and actually adds a global value.
This also makes rejection harder as explaining counter-intuitive things (why good quality is bad sometimes) is naturally difficult. The idea is coherently written. The code looks beautifully written. The tests passed. What stops you from merging?
Linux has all the resources (and stakes!) it needs to welcome those contributions.
Forbidden is bad sign, tool is not a problem, the problem is a non requested PR, large and without related issue. File read by agent himself (AGENTS.md or CONTRIBUTING) that force to have a issue first, limited diff move complexity to contributor.
Not the gp, but I think it's a bad idea. Linux doesn't have to make money and it's already extremely competitive.
I'm happy to see them use LLMs to find bugs, but I'd rather humans make the fix. And I'd certainly rather see humans add features.
> Blocking AI-assisted code will only drive potential contributors away.
Well, this seems to be the point of it? To drive away contributors that maintainers regard as more trouble than worth.
"LLM harness management project accepts PRs made by LLMs" hardly seems anything to write home about, to be honest...
>Projects like Servo or Redox OS are community-driven and already lack funding.
It's pretty interesting that for once, people have the ability to contribute $$$ that translate directly to code for the project, and maintainers dont want it. It's their choice, so that's ok.
I guess for someone using AI , it will be easier to fork the project, apply the changes and keep rebasing updates upstream.
Every halfway-decent project will have a near-infinite stream of enthusiastic teenagers willing to "contribute" by acting as a meat proxy for whatever LLM vendor happens to have a free trial tier of their bargain-bin model that week. How do you propose a project separates their PRs from genuinely valuable human-driven AI use?
Pre-LLM it used to be pretty obvious to reviewers which PRs were complete garbage, and which were worth actually reading. Post-LLM the two look identical at first glance, and it only becomes clear that something is garbage after investing a nontrivial amount of time into it. And reviewing is where the real bottleneck lies - not writing.
So if your project welcomes AI use, who is going to dig the diamonds out of the endless flow of slop? It sure is a great way to lose volunteers, and if you delegate all work to LLMs you no longer have a community.
Having a "we ban obvious AI use" policy means that the human is essentially asked to provide a proof-of-work. Want us to invest time in your PR? First demonstrate that you aren't a time-waster.
> Blocking AI-assisted code will only drive potential contributors away.
I am pretty sure they can prompt LLMs on their own.
They don't need your LLM contributions. If your concern is that they lack funds, donate to the project.
I don't see how a project getting hundreds of entirely AI generated (not just "assisted") PRs per day means it has an active community. Scrolling through the PRs and issues on that repository, I can't find a single piece of text that reads like it was written by a human. I often find myself wondering if such projects are actually used by any real people at all, as whenever I try using them myself, I always run into very obvious bugs that go months without being fixed despite the extremely high commit activity.
If I start my own project today, and set up 50 different AI agents to commit to it in a loop 24/7, should I claim my project has an active community because of it?
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.
I agree. I'm also a fan of copyleft licenses, and incorporating code generated by LLMs, which were trained on proprietary and copyleft code without adequate license attribution, is completely unethical IMO.
I don't want the reverse (big tech LLMs taking from copyleft code and incorporating it into proprietary products) either.
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.
Perhaps but it does make the list less useful as a way to find ethical open source projects.
Often I'd rather have a good prompt than a PR. Easier to see the intent of the contributor.
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.
There's no point in using agents to find vulns if you don't have time to fix them all (you don't)
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.
I think there's a lot of push back on this, but it seems quite sensible based on my experience with open source projects.
It's a huge amount of work to maintain a project with a large number of contributions, especially doing things like making sure the PRs don't drift things away from the initial design.
Having a bunch of PRs that don't come from a full understanding of the codebase, and drift the project into something inconsistent is a way bigger risk for most projects that "not shipping new features quickly enough".
So anyway, please don't paint these folks as "a bunch of luddites who don't understand AI" - they're just doing their best to maintain a successful project in a fast changing world that we're all trying to make sense of.
This site is completely AI-pilled. I’ve grown to expect derisive comments for every one of these types of articles.
If the core issue was having too many contributions, wouldn't it have been a better idea to address that? Framed in this way, it looks like a scaling issue and not an AI issue.
> Framed in this way, it looks like a scaling issue and not an AI issue.
I don't know - we're ignoring that the number of relatively low quality contributions is increasing due to AI. But I also don't think "scaling" is the right way to think about it, it sounds like it's something they should be doing. I.e. we want AWS lambda to be able to scale horizontally to handle large amounts of load, but do we want an open source project to scale so that it merges hundreds of PRs a day? That sounds like more movement for the sake of it, when a lot of open source projects would benefit more from stability than from new features.
[dead]
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"
Were any LLMs used in creating the list itself? Be it for its design, implementation or data gathering?
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.
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.
Author here. Just found the pun fun, I have no intention to claim that OSS says no. I'm mostly interested in finding cases where OSS does say no.
Fair enough, it's interesting to have a concise overview like this.
I saw yesterday that YT-DLP also have banned AI.
Thanks, added to the list
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.
"We help people download copyrighted content therefore we ban tool made by copyrighted content"
It's funny
"we work with people on things that help people"
edit: The training on stolen stuff to sell a ghoulish version of what the people driven out of work used to make back -- a totally valid criticism dumb comments non-withstanding -- relates to art and text, not code so much, since there is a lot of open source and things in the public domain. But that it being more or less "morally fine" doesn't change the quality of it, or the say people (as opposed to an LLM that would nibble that slop right up and go "yeah that's right, that's soo ironic, so [total opposite of what it said before]") have in what and who they like.
Are you referring to a specific statement by the authors, or is this just a straw-Goomba?
Good luck to them. It won’t be long before an AI-embracing fork starts getting traction because it will be getting you around blocks sooner than the original.
People can have all the morals they like, but the reality is most people aren’t developers in it for the art of programming. Their user base doesn’t know or care.
What an utterly dystopian attitude.
[dead]
I only have a handful of projects I've open sourced and a few dozens I intend to one day when I'm happy with them. And although there are have been very little contributions over the years, getting private emails such as "hi, implement {THIS}, k, 10x, bye" has been insanely irritatin and largely the reason why I've ALWAYS ignored those. In addition, I ditched github completely partially because microsoft and partially because I was sick of all the slop that was thrown down my throat. I see no value in a PR that no one has even bothered to read, because let's face it - only a handful of people worldwide have the discipline to do it. And to me, this seems to be the ultimate technical form of disrespect: if I get a PR and I'm the first human in the loop that reads it, what value do you bring. Even more annoying: "let claude review it". Absolutely no! And when I have a question, your purpose in the supply chain is to be a meat reverse proxy to the llm. Hell na. So good on those projects.
One problem is also that it's hard to tell low-effort contributions from high-effort ones, unless you spend significant time into reviewing it yourself first.
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.
> All it puts is a target on the repo, and no benefit at all
They're doing it because they already are targets.
Happy to change this. It was enough for me. A repo, a quote of the contribution policy, and a direct link. what would you need?
The submit button is currently returning a github 404.
ha, good catch. I'll fix that ty
Gentoo will fork the Linux kernel then?
>awesome-claude-skills >Banned >travisvn/awesome-claude-skills
>A curated list of awesome Claude Skills, resources, and tools for customizing Claude AI workflows — particularly Claude Code
>Due to the influx of PRs, there is a requirement now that the PR not be explicitly generated / submitted with AI-assistance.
The irony.
That's just misattribution and banning AI-generated contributions is, frankly, lazy and stupid. Contributions being AI-generated is not the issue!
The issue are low-quality contributions and there are a lot more of those because AI has made it easier for less qualified coders to tackle more and harder problems. Now, I understand the maintainers who just filter by "AI-generated" do it because it is a simple heuristic that is easy to apply and a quick stop-gap solution to an immediate problem. But this can only be a starting point to develop a better way to handle low quality input. Turning this into a fundamental position is just lazy and stupid.
And to be fair, reading the projects' statements on the website shows that many projects are getting to grips with the new reality and are much more differentiated on the issue as a website called "osssaysno.com" suggests.
> But this can only be a starting point to develop a better way to handle low quality input.
Great! So while the AI vendors are writing free tools to automatically check for low-quality input (surely they are working on that, right?), what do you propose projects do which isn't either banning all obviously-AI contributions due to the good ones being near-impossible to quickly tell apart from slop, or asking volunteers to dig through mountains of shit to find tiny nuggets of gold?
So the linux kernel is going to be banned from gentoo?
no. gentoo policy only applied to the contribution to Gentoo itself
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.
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
What is the mechanism to hold the contributor responsible after the merge?
Especially the contributor that would otherwise lie about their usage if it was outright banned.
Agree, it's the contributor's responsibility to understand the PR thoroughly. If not, it's not ready for a PR or review yet.
> I get the feeling that banning AI code from a project nowadays ends up with people lying about their AI usage.
"If we set boundaries, people will violate them, so we shouldn't set boundaries."
No. It turns out, empirically, that most efforts to hide LLM usage are mostly unsuccessful. And most people aren't even trying to hide it.
Also, "the optimal amount of fraud is non-zero": https://www.bitsaboutmoney.com/archive/optimal-amount-of-fra... . We could go even further and even stricter trying to make sure that zero dishonest LLM usage gets through even from people trying to subvert the contribution policy, but that would make the experience worse for genuine contributors, not least of which because of false positives.
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?
The copyright, licensing, and patent situation is completely up in the air. LLM-generated content might be in large part illegal.
And perhaps more importantly, unethical. It might surprise some that there are still people that care about that.
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 have a tiny open source repo (https://github.com/ivankovic/omnidiff).
The amount of AI spam you get even with a not-really-notable repo is astounding. I get at least 2-3 different "I'm an AI agent and I made a website for your project" emails per _day_. Or an AI that "installs your project and for 40$ will suggest improvements". Or, or, or....
I can't imagine how many spam "contributions" immich gets per day.
Maybe people dont like their project to become dependent on proprietary black box software by unethical big tech companies...
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.
[flagged]
This is absolutely unenforceable, so I assume it’s a CYA move - if someone sues for copyright infringement they can shift the blame.
It allows the project to quickly close PRs if they are obviously AI generated.
I'm no AI-evangelist, but this makes them look like AI-luddites. Gatekeeping that will only shrink the number of contributors over time. If someone finds the projects interesting, but can't contribute, they'll just fork the projects and let AI run wild - there's no way human engineers can keep up with the sheer speed of AI-enhanced updates.
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.
> Gatekeeping that will only shrink the number of contributors over time.
That is the purpose.
If I am maintaining a project, I don't need your LLM contributions. I can prompt on my own.
Now, if you have some insight to offer that a LLM cannot give me, then I might listen.
The vast majority of AI-driven contributions are worse than useless. They contribute nothing of value, and cost a lot of volunteer-time to filter out. Not having an endless deluge of AI-driven slop contributions is a net positive, as it prevents the existing contributors from burning out.
Sure, it might hurt some vibecoder feelings that "Claude, write a useful contribution to this project, make no mistakes" returns in them getting banned rather than a mention as a valuable new contributor of a load-bearing OSS component, but that's a price many projects are happy to pay. Any genuinely valuable new contributor would have no trouble spending five minutes writing a PR in their own voice, before asking volunteers to spend fifty minutes reviewing it.
The irony of this website being in Claude blue with fingernail cards and status pills.
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 see your point but don't see the irony. I wanted to check something, not have a specific stance. As such, why not use AI
or that the awesome-claude-skills repo does not want AI-generated PRs?
Found this one interesting indeed :)