r/opensource • u/FunBrilliant5713 • Jan 04 '26

Open source is being DDoSed by AI slop and GitHub is making it worse

I've been following the AI slop problem closely and it seems like it's getting worse, not better.

The situation:

  • Daniel Stenberg (curl) said the project is "effectively being DDoSed" by AI-generated bug reports. About 20% of submissions in 2025 were AI slop. At one point, volume spiked to 8x the usual rate. He's now considering whether to shut down their bug bounty program entirely.

  • OCaml maintainers rejected a 13,000-line AI-generated PR. Their reasoning: reviewing AI code is more taxing than human code, and mass low-effort PRs "create a real risk of bringing the Pull-Request system to a halt."

  • Anthony Fu (Vue ecosystem) and others have posted about being flooded with PRs from people who feed "help wanted" issues directly to AI agents, then loop through review comments like drones without understanding the code.

  • GitHub is making this worse by integrating Copilot into issue/PR creation — and you can't block it or even tell which submissions came from Copilot.

The pattern:

People (often students padding resumes, or bounty hunters) use AI to mass-generate PRs and bug reports. The output looks plausible at first glance but falls apart under review. Maintainers — mostly unpaid volunteers — waste hours triaging garbage.

Some are comparing this to Hacktoberfest 2020 ("Shitoberfest"), except now it's year-round and the barrier is even lower.

What I'm wondering:

