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
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.
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.)
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.
The tools are just not there yet.
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.
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.
Well, this seems to be the point of it? To drive away contributors that maintainers regard as more trouble than worth.
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 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.
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?
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 don't want the reverse (big tech LLMs taking from copyleft code and incorporating it into proprietary products) either.
"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.
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.
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.
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 funny
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.
>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.
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.
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?
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.
"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.
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.
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".
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.
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.
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.
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.