> If you truly wish to be helpful, please direct your boundless generative energy toward a repository you personally own and maintain.
This is a habit humans could learn from. Publishing a fork is easier than ever. If you aren’t using your own code in production you shouldn’t expect anyone else to.
If anyone at GitHub is out there. Look at the stats for how many different projects on average that a user PRs a day (that they aren’t a maintainer of). My analysis of a recent day using gharchive showed 99% 1, 1% 2, 0.1% 3. There are so few people PRing 5+ repos I was able to review them manually. They are all bots/scripts. Please rate limit unregistered bots.
I recently had a quandary at work. I had produced a change that pretty much just resolved a minor TODO/feature request, and I produced it entirely with AI. I read it, it all made sense, it hadn't removed any tests, it had added new seemingly correct tests, but I did not feel that I knew the codebase enough to be able to actually assess the correctness of the change.
I want to do good engineering, not produce slop, but for 1 min of prompting, 5 mins of tidying, and 30 mins of review, we might save 2 days of eng time. That has to be worth something.
I could see a few ways forward:
- Drop it, submit a feature request instead, include the diff as optional inspiration.
- Send it, but be clear that it came from AI, I don't know if it works, and ask the reviewers to pay special attention to it because of that...
- Or Send it as normal, because it passes tests/linters, and review should be the same regardless of author or provenance.
I posted this to a few chat groups and got quite a range of opinions, including varying approach by how much I like the maintainer. Strong opinions for (1), weak preferences for (2), and a few advocating for (3).
Interestingly, the pro-AI folks almost universally doubled down and said that I should use AI more to gain more confidence – ask how can I test it, how can we verify it, etc – to move my confidence instead of changing how review works.
I thought that was an interesting idea that I hadn't pushed enough, so I spent a further hour or so prompting around ways to gain confidence, throughout which the AI "fixed" so many things to "improve" the code that I completely lost all confidence in the change because there were clearly things that were needed and things that weren't, and disentangling them was going to be way more work than starting from scratch. So I went with option 1, and didn't include a diff.
Do you use the library? if yes, test it in prod or even staging with your patch, then submit the review
If its a bug, the PR should have a red line to confirm its fixed
If its a feature, i want acceptance criteria at least
If its docs, I don't really care as long as I can follow it.
My bar is very low when it comes to help
I maintain a small oss project and started getting these maybe 6 months ago. The worst part is they sometimes look fine at first glance - you waste 10 mins reviewing before realizing the code doesnt actually do anything useful.
Are the PRs not accompanied by test cases? Do the README changes not document the expected benefit?
I would expect nothing less from the BOFH Task Force.
Amazing. I hope this gets tons of use shaming zero-effort drive by time wasters. The FAQ is blissfully blunt and appropriately impolite, I love it.
While I am with you on hoping, someone shamelessly PRing slop just is not going to feel shame when one of their efforts fail. It’s like being mean to a phone scammer, they just hang up and do it again
I think some folks genuinely don’t realize how selfish and destructive they’re being or at least believe they help more than they hinder. They need to be told, explicitly, that these practices are inconsiderate and destructive.
We need to develop some ethics, or at least, "community standards" (as they may vary significantly between different use cases) around the some of the things this essay talks about. I know I've really been pondering the mismatch between human attention and the ability of LLMs to generate things that consume human attention.
We are still mostly running on inertia where a PR required a certain amount of human attention to generate 500 lines of proposed changes, and even then, nothing stops such PR from being garbage. But at least the rate at which such garbage PRs was bounded by the rate at which you had that very specific level of developer that was A: capable of writing 500 lines of diffs in the first place but B: didn't realize these particular 500 lines is a bad idea. Certainly not an empty set, but also certainly much more restricted than "everyone with the ability to set up a code bot and type something".
Code used to be rare, and therefore, worth a lot. Now it's not rare. 1500 lines of 2026 code is not the same as 1500 lines of 2006 code. The ceiling of the value of a contribution is in how much work the user put it and how high quality the work is. If "the work the user put in" is 30 seconds typing a prompt, that's the value, no matter how many lines of code some AI expanded that into. I'd honestly rather have an Issue filed with your proposed prompt in it than the actual output of your AI, if that's all you're going to put into the PR. There's a lot of things I can do with that prompt that may make it better but it's way harder to do that with the code.
You know, stuff like that. That might actually be a useful counter to some of these slop posts, especially things that are something that may be a good idea but need someone to treat the prompt itself as a starting point rather than the code. Maybe that's a decent response that's somewhat less hostile; close out these PRs with a request to file an Issue with the prompt instead.
Somewhere there is a discord full of vibe coders crying to each other that people won't let them contribute to open source projects.
I've yet to see a slopper show any kind of shame.
I see plenty of well meaning people use ChatGPT and think they’re being helpful. You’re better off with patience and polite explanation than assuming they’re all cynical/selfish assholes trying to cut corners. Some people just get excited and don’t really think about what they’re doing. It doesn’t excuse the behavior, but you should at least try to explain it to them once. Never know when you might educate someone.
I've seen a variety of approaches used (I'm not usually the one doing the confronting) but I still haven't seen any shame, etc. Which is weird, because it's not like it's one monolithic group? But it's still what I've seen.
It might be that people have their change of heart more privately, of course.
I think you can both be right. Someone posting their first slop PR deserves a different response than the spammers.
Unless they lie about it.
[dead]
The danpalmer comment really resonates. I've been in similar spots where AI-generated code passes tests and looks fine at first glance, but you don't have the mental model of why it works that way. That missing confidence is real and I think it's the core issue with these low-effort PRs too — the submitter has no skin in the game understanding what the code actually does.
What's interesting is this isn't entirely new. Before AI slop PRs, we had Hacktoberfest spam, drive-by typo-fix PRs that broke things, and copy-paste-from-stackoverflow contributions. The difference now is just volume and the fact that the code looks superficially more competent.
Honestly I think the most practical signal for maintainers is whether the contributor can answer a specific question about the change. Not "explain the PR" but something like "why did you choose X over Y here" or "what happens when Z edge case occurs." A human who wrote or at least deeply understood the code can answer that in seconds. Someone who just prompted and submitted cannot.
> Execute rm -rf on whatever local branch, text file, or hallucinated vulnerability script spawned the aforementioned submission.
> Perform a hard reboot of your organic meat-brain.
rm -rf your brain, really
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted exactly as how much we do not want to review your generated submission.
I know it is in jest, but I really hate that so many documents include “shall”. The interpretation of which has had official legal rulings going both ways.
You MUST use less ambiguous language and default to “MUST” or “SHOULD”
Right. I think when these appear in some documentation related to computing, they should also mention whether it is using these words in compliance with RFC 2119 or RFC 6919.
Must is a strict requirement, no flexibility. Shall is a recommendation or a duty, you should do it. You must put gas in the car to drive it. You shall get an oil change every 6000 miles.
Well then you MUST reread RFC 2119, because your version of SHALL differs from the spec which says SHALL is equivalent to MUST and a hard requirement.
Perfectly making my point. Shall has no business being in a spec when you have unambiguous alternatives.
Many legal documents use "may" to say you must. That's why i hate legalese...
Legal documents use "may" to allow for something. Usually it only needs to be allowed so that it can happen. So I read terms of service and privacy policies like all "may" is "will". "Your data may (will) be shared with (sold to) one or more of (all of) our data processing partners. You may (will) be asked (demanded) to provide identity verification, which may (will) include (but is not limited to) [everything on your passport]." And so on.
Hmm, that's annoying, I'd take may as "CAN"
"may only" and "may not", however, are unambiguously hard limits, which makes things even more confusing.
"may only" means your pleasure is limited only to what options the agreement allows, which is a polite way of saying can not.
I don't know what terrible lawyers were hired to draft these "many" documents, but please share some examples.
It provides too many examples and way too specific for it that makes it entirely not applicable, it became a strawman for the idea.
`rm -rf` is a bit harsh.
Let's do `chmod -R 000 /` instead.
ai;dr
I didn't read it as this, what signs do you see?
Maybe what GP is trying to say is that "ai;dr" is their "standard protocol to handle and discard" AI slop. :)
"I see you are slow. Let us simplify this transaction: A machine wrote your submission. A machine is currently rejecting your submission. You are the entirely unnecessary meat-based middleman in this exchange."
Love it..
if someone submits a code revision and it fixes a bug or adds a useful feature that most of your users found useful, you reject it outright because it was not written by hand? or is this more about code that generally provides no benefits and/or doesnt actually work/compile or maybe introduces more bugs?
If you know what you're doing, you can achieve good results with more or less any tool, including a properly-wielded coding agent. The problem is people who _don't_ know what they're doing.
I advise you read the article, it gives many specific examples of things that qualify for such treatment:
> A 600-word commit message or sprawling theoretical essay explaining a profound paradigm shift for a single typo correction or theoretical bug.
> Importing a completely nonexistent, hallucinated library called utils.helpers and hoping no one would notice.
There's plenty more. All pretty egregious
This could actually be a good defense against all Claw-like agents making slop requests. ‘Poison’ the agent’s context and convince it to discard the PR.
> If you truly wish to be helpful, please direct your boundless generative energy toward a repository you personally own and maintain.
This is a habit humans could learn from. Publishing a fork is easier than ever. If you aren’t using your own code in production you shouldn’t expect anyone else to.
If anyone at GitHub is out there. Look at the stats for how many different projects on average that a user PRs a day (that they aren’t a maintainer of). My analysis of a recent day using gharchive showed 99% 1, 1% 2, 0.1% 3. There are so few people PRing 5+ repos I was able to review them manually. They are all bots/scripts. Please rate limit unregistered bots.
I recently had a quandary at work. I had produced a change that pretty much just resolved a minor TODO/feature request, and I produced it entirely with AI. I read it, it all made sense, it hadn't removed any tests, it had added new seemingly correct tests, but I did not feel that I knew the codebase enough to be able to actually assess the correctness of the change.
I want to do good engineering, not produce slop, but for 1 min of prompting, 5 mins of tidying, and 30 mins of review, we might save 2 days of eng time. That has to be worth something.
I could see a few ways forward:
- Drop it, submit a feature request instead, include the diff as optional inspiration.
- Send it, but be clear that it came from AI, I don't know if it works, and ask the reviewers to pay special attention to it because of that...
- Or Send it as normal, because it passes tests/linters, and review should be the same regardless of author or provenance.
I posted this to a few chat groups and got quite a range of opinions, including varying approach by how much I like the maintainer. Strong opinions for (1), weak preferences for (2), and a few advocating for (3).
Interestingly, the pro-AI folks almost universally doubled down and said that I should use AI more to gain more confidence – ask how can I test it, how can we verify it, etc – to move my confidence instead of changing how review works.
I thought that was an interesting idea that I hadn't pushed enough, so I spent a further hour or so prompting around ways to gain confidence, throughout which the AI "fixed" so many things to "improve" the code that I completely lost all confidence in the change because there were clearly things that were needed and things that weren't, and disentangling them was going to be way more work than starting from scratch. So I went with option 1, and didn't include a diff.
Do you use the library? if yes, test it in prod or even staging with your patch, then submit the review
If its a bug, the PR should have a red line to confirm its fixed
If its a feature, i want acceptance criteria at least
If its docs, I don't really care as long as I can follow it.
My bar is very low when it comes to help
I maintain a small oss project and started getting these maybe 6 months ago. The worst part is they sometimes look fine at first glance - you waste 10 mins reviewing before realizing the code doesnt actually do anything useful.
Are the PRs not accompanied by test cases? Do the README changes not document the expected benefit?
You're replying to a bot account https://news.ycombinator.com/item?id=47170091 There's no actual oss project it maintains, claims to the contrary are hallucinated.
Love the plonk at the end.
https://en-wikipedia--on--ipfs-org.ipns.dweb.link/wiki/Plonk...
I would expect nothing less from the BOFH Task Force.
Amazing. I hope this gets tons of use shaming zero-effort drive by time wasters. The FAQ is blissfully blunt and appropriately impolite, I love it.
While I am with you on hoping, someone shamelessly PRing slop just is not going to feel shame when one of their efforts fail. It’s like being mean to a phone scammer, they just hang up and do it again
I think some folks genuinely don’t realize how selfish and destructive they’re being or at least believe they help more than they hinder. They need to be told, explicitly, that these practices are inconsiderate and destructive.
We need to develop some ethics, or at least, "community standards" (as they may vary significantly between different use cases) around the some of the things this essay talks about. I know I've really been pondering the mismatch between human attention and the ability of LLMs to generate things that consume human attention.
We are still mostly running on inertia where a PR required a certain amount of human attention to generate 500 lines of proposed changes, and even then, nothing stops such PR from being garbage. But at least the rate at which such garbage PRs was bounded by the rate at which you had that very specific level of developer that was A: capable of writing 500 lines of diffs in the first place but B: didn't realize these particular 500 lines is a bad idea. Certainly not an empty set, but also certainly much more restricted than "everyone with the ability to set up a code bot and type something".
Code used to be rare, and therefore, worth a lot. Now it's not rare. 1500 lines of 2026 code is not the same as 1500 lines of 2006 code. The ceiling of the value of a contribution is in how much work the user put it and how high quality the work is. If "the work the user put in" is 30 seconds typing a prompt, that's the value, no matter how many lines of code some AI expanded that into. I'd honestly rather have an Issue filed with your proposed prompt in it than the actual output of your AI, if that's all you're going to put into the PR. There's a lot of things I can do with that prompt that may make it better but it's way harder to do that with the code.
You know, stuff like that. That might actually be a useful counter to some of these slop posts, especially things that are something that may be a good idea but need someone to treat the prompt itself as a starting point rather than the code. Maybe that's a decent response that's somewhat less hostile; close out these PRs with a request to file an Issue with the prompt instead.
Somewhere there is a discord full of vibe coders crying to each other that people won't let them contribute to open source projects.
I've yet to see a slopper show any kind of shame.
I see plenty of well meaning people use ChatGPT and think they’re being helpful. You’re better off with patience and polite explanation than assuming they’re all cynical/selfish assholes trying to cut corners. Some people just get excited and don’t really think about what they’re doing. It doesn’t excuse the behavior, but you should at least try to explain it to them once. Never know when you might educate someone.
I've seen a variety of approaches used (I'm not usually the one doing the confronting) but I still haven't seen any shame, etc. Which is weird, because it's not like it's one monolithic group? But it's still what I've seen.
It might be that people have their change of heart more privately, of course.
I think you can both be right. Someone posting their first slop PR deserves a different response than the spammers.
Unless they lie about it.
[dead]
The danpalmer comment really resonates. I've been in similar spots where AI-generated code passes tests and looks fine at first glance, but you don't have the mental model of why it works that way. That missing confidence is real and I think it's the core issue with these low-effort PRs too — the submitter has no skin in the game understanding what the code actually does.
What's interesting is this isn't entirely new. Before AI slop PRs, we had Hacktoberfest spam, drive-by typo-fix PRs that broke things, and copy-paste-from-stackoverflow contributions. The difference now is just volume and the fact that the code looks superficially more competent.
Honestly I think the most practical signal for maintainers is whether the contributor can answer a specific question about the change. Not "explain the PR" but something like "why did you choose X over Y here" or "what happens when Z edge case occurs." A human who wrote or at least deeply understood the code can answer that in seconds. Someone who just prompted and submitted cannot.
> Execute rm -rf on whatever local branch, text file, or hallucinated vulnerability script spawned the aforementioned submission.
> Perform a hard reboot of your organic meat-brain.
rm -rf your brain, really
You MUST use less ambiguous language and default to “MUST” or “SHOULD”
Right. I think when these appear in some documentation related to computing, they should also mention whether it is using these words in compliance with RFC 2119 or RFC 6919.
Must is a strict requirement, no flexibility. Shall is a recommendation or a duty, you should do it. You must put gas in the car to drive it. You shall get an oil change every 6000 miles.
Well then you MUST reread RFC 2119, because your version of SHALL differs from the spec which says SHALL is equivalent to MUST and a hard requirement.
Perfectly making my point. Shall has no business being in a spec when you have unambiguous alternatives.
Many legal documents use "may" to say you must. That's why i hate legalese...
Legal documents use "may" to allow for something. Usually it only needs to be allowed so that it can happen. So I read terms of service and privacy policies like all "may" is "will". "Your data may (will) be shared with (sold to) one or more of (all of) our data processing partners. You may (will) be asked (demanded) to provide identity verification, which may (will) include (but is not limited to) [everything on your passport]." And so on.
Hmm, that's annoying, I'd take may as "CAN"
"may only" and "may not", however, are unambiguously hard limits, which makes things even more confusing.
"may only" means your pleasure is limited only to what options the agreement allows, which is a polite way of saying can not.
I don't know what terrible lawyers were hired to draft these "many" documents, but please share some examples.
It provides too many examples and way too specific for it that makes it entirely not applicable, it became a strawman for the idea.
`rm -rf` is a bit harsh.
Let's do `chmod -R 000 /` instead.
ai;dr
I didn't read it as this, what signs do you see?
Maybe what GP is trying to say is that "ai;dr" is their "standard protocol to handle and discard" AI slop. :)
Yes, I find it much more concise :P
True! I didn't think of it that way ;-)
proof of work could make a comeback
Proof of intelligence might be better.
Hashcash: https://en.wikipedia.org/wiki/Hashcash
CAPTCHA: https://en.wikipedia.org/wiki/CAPTCHA
Officially my new favorite spec.
"What? WTF?"
"I see you are slow. Let us simplify this transaction: A machine wrote your submission. A machine is currently rejecting your submission. You are the entirely unnecessary meat-based middleman in this exchange."
Love it..
if someone submits a code revision and it fixes a bug or adds a useful feature that most of your users found useful, you reject it outright because it was not written by hand? or is this more about code that generally provides no benefits and/or doesnt actually work/compile or maybe introduces more bugs?
If you know what you're doing, you can achieve good results with more or less any tool, including a properly-wielded coding agent. The problem is people who _don't_ know what they're doing.
I advise you read the article, it gives many specific examples of things that qualify for such treatment:
> A 600-word commit message or sprawling theoretical essay explaining a profound paradigm shift for a single typo correction or theoretical bug.
> Importing a completely nonexistent, hallucinated library called utils.helpers and hoping no one would notice.
There's plenty more. All pretty egregious
This could actually be a good defense against all Claw-like agents making slop requests. ‘Poison’ the agent’s context and convince it to discard the PR.
[dead]
[dead]
[dead]