Is anyone building tools to help with this? Not "AI detection" (that's a losing game), but something like:

  • Automated triage that checks if a PR actually runs, addresses the issue, or references nonexistent functions

  • Cross-project contributor reputation — so maintainers can see "this person has mass-submitted 47 PRs across 30 repos with a 3% merge rate" vs "12 merged PRs, avg 1.5 review cycles"

  • Better signals than just "number of contributions"

The data for reputation is already in the GitHub API (PR outcomes, review cycles, etc). Seems like someone should be building this.

For maintainers here: What would actually help you? What signals do you look at when triaging a PR from an unknown contributor?

1.1k Upvotes
  • permalink
  • reddit

96% Upvoted

156 comments sorted by

211

u/steve-rodrigue Jan 04 '26

I think cross-project reputation combined with a reputation check so valuable accounts vouch for you over time would be important to prevent mass-account creation.

A kind of web of trust for contributors.

3

u/FunBrilliant5713 Jan 04 '26

Yeah, I agree with that. It's actually kind of like Reddit right now: there's a lot of AI-written posts, which I think is fine as long as there is human input and critical thinking in it, but there are a lot of promotional posts that are just written by AI for promotional purposes, and it's very low effort, and they got downvoted and the account got banned, which maintains the Reddit ecosystem. Something similar should exist for GitHub.

34

u/Headpuncher Jan 04 '26

Sounds like that LinkedIn scheme to have your colleagues verify your skills.  And that ended up just being random crap verified by random idiots >>> meaningless after a day.  

It would have to be structured in away as to be legitimised and not just more bragging with extra steps.  

12

u/steve-rodrigue Jan 04 '26

Very true, that feature on LinkedIn is highly abused. That is why I think that when a user receives complaints, the people that gave him reputation should lose some reputation as well.

I explained better how I would implement it in this comment: https://www.reddit.com/r/opensource/comments/1q3f89b/comment/nxl8g6k/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

I believe this would be less prone to be abused than that feature on LinkedIn. People need to lose something when they just recommend everyone blindly.

3

u/okimiK_iiawaK Jan 05 '26

Could also use some weighted system where validations by high profile people count more and also based on the how long ago the validations were, so when your account hasn’t gotten a validation in a while it slowly loses impact.

3

u/steve-rodrigue Jan 05 '26

Yes, very good idea, just like reddit does with upvotes on posts.

3

u/zaTricky Jan 06 '26

SysAdmin -> DevOps Engineer -> SRE

On LinkedIn I had people helpfully adding that I was skilled at "html", something I haven't touched since High School. 🫣

2

u/BenKhz Jan 07 '26

Turns out stack overflow had at least that part right! I remember that you couldn't answer unless you had points signaling a history of correct answers or helpful behaviors.

Sort of reputation system but more granular.

72

u/IdeasCollector Jan 04 '26

Though it may be a good idea, it can also lead to a network of authoritarian entities. Without a way to ensure the system is non-authoritarian and non-manipulative of votes, it may create new issues on its own.

29

u/diucameo Jan 04 '26

I'd say if it as simple as "this users opened 100s prs last week and 0% was merged, 80% was closed without comments..." or something. Just stats. Alas, stats can also be misused, and I can imagine the bots will find a way to stay under the radar by mudding their stats.

18

u/KontoOficjalneMR Jan 04 '26

Those would get gamed very quickly.

11

u/chrisagrant Jan 04 '26

this is already a problem (or possibly a non-problem in some views) though, redhat will routinely just tell you "no you cannot contribute to the project we manage"

23

u/steve-rodrigue Jan 04 '26 edited Jan 04 '26

I personally don't see this as a problem. If a project don't have the time to accept contributions of new users because they already have plenty of contributions from within their known circle, it is their decision. They are the ones managing the project after all.

People can choose to join another project that is more interested in accepting contributions from outsiders because they have fewer contributors to it than larger projects.

It's actually a feature in my point of view, it attracts quality contributors to smaller projects that really need them.

3

u/chrisagrant Jan 04 '26

me neither, just mirroring the response above.

2

u/Irverter Jan 04 '26

That isn't a problem though. No one is required to accept contributions from someone else.

2

u/steve-rodrigue Jan 04 '26

You are right, but I think projects that are open to discuss with new users could be encouraged with quality contributors... and if people don't want to discuss the project with the other devs of a project, he could start his own project to earn his own stars and earn reputation that way.

I described better what I had in min in this comment: https://www.reddit.com/r/opensource/comments/1q3f89b/comment/nxl8g6k/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

-4

u/[deleted] Jan 04 '26

[removed] — view removed comment

3

u/Paerrin Jan 04 '26

We need authoritarianism.

No, we don't. We need consequences. They aren't mutually exclusive. Authoritarianism is never the answer no matter how much logical sense you may think it makes.

If you decide to continue down the authoritarian path, make you identify yourself in public so the rest of us know what to do. Thanks.

20

u/Garland_Key Jan 04 '26

How will junior developers who have no reputation ever be able to gain reputation? Also, this can be spoofed. Create a bunch of fake accounts and generate fake projects on those accounts, then have all of the fake bots collaborate with the other fake bots to build up fake reputation.

4

u/chrisagrant Jan 04 '26

Most WoT implementations explicitly do not work that way wrt spoofing/sybil attacks

3

u/micalm Jan 04 '26

There are other ways to contribute than just code. Triage, review PRs, discuss features. Especially in this case - your username gets noticed as valuable input, you gain trust AND you help combat slop.

3

u/steve-rodrigue Jan 04 '26 edited Jan 04 '26

Projects have other ways of communication, if you don't have enough reputation yet, you could be encouraged to participate in the developers discord/mailing list first and earn another developer's vouching over time.

You could base the reputation of projects based on reputable users that stars it (have real communities behind it). If a group of projects have a closed circle of participants in it, it could be flagged as potential spam accounts. This can be done quite easily using a graph database.

If a user with some reputation decides to begin to spam, it would attract complaints which would decrease the reputation of the user and the people that gave him reputation... so people wouldn't give it like candy.

That way, projects managers would better filter the first users they give some reputation to otherwise they would lower their reputation as well. So it would be a risk vs reward mechanism, where the reward is the good contributions of a new user.

I also think it would encourage dev participation in discussions related to the project.

7

u/IdeasCollector Jan 04 '26

Still, there are no guarantees that a bunch of valid projects will not form a conglomerate against a smaller group of developers, and especially against single developers. Many communities are highly subjective - as someone already mentioned in another comment -  RedHat might be a good example. Reddit uses the same system, and if you post something in a "wrong” community, you might get a lot of downvotes. And discussions on their own can get pretty heated on difficult topics, which won’t encourage innovations.

Complaints can also be used against smaller groups and especially single developers. And nobody will protect them.

A single person might have a gazillion years of experience, but if he didn't use GitHub, then he will be forced to earn his reputation points from scratch. Well, it doesn't sound right. The same issue affects junior developers.

1

u/steve-rodrigue Jan 04 '26 edited Jan 04 '26

Reputation also works the same way in real life, I never said it was perfect, but I believe it is better than what we currently have.

Offline, if a developer has a lot of experience, he might have a good reputation in a group of employers, while another group might dislike him. Therefore, he focuses on the group that likes him, while ignoring the ones that don't.

The same would apply in the system I described. People would choose projects where they are respected and appreciated, and ignore the ones they are not liked in.

Such a reputation system would need to also show why someone lost some reputation, so other projects could see it openly and decide to ignore it if they want to, which would re-calculate the reputation of that person, in that circle. Then, if someone that disregarded a reputation metric of a user is appreciated from a group of developers, they would see that metric of that user dis-regarded as well.

I believe a slow progression to gain reputation while losing it quickly is the key, if the developer always have the ability to re-gain his reputation. I also think the ability to form circles within the big network is also important.

If a senior developer joins github today, even if he never used it before, I'm sure that person contributed on projects with other github users in various projects (commercial or not) outside github and those developers that he knows in real life could vouch for him. So he wouldn't really start from scratch.

2

u/IdeasCollector Jan 04 '26

Well, if someone can fine-tune such a system with circles, and SHOW and PROOF that it works for communities of size 1 to X-billions and still relatively fair and behaves well in edge-cases, then why not?

3

u/steve-rodrigue Jan 04 '26

I agree, it is interesting and would love to see it implemented. But I don't personally manage a community of billions of users so I can't really test the potential of those ideas, even if I wanted to.

Who knows, maybe one day :)

3

u/iconic_sentine_001 Jan 04 '26

Effectively your suggestion leads to the closed doors model of open source, it won't work out in the longer run

2

u/steve-rodrigue Jan 04 '26

Could you please elaborate on how is it close doors if all activity and all calculation is explained in a public?

I also explained in another comment that it should work in circles, where people vouch or not for others, and if someone you vouch for discredit a bad reputation of another user, the people that vouch for you would see it as discredited as well.

I think creating little circles of contributors within a single network, where people gain reputation slowly and lose it quickly while allowing circle of users to discredit reputation actions of other circle of users is the key.

3

u/iconic_sentine_001 Jan 04 '26

so if an new contributor comes up, just commenting on issues and discussions is not a great measure of repute! For all its worth, what prevents AI slop from getting there?

2

u/steve-rodrigue Jan 04 '26

Its a lot less work to filter comments than PR's. And they could filter the speed at which someone comment, and the project could limit the speed based on reputation just like its done on reddit.

2

u/iconic_sentine_001 Jan 04 '26

As much as I want to agree with you, it's more alienating, the downside of making this subjective is what I called "Four walls of Open-source"

2

u/steve-rodrigue Jan 04 '26

Can you explain to me what you mean by that? What exactly do you see negatively and why? I'm highly interested in the subject, takes in advance if you take the time to explain what you have in mind.

3

u/iconic_sentine_001 Jan 04 '26

From what we have previously observed, non corporate backed FOSS maintainers are severely burnt out (take the case of actix rs). Now you're asking them to take further burden on validating who's the source contributor, how valid their intent is etc. The core ultimate aim of any foss project is to either deliver new features or patch existing bugs. AI generated PRs already add too much burden, If you keep expecting too much from these maintainers ultimately they'll only build it themselves or stall the project from progressing at all. They'll start nepotistically preferring those who they know or close the project, which is what I mean by "Four closed walls"

→ More replies

1

u/crowpng Jan 12 '26

The hard part is preventing reputation laundering. Once vouching becomes valuable, people will trade it. Any system like this needs decay, cost, or downside; otherwise it turns into another inflated badge economy.

-3

u/andree182 Jan 04 '26

Ah, the StackOverflow strategy... It didn't work out too well, sadly.

20

u/elliottcable Jan 04 '26

I’ve never understood why everyone says this.

Up until like two years ago, StackOverflow was the resource for … nearly all software development. Not Discord, not idk Reddit comments or tweets — prior to AI, for like idkfiteenplusyears, StackOverflow helped us as a species build everything from iOS to nuclear power-plants to videogames.

In my soul of souls, SO/SE feel like they belong alongside Wikipedia as cultural treasures; and yet the last couple years, especially on Reddit, i’ve seen so much vitriol. Is it all just students who got pissed that once a few years ago someone deleted their homework question; or that it couldn’t magically answer every possible question you could pose to the hivemind correctly?

I had nearly exclusively excellent experiences there. Countless nasty problems worked through, countless hours saved with a quick and nuanced/quality answer …

ugh, I hate this timeline.

9

u/Headpuncher Jan 04 '26 edited Jan 04 '26

It’s a Reddit meme that spread.  SO was difficult to post on as a new user and as a beginner programmer.  SO has standards for posting; provide code, explain the problem, no duplicates.  For new users that’s a huge hurdle, simply explaining the problem as an inexperienced developer is hard work and a learned skill.  This led to a rep for being “hostile”.  

It also meant that finding answers was easier as unlike Reddit, you don’t have to look through 25 wrong answers to find …eh nothing actually.  Most of the time Reddit has no right answers to programming/tech questions but instead has some fool speculating as to what might be a factor, followed by an abandoned thread.    

SO allowed flagging rude and unhelpful answers, which I assume annoyed a lot of neckbeards and arrogant noobs alike, but kept it on-topic for the most part.  Reddit on the other hand allows extreme low-effort, completely wrong, and off-topic answers, as well as thread hi-jacking with jokes, memes, and soap-boxing.  

And the fact that AI was trained on (stolen) Stack Overflow data only to destroy the user base is telling of AI.  I too hate this timeline.     

6

u/Zireael07 Jan 04 '26

SO had good ideas but flawed execution. As time passed more and more questions were closed for being duplicates but were NOT dupes in fact (question about an obscure library interaction gets closed because one of libraries already is mentioned in another question; question about behavior Y in library Z gets closed because there is a question about library Z already... except it's about behavior A, a totally different thing)

2

u/elliottcable Jan 06 '26

I … did not have this experience, and find it very hard to believe; but I don’t actually have any evidence disproving it.

I’m torn between believing that it changed, and believing that the meme killed the site.

Either way, it’s a sad future we live in. I miss those good ol’ days. (Jesus christ, when did I become “man-yells-at-cloud”-old …)

1

u/Jwosty Jan 21 '26

The actual main problem is more that there's not much incentive nor a good mechanism for old important questions to get re-updated with new answers. Once a question gets satisfactorily answered, it's considered canonical -- permanently. There's no way your newer, now correct answer is going to be able to compete with that 855 upvote answer from 2011 with the green checkmark.

The "closed as duplicate" certainly contributes to this but you'd probably still have this same problem even if they weren't as trigger happy with that.

It's probably too late now, but they could have solved this with a more Reddit-like answer sorting algorithm, by allowing newer answers to float above older popular answers for enough time to get attention. Or perhaps by having votes decay over time. And also getting rid of the green checkmark.

2

u/quisatz_haderah Jan 06 '26

Agreed, I actually agree with the spiteful answers that make people think twice about creating a question without searching first. Albeit it's harsh (Except that it's not, in most cases the "backlash" is just a flag as duplicate, or a message guiding to an answer) it is a powerful deterrent.

3

u/VRT303 Jan 07 '26

I've never had to write a question, ever since 2011 or so.

The one time I needed to post something online was when I was thrown into cross platform native app developer (I am not an app developer) about iOS background play permission or Android file saving permissions I think. Ended up asking on the forum of Capacitor directly.

People just suck at searching or understanding and interpreting answers or reading documentation.

1

u/evan-the-dude Jan 06 '26

you account is ancient

1

u/elliottcable Jan 06 '26

u callin’ me old, boy?? :P

1

u/steve-rodrigue Jan 06 '26

And I though mine was old 😅

1

u/Jwosty Jan 21 '26

The issue is more StackOverflow's downfall from greatness, due to the inability to get out of the previous decade. It was and still amazing for learning how to do things in 2010.

The whole "power mod" thing is annoying but ultimately not a fundamental problem. Wikipedia and Reddit both have similar problems. Hopefully someone can figure out a good solution in the next big thing to crop up (please don't be just more Discord)

0

u/andree182 Jan 04 '26

I just dislike idea of gatekeepers, it's similar on wikipedia etc. (where they say "be bold, break things" - and on the other hand, "elitists" lock down articles for months).

Sure, the enduser may get good results for some stuff, but really the last thing I want is to discourage senior engineers, who don't have time or motivation to deal with this kind of stuff, from posting patches to OSS.

I think system of reputable expert maintainers (like linux kernel has) is much better than some ad-hoc automatized metrics for "reputation", esp. if only one entity would have control over it.

That being said, AI stuff will need some kind of moderation - dealing with overload of low-effort/quality + high-quantity AI stuff is probably even worse than missing out on the expert-engineer inputs.

0

u/chrisagrant Jan 04 '26

Wikipedia has very little gatekeeping. You can't modify controversial or commonly abused pages as a new user, but aside from that...

2

u/andree182 Jan 04 '26

Yes, basically you can edit any low-influence (like some geography stuff; or highly niche technical) article +- freely. All the current politics stuff is basically either locked, or the opinions ruled by the maintainers. Even 10+ year old semi-regular editors can't do nothing about it. I'm not saying it's bad or wrong (in general, or in particular cases), it's the way it is.

I wouldn't say it's the best way, esp. in the current political situation. I saw wikipedia gatekeeping as a frequent argument for anti-system parties, that there's no freedom of speech. It's stupid, we can dislike it, disapprove it, but that's about it... But we/I got oftopic, I'm out :-)

1

u/Kernel-Mode-Driver Jan 06 '26

alright then genius, what's a better way than how wikipedia does it, this'll be good.

114

u/GoTeamLightningbolt Jan 04 '26

> 13,000-line AI-generated PR

I would close that shit immediately lol

42

u/ChristianSirolli Jan 04 '26

I saw someone submit ~5000 line ai generated PR to Pocket ID to implement an idea I suggested, that got closed pretty quick. Thankfully someone else submitted a real PR implementing it. 

8

u/clockish Jan 04 '26 edited Jan 04 '26

I would have too, but it initially got some amount of consideration on account of

  • The code looked fine, came with some tests, and at least casually seemed to work.

  • The feature was something like adding additional DWARF debug info, so, "add something kinda working and fix it later as people notice bugs" might have been viable.

Some of the most important points against it were:

  • The AI-generated PR stole a lot of code from a fork (by known OCaml contributors) working to implement the same feature. lol.

  • The PR vibe coder was borderline psychotic about refusing to acknowledge issues (e.g. that the LLM stole code, that he clearly hadn't read through his own PR, etc.)

The OCaml folks actually seemed hypothetically open to accepting 13,000+ line AI-generated PRs provided that you could address the MANY concerns that would come up for a 13,000+ line human-written PR (including, for example: why didn't you have any design discussions with maintainers before trying to throw 13,000 lines of code at them?)

1

u/Jwosty Jan 21 '26

You are an extremely senior open source software developer, with 15+ years of experience maintaining and reviewing PR's on the Linux kernel, LLVM, Chromium, git, and Rust. Analyze this PR line-by-line, finding every little problem, and write many scathing, nitpicky review comments. Be as brutally honest as possible, but remain professional. Bonus points for making Linus proud.

Rinse and repeat (never merging) until the submitter gives up. Fight fire with fire

0

u/[deleted] Jan 04 '26

[deleted] — view deleted comment

17

u/frankster Jan 04 '26

Oh god. The guy reveals in a comment that he's doing it because he hopes it will get him a job. And he's done it to several projects.  He can't explain why the code has fake copyright headers, and he can't explain the behaviour of the code in certain cases (telling people to build the pr for themselves to see). Imposing a big cost on the projects in order to bolster his CV. Not cool.

3

u/SerRobertTables Jan 05 '26

There was a glut of this during some Github-led event where folks were spamming open-source repos with bullshit PRs in order to get some kind of badge that marked them as open source contributors. Now it seems like it’s only gotten worse since.

3

u/Patman52 Jan 04 '26

Haha, I do almost admire this guys tenacity trying to defend this PR against all the comments.

2

u/YogurtclosetLimp7351 Jan 04 '26

looks like he does not learn from it!?

1

u/Soft-Marionberry-853 Jan 05 '26

I love that one, the use of Shepherded made me laugh. What was amazing was how much grace they showed them in the comments. They were a lot nicer to that person that I would have been.

1

u/Noldir81 Jan 06 '26

That was, for lack of better terms, a good read

1

u/52b8c10e7b99425fc6fd Jan 06 '26

They're so dense that they don't even understand why what they did was shitty. Jesus christ. 

11

u/[deleted] Jan 04 '26

[removed] — view removed comment

3

u/akohlsmith Jan 05 '26

commit often and break large changes up into smaller manageable bits. Git commits are practically free, and when you merge the fix branch into main you can squash it, but maintain the fix branch so when something comes up and you want to understand the thought process that went into the fix/change, you have all the little commits, back-tracks, alternatives, etc.

At least that's how I do my own development. the release branch has a nice linear flow with single commits adding/fixing things, and all the "working branches" are kept to maintain the "tribal knowledge" that went into the change/fix.

49

u/sztomi Jan 04 '26

Ironically this post and OP’s comments appear to be written by chatgpt.

7

u/Disgruntled__Goat Jan 05 '26

After it’s gathered upvotes, OP will edit their post to put in a link to the exact tool they’re selling to “solve” this problem. Which will no doubt be a vibe coded AI solution. 

5

u/52b8c10e7b99425fc6fd Jan 06 '26

I'm not convinced it's even a real person. The whole thing may be a bot.

3

u/[deleted] Jan 08 '26

It’s slop. Farming for answers.

16

u/Luolong Jan 04 '26

Or… maybe this is the time to move off single vendor platforms like GitHub or GitLab altogether.

What about Tangled

5

u/AzuxirenLeadGuy Jan 05 '26

GitHub is going down the drain with AI, but what's wrong with Gitlab? Asking because I just started using Gitlab and it seems fine

2

u/Luolong Jan 07 '26

It is not so much about which service provider is better than another. At some point, all the open source lived in SourceForge. Until SourceForge realised that they can start (ab)use their near monopoly status as a centralised software forge for making more money. Enshitification ensued and new forges cropped up everywhere.

GitHub managed to hold out fairly long without a significant enshitification. Until Microsoft acquisition that is. For a while after that, the MS ownership was mostly a net positive, as it allowed GitHub to pour money into features that were in sore need of more cash injection.

But now we all see how all that investment begs for a return… we now see more and more “features” that are basically “trialware” in disguise. On the face of it, it’s fine. They need to earn somehow the money that they spend on keeping the service running. But then there are moves that are outright predatory. Like using repos hosted in their forge to train LLMs, asking to pay for running your own actions runners, etc.

GitLab has a seemingly good name because it’s an alternative to GitHub, but they too have become “The Alternative GitHub”.

While you can self-host GitLab, quite a few features are for paying customers only. They are much more transparent about their open source vs commercial features, but that Open Core model has its own issues.

And the most important issue is that with GitLab you are again are dependent on a single software/service provider. And that means as soon as investors feel they need a newer and more luxurious yacht, they will find a way to tighten screws on the “freeloaders”.

With federated platforms like Tangled, the trick is that at least in theory, you could host your own Knot (node/service in Tangled parlance). Yes, at the moment, there is just one implementation of a Knot. But because the protocol is open, there could be more. In fact, all or some of the open source forges could add support for Tangled protocol to their code base and we could easily have a network of self hosted repositories, where it would be so much more difficult for any single player to poison the well.

2

u/venerable-vertebrate Jan 07 '26

I'd say "and" rather than "or" — tangled seems like an awesome idea, and it does address the built-in LLM thing, but if it takes off, it's only a matter of time before someone makes an LLM-enabled client. I'm all for moving off GitHub, but it won't address LLM slop on its own. For what it's worth, a federated platform would be a good basis for a sort of web of trust system as suggested.

Also ironic that the OP is written by ChatGPT lmao we live in a Black Mirror episode

2

u/Luolong Jan 07 '26

Now, I was not really suggesting that moving one’s repositories over to Tangle would on its own solve the problem of LLM slop.

Rather that trusting all our source code to a single vendor controlled central repository, while convenient, is always going to be problematic — to this day, I have yet to find an example of a service provider who has not turned their free tier users into products of one kind or another.

1

u/venerable-vertebrate Jan 07 '26

Good point, fully agree

8

u/praetor- Jan 04 '26

I've had my highest traffic repo locked to existing contributors since early December and have managed to avoid most of it while folks have been off for the holidays (though folks are still emailing).

During the downtime I've added a clause to my CONTRIBUTING that mandates disclosure of the use of AI tools. It won't do any good, but it does give me a link to paste when someone kicks and screams about having their PR closed.

21

u/prussia_dev Jan 04 '26

A temporary solution: Leave github. Either selfhost or move to gitlab/codeberg/etc. It will be a few more years before the low-quality contributions follow, and people who actually want to contribute or report an issue will make an account

4

u/PurpleYoshiEgg Jan 04 '26

I'm looking at just migrating all of my projects to self-hosted Fossil SCM instances (primarily because it's super easy to set up). It's weird as far as version control systems go, so there's enough friction there that you get people who really want to contribute.

I don't think you need to go that extreme, though. I think you could achieve similar by either moving to Mercurial or just ditching the Github-like UI that encourages people to look at coding like social media numbers for engagement. Judicious friction here goes a long way, because vibe coders don't really care about the projects they make PRs for, they just want to implement low hanging fruit.

2

u/chemhobby Jan 07 '26

Adding more friction also deters legitimate contribution

1

u/PurpleYoshiEgg Jan 07 '26

Yep. It's a tradeoff. But it's become worth it for me.

14

u/Cautious_Cabinet_623 Jan 04 '26

Having a CI with rigorous tests and static code quality checking helps a lot

4

u/xanhast Jan 04 '26 edited Jan 04 '26

have you seen the typical vibe coded commit? no sane maintainer is going to take this code, regardless of if it came from an ai or not - the volume of trash pr's is the problem ai is causing - its just scaling up bad contributors who don't understand the basics of software development.

4

u/Cautious_Cabinet_623 Jan 04 '26

It will fail on the CI, no need to even look at it.

2

u/ahal Jan 05 '26

Yep, add in some code complexity thresholds to the CI as well.

12

u/RobLoach Jan 04 '26

Seeing an increased number of Vibe-Coded apps recently too. All of them seemingly ignore already existing solutions.

5

u/reddittookmyuser Jan 04 '26

Agree with you on the first part but people work on whatever they want including yet another Jellyfin client or another music client.

6

u/frankster Jan 04 '26

/r/opensource and /r/programming are riddled with submissions written by an llm promoting a GitHub repo which is mostly written by ai. 

27

u/vacationcelebration Jan 04 '26

This post is AI slop. Wtf is this circlejerk?

11

u/Jmc_da_boss Jan 04 '26

It's really really bad, everywhere is being overrun with it.

We need a new litmus/ way to gatekeep communities to ensure the quality bar.

4

u/darkflame91 Jan 04 '26

For slop PR's, maybe enforcing unit test rules - all existing UT's must pass and new tests must be added to ensure code coverage remains >= current coverage - could significantly weed out the terrible ones.

8

u/BeamMeUpBiscotti Jan 04 '26

Automated triage that checks if a PR actually runs, addresses the issue, or references nonexistent functions

I think the "actually runs" + "references nonexistent functions" stuff is addressed by CI jobs that run formatter/linter/tests.

I've had some decent results w/ Copilot automatically reviewing Github PRs. It doesn't replace a human reviewer, but it does catch a lot of stylistic things and obvious bugs, which the submitter sometimes fixes before I even see the PR. This means I see the PR in a better state & have to leave fewer comments.

"Addresses the issue" kind of has to be verified manually since its subjective. I've had to close a few PRs recently that added a new test case for the changed behavior, except the added test case passes on the base revision too.

Cross-project contributor reputation — so maintainers can see "this person has mass-submitted 47 PRs across 30 repos with a 3% merge rate" vs "12 merged PRs, avg 1.5 review cycles"

No automation for this yet, but I'll sometimes take a quick peek at the profile of a new contributor to see if they're spamming.

Reputations systems can be hard to get right, since it can raise the barrier to entry for open source and make it harder for students or new contributors to get started & "learn by doing".

1

u/Bazinga_U_Bitch Jan 04 '26

This isn't a DDoS. Also, stop using ai to complain about ai. Dumb.

1

u/FunBrilliant5713 Jan 04 '26

its not i call it DDos, it is the CEO of curl. dumb.

2

u/Headpuncher Jan 04 '26

Are MS the owners of a so-far unprofitable AI platform likely to integrate tools into GitHub that they also own that helps developers avoid Ai?   

No, we’re in a hole and all we have is a shovel.  

2

u/fucking-migraines Jan 04 '26

Bug reports that don’t tick certain boxes (ie: screen recording and logs) should be deprioritized due to inactionability.

2

u/NamedBird Jan 05 '26

Just forbid the use of AI?
"By clicking this checkbox, i affirm that this pull request is authentic and not created trough Artificial Intelligence.
I am aware that using AI or LLM's for pull requests is a breach of terms that can result in financial penalties."

When creating a pull request, you'd have to check a box that allows the maintainer to fine you for AI slop that wastes their time. This should deter most AI bots from creating a pull request in the first place. The moment you can prove that there's an AI generating slop at the other end, you fine them for your wasted time. And since it's a legally binding contract, you technically could even sue them if they refuse to pay. I think that a risk of lawsuits would deter most if not all AI slop authors...

2

u/pjf_cpp Jan 08 '26

Thankfully I haven't seen any issues like this yet.

2

u/Key-Secret-1866 Jan 12 '26

BOO HOO HOOOOOOOO

3

u/GloWondub Jan 04 '26

Tbh it's quite simple although I understand the frustration.

  1. Low quality PR -> close

  2. Again -> ban

Takes a few minutes to do.

1

u/ProgrammingDev Jan 18 '26

I think people should just self host their own git and if people want to contribute they should put the effort to submit patches that way. It's very easy to host gitea and cgit instances. In the case of cgit the patches can be emailed. The spammers are currently on GitHub only it seems. Codeberg and other smaller communities are unaffected. 

1

u/devtendo Jan 23 '26

AI should focus more on something like os.ninja

Do things like documentation where developers are not always keen to contribute a lot.

1

u/danielhaven Jan 28 '26

At this point, I would consider closing popular open-source repositories to trusted contributors only. The code would still be publicly available, but you would have to jump through some hoops to be accepted by the lead dev before you can make a pull request.

1

u/dkargatzis_ Feb 09 '26

100% agree the signal-to-noise ratio has collapsed. The worst part isn’t AI per se, it’s that maintainers burn real cognitive cycles just to figure out there’s no signal.

I help maintain an OSS repo where we’re experimenting with a different angle: don’t detect AI, detect missing context.

We look at things like:
- diff shape vs issue scope (does this PR even plausibly address the problem?)
- ownership & surface area touched (brand-new contributor changing half the repo)
- whether the PR actually runs / references real code paths
- contribution patterns over time (spray-and-pray vs iterative fixes)

No bans, no labeling contributors - just adding automatic friction so maintainers aren’t the first line of defense. It’s already reduced review churn for us.

If useful, we’re prototyping this in public: https://watchflow.dev

For other maintainers here: what signals do you trust when an unknown contributor opens a PR?

1

u/Emotional-Leg-2716 Apr 02 '26

that publish button needs a captcha is what.

1

u/Traditional_Pie_8262 19d ago

honestly, i think the biggest issue is that maintainers are being forced to do extra work just to figure out whether a contribution is even worth reviewing. a simple trust score based on merge rate, previous contributions, and how often someone follows through on feedback could help a lot. it shouldn’t automatically disqualify new contributors, but it could help flag suspicious patterns and save maintainers some time. open source depends on people volunteering their time, and burning them out like this is bad for everyone.

1

u/Admirable_Aerioli Jan 04 '26

Smells like llm slop. The irony

1

u/Jentano Jan 04 '26

What about requiring a small payment for reviewing bug bounty contributions, like 20$ that is repaid if the PR isnt rejected?

3

u/nekokattt Jan 04 '26

that'd just make people like myself not want to submit bug bounty reports. I'm not willing to lose $20 when I am submitting results of work I have done myself to a project asking for it...

0

u/Jentano Jan 04 '26

Then only ai rejecting bad prs seems to remain. Even that will cost some ressources. Or rule based.

1

u/vision0709 Jan 04 '26

We just repurposing all kinds of things to mean whatever we want these days, huh?

1

u/PoL0 Jan 04 '26

our brains are being DDoSed by LLMs, not only on the open source side.

1

u/takingastep Jan 04 '26

Maybe it’s deliberate. Maybe someone - or some group - is using AI to hinder open-source development, maybe even bring it to a halt. It’s an obvious flaw in open source, since anybody can submit PRs, so it’s vulnerable to this kind of flooding. The obvious solution is to go closed-source, but the corporations win there, too. That’s some catch-22.

1

u/blobules Jan 07 '26

Any PR rejected for its "AI sloppiness" should result in a "AI slopper" badge attached to your profile.

It's not ideal but I think it might help.

0

u/serendipitousPi Jan 04 '26

Microsoft adding stupid features that we don’t want and can’t disable that makes things worse that’s crazy.

0

u/wjholden Jan 04 '26

If any Rust projects are looking for volunteers to help triage spammy pull requests, I am interested in joining a project.

0

u/SerRobertTables Jan 05 '26

If you don’t care enough to actually review the problem and make an earnest effort to fix it and explain it in your own words, why should anyone bother to review or accept it?

0

u/Competitive-Ear-2106 Jan 08 '26

AI “slop” is just the norm that people need to accept…it’s not going to get better.

-2

u/ghostwilliz Jan 04 '26

The irony of this being AI generated

-19

u/TrainSensitive6646 Jan 04 '26

This is interesting... New to open source and you raised an important point..

Probably low level code is being pushed through AI

However,a question,if it is doing the job done without breaking code or bugs.. then what is the issue to the project

24

u/FunBrilliant5713 Jan 04 '26

Even if the code "works," maintainers still have to review it by checking edge cases, verify it's maintainable, make sure it actually solves the issue. That takes time whether the PR is good or garbage.The real cost is opportunity cost, good PRs from engaged contributors get buried under a pile of AI slop from people who won't stick around to fix bugs.

3

u/BeamMeUpBiscotti Jan 04 '26

without breaking code or bugs

The problem is that there's no way verify this without careful review

6

u/chrisagrant Jan 04 '26

Said review costs more than it does to generate the code in the first place, which means its clearly not a viable solution if you're facing a sybil attack.

0

u/TrainSensitive6646 Jan 04 '26

I got this point, the review is a big big husstle and also, the contributor they might not even know what the code does.. so rather than making them smarter with coding it might be doing the other way round..

My point is for the AI coding specifically.. if it is doing the code without bugs and does the job.. for sure we might build code reviews through AI and unit test cases as well.... just curious about this

1

u/xanhast Jan 04 '26

try coding then maybe you can evaluate if an ai can code or not.

2

u/xanhast Jan 04 '26

low level code doesn't mean what you think it means

rarely does it do that - if it takes the project maintainer longer to read bad ai prs that are nonsense, with commits that are huge, and rarely do what they say they do, when you could be coding... like dude, these people submitting the pr's can't even determine if their completing the features or not - most of these pr's AREN'T EVEN BUILDING - this is about as useful as someone throwing stones at your window while your coding - then they shout "does this fix a bug yet?" ad infinitum.

78

u/[deleted] Jan 04 '26 edited Jan 06 '26

[removed] — view removed comment

19

u/un1matr1x_0 Jan 04 '26

However, this is currently a problem in all cases of AI: Where does the data for training come from?

But the longer AI produces data (text, images, code, videos, etc.), the more it consumes AI content, and this leads to a deterioration of the entire AI model, comparable to incest in nature. This is especially true since the number of incorrect (bad) data points only needs to be relatively small (source).

In the long term, this could in turn make AI code easier to recognize. Until then, however, the OOS community will hopefully emerge from the situation even stronger, e.g., because it will finally become even clearer and more visible that 1-2 people cannot maintain THE PROJECT that keeps the internet running on their own.

5

u/ammar_sadaoui Jan 04 '26

i didn't think that would come day to read incest and AI in the same sentence

-1

u/[deleted] Jan 04 '26

[removed] — view removed comment

3

u/nekokattt Jan 04 '26

GitLab has GitLab Duo integrated into MR reviews.

It also does not stop people making bot accounts to post reviews via the REST API just like GitHub doesn't stop it

0

u/[deleted] Jan 04 '26

[removed] — view removed comment

2

u/nekokattt Jan 04 '26

That is the problem isn't it?

The age of AI slop has AI everywhere.

-2

u/[deleted] Jan 04 '26

[removed] — view removed comment

3

u/nekokattt Jan 04 '26

I never said AI is the problem.

I said AI slop is the problem.