At Plotly we are dealing with similar issues. We're doing our best to keep up, but it's genuinely hard not to just cut our losses on passer-by community contributions. 3 page issue writeups nobody has proofread, nobody but a bot to follow up with when we try, huge volume of plausible but weak PRs eating up reviewer time. All while we have core work we really want to be focused on rather than merging another bug fix we don't expect anyone but this bot has really run into.

▲

mrkaye97 an hour ago | parent | next [-]

This has basically been the story for us at Hatchet too, and it’s been similarly challenging. A lot of the OSS PR reviews I’ve done lately from non-core contributors are basically just me going back and forth with Claude via someone else, which is frustrating when I feel like I could 1) just not or 2) do the back and forth with Claude myself and cut out the middle man.

I have a sneaking suspicion that people are having some agent check out 500 repos and just prompting with “find a bug in this repo and fix it” and submitting the results blindly.

Edit: typos, on mobile

▲

dspillett 38 minutes ago | parent | next [-]

> I have a sneaking suspicion that people are having some agent check out 500 repos and just prompting with “find a bug in this repo and fix it” and submitting the results blindly.

From the reports coming from a number of places, I'm absolutely sure this is what is happening. People want the glory of finding a named bug, perhaps they believe some more widely useful reputation gain is heading their way if something that their bot finds is actually massively significant. Though it isn't limited to 500 repos, they tell it to just keep going after every one it scans.

▲

BowBun 38 minutes ago | parent | prev | next [-]

>I have a sneaking suspicion that people are having some agent check out 500 repos and just prompting with “find a bug in this repo and fix it” and submitting the results blindly.

This is unironically suggested as a way to 'get in the door' both in bootcamps and 'spammy' universities.

▲

jvanderbot an hour ago | parent | prev | next [-]

Well, contributing to FOSS is a prestige accomplishment. It's viewed as a way in. It's now just a metric to game, and to automate that process is too easy.

Combine this with a growing sense of being "left behind" and a highly publicized collapse in software jobs coming any day now and any proof of contribution is highly prized. So why not?

▲

nemomarx an hour ago | parent [-]

They'll destroy the prestige of it by doing this, though. Unfortunately the OSS model will have to change to cut them off now, and the more people rush it the faster that response will happen.

	▲	jvanderbot an hour ago \| parent [-]
		On the contrary, the prestige will go up - filtering mechanisms, fatigue, and general banning of AI contributions will make it harder to get a PR accepted. If you make it past all that, you are a real one now.

▲

20k an hour ago | parent | prev [-]

I've seen this with godot. People are letting their agents blindly file AI generated PRs even though Godot specifically bans this, and then coming in and giving a very weak apology when they get called out by the devs. A lot of the bugs are incredibly low priority bugs as well that no reasonable person would ever really run into, with these huge long wordy slop reports

Its kind of appalling that people think this is an acceptable way to behave

▲

levkk an hour ago | parent | prev | next [-]

We disabled PRs for PgDog, but left the issues open, for now.

Most bugs that are reported via AI-generated GitHub issues are edge cases, which are technically bugs, but not something anyone actually ran into.

Contributions are exclusively AI-generated, and it's much easier to just go off of a GitHub issue myself than asking the bot behind the GH account to remove the 5 redundant tests it added, or to refactor what has become a 3k line file.

AI doesn't care about code quality, maintenability, or long term goals. It's just a local maximum optimized with RL. Great for debugging, OK for reviews, but can't produce anything that's above average.

	▲	rustystump 20 minutes ago \| parent [-]
		This is pretty spot on. AI will find some off the ball edge case that is a valid edge case but perhaps an undefined expectation of the code. Avoiding the additional complexity of handling it keep everything more grokable and clean. Sadly, people seem to think all these edges AI finds are valid and must be fix and were never thought about. Most were thought about and deemed not worth the additional 50 if statements to handle. Cyclomatic complexity has exploded exponentially with AI and everyones response is “no no no you just need to use opus 6.5 and it will work”

▲

dspillett 43 minutes ago | parent | prev | next [-]

Low quality PRs, along sometimes with concerns of providence that might cause future licensing issues, were a problem before the Eternal LLM September made it easy for far less capable (or caring) people to submit them than before. This is at least part of why a number of projects switched to being “open source but not open contribution”.

▲

qwerpy 2 hours ago | parent | prev | next [-]

Yeah I sympathize with this, but I’ve experienced the other side of this: I ran into a bug (an integration for home assistant has to be manually kicked every time HA restarts due to a bug in the integration) that my AI fixed with a one-liner. It works great for me. I submitted a PR which is languishing for weeks. No problem. My AI will just maintain a personal fork with my patch until my PR gets merged (or not). Previously it was way too much work maintaining your own fork, merging in upstream changes, and keeping your patch working.

I think this is going to be a common outcome from the fact that many people have AI agents that can one-shot fix and deploy. Maybe it’s not a bad thing for those people and the maintainers who each get what they want.

	▲	theptip an hour ago \| parent \| next [-]
		I feel this is something of a temporary and unstable equilibrium. Once the maintainers figure out how to harness agents more effectively, they can just have a daily bot job to poll all the forks and pull back stuff that looks good. We just don’t quite have the tooling and practices to scale the contributor side effectively. I think OSS is going to look more like the original Git model, or perhaps even further towards “horizontal gene transfer” where memes/alleles get copied across various repos, rather than having a single lineage of phenotypes.
	▲	theragra 43 minutes ago \| parent \| prev \| next [-]
		Yeah. I did almost the same with KDE Spectacle. It lacks good shortcut keys for annotations. I've just asked AI to add them. Sent a manually reviewed TINY patch to maintainers, never heard back.
	▲	ultrarunner an hour ago \| parent \| prev [-]
		I would be interested if a common outcome was to have a fork with AI PRs and one with AI contributions disabled. Not only does it satisfy both camps, but it provides a longterm anecdote of the effects of agentic code quality and maintainability.

▲

kardos an hour ago | parent | prev | next [-]

Possible idea: tag them with AI, and leave them aside for 6 months and review them with 2027 AI

▲

verdverm 23 minutes ago | parent | prev | next [-]

The linux kernel team set something up that they are pretty happy with. I don't know the details, but they have dealt with the influx and feel comfortable their solution will last.

https://www.youtube.com/watch?v=NnV_cWeoo5Q

One thing I've been thinking is something like the DCO checks. Set up some account bridge between (eg.) Discord and GitHub, then auto close anything submitted by accounts not sufficiently involved with a message linking to the new contributor policy and rationale.

▲

theptip an hour ago | parent | prev [-]

I’m a little perplexed though. The problem as stated is there’s too many drive-by contributions with AI slop. Isn’t the solution to define a contributor network (eg a GitHub org that you can apply to) based on trust?

The other option they proposed was a proof-of-humanity by payment, which seems much more in line with the above.

The problem with just banning AI is you didn’t solve trust, and your untrusted users are just going to drop drive-by PRs anyway. How do you know if an untrusted user did or did not use AI? In practice this likely means just aggressively closing “slop-looking” PRs from users you don’t recognize?

But then, you’re preventing your trusted community members from benefiting from AI assistance.

I’ve been advocating for defining a higher standard for AI contributors, eg an AGENTS.md that specifies some meaningful correctness bar. In this case, perhaps the PR that adds you to CONTRIBUTORS.md could to add a large novel and non-trivial end-to-end test; if you can construct problems that are easy to verify but hard to get right, then this is your “proof of work” to establish competence.

From reading the GH issue it does seem this is a placeholder solution, so I hope they find a more stable long-term resolution.

	▲	post-it an hour ago \| parent [-]
		> Isn’t the solution to define a contributor network (eg a GitHub org that you can apply to) based on trust? Yes but this is fairly tedious people work that most open source maintainers are not interested in. Once the tooling is available to make that easy, it will become more popular.