Maybe we should cut out the middle-man and make it easy for people to donate token credits to open-source projects, and let the maintainers decide how to use them.
Maybe we should cut out the middle man and make it easy for people to donate money to open-source projects, and let the maintainers decide whether to use them on tokens or hosting or developer salaries or something else.
Unfortunately "I donated money/tokens to open source" doesn't land interviews as well as "I'm a big contributor to open source"
People spamming Open Source repos with AI PRs aren't trying to help Open Source, they're trying to build a brand, some kind of credible online presence with their username on it, or whatever else. It's purely selfish and completely opposite to the spirit of Open Software imo
>People spamming Open Source repos with AI PRs aren't trying to help Open Source, they're trying to build a brand
I am certain many of them honestly believe that they are doing the right thing and that they are helping. After all hey, they implemented a feature or fixed a bug for the community! It's a grim worldview if you think they are all just selfish.
The high school kid who volunteers at a homeless shelter and hopes it will help their college app is likely doing it both out of altruism and self-interest.
(Actually, the person who helps people because it feels good is also acting out of self-interest).
Given many ways to be altruistic, people will usually pick the ones that coincide more with their self interest. And in turn, self interest can warp a lot of the outcomes, even if people are trying to help.
> there's very little evidence to support this opinion other than just wishing it was true
Building a brand doesn’t require submitting to someone else’s open source project. You can do the same thing by creating your own OSS project.
For a lot of them it’s probably a little of column A and a little of column B.
If people are submitting in their real name it’s more likely they’re building a brand. I also think it’s possible for someone to genuinely think they are helping without trying to build reputation.
Yeah. I'm sure some (maybe a lot?) are for selfish reasons, but there is also a pretty large section of users who have always wanted to contribute, help out, or make some features in their favorite projects and just never had the skill or opportunity to do so and see LLMs as a way for them to final actualize that desire.
Think about it from the perspective of a non-programmer, or even total non-technical person. Vibe coding to someone like that looks like complete magic. Suddenly to that person, a whole new world has opened up. Ideas, features, bug fixes they've always wanted but could never do now look possible. That particular group of people don't see it as spamming the maintainer, they genuinely feel like they're finally able to help.
> they implemented a feature or fixed a bug for the community!
yeah but, did they really?
All IMHO of course, but:
If they understand what they did, it follows that they understand someone has to approve/disapprove that contribution for it to land in the repo, and therefore, size their contributions accordingly to make reviewers lives easier.
If they do not understand what they did, they should not be attempting to land high-value high-complexity contributions yet; they should start with something smaller precisely so they can learn.
Edit: I realize I probably sound too grumpy about it, its just that they could be doing it in their own project, in their own repo, where they're free to go for anything they are comfortable with.
They're stuck in this idea that somehow they're better at prompting the slop generator than anyone else, therefore they're helpful and people definitely want their output merged in to these various projects. They will have trouble understanding that their personal contribution to the whole process is somewhere between negligible and harmful, and simply donating those tokens to a maintainer who is actually aware of how the codebase works and where all the skeletons are is a much better proposition.
There are so many leetcode questions where solving it requires knowing some trick. Part of the trap for SWEs is that once you know the trick you feel smarter, but it really has nothing to do with software engineering.
Now that Claude is the best leetcoder in the world it would be great if companies which intend to hire humans would reconsider asking such dumb questions.
I've personally started focusing a lot more on code quality and communication skills over correctness of solving some leetcode problem. If I could get the infrastructure in place for it in the interview, I would have candidates generate something via AI and watch their process for that (how do they evaluate a plan, how do they review the code, etc.).
A fine example of Goodhart's law: "When a measurement becomes a target, it ceases to be a good measurement."
Measuring open source contributions as a way to judge prospective employees used to be a good measurement.
Of course, prospective employees started to not only contribute to OS projects because it was good, but to make sure their contributions were high and noticeable — contributing not for the good of the project but for their own good, and now with amplification of AI 'contributions'.
So, measuring contributions to open source projects is now approximately worthless for evaluating prospective employees.
This is the most uncharitable outlook on the increase of PRs. It may be true for some contributors, but any company reviewing their GitHub will see that the code is largely spam.
I think most AI generated code is people that want to help the project, but maybe aren’t familiar with the standards and norms.
For now. Give it another half year and "I contribute to open source" will carry the same weight as "I donate to charity" ie nobody cares because any idiot can do it.
I wonder how long it'll take before "I don't use LLMs for coding" carries weight.
I see one big difference: with email it was always about sender reputation based on email servers (IPs), maybe about domains. But never about individual users. It's the organizations running the email server, who make sure users behave. So they don't get blacklisted and lose sending privileges for hundreds or thousands of users.
In my main project we added a new requirement that all new contributors meet a maintainer in a non-textual format before their first PR is merged. Seems to work well for a small project.
Only if you have maintainers everywhere. I live in a small city in the middle of the US - how far is it to a maintainer? 4 hours to Kansas City, or fly to San Francisco? Either way the burden seems far too high.
Isn't the burden being that high the point? It keeps a small team who all know each other working on it, and everyone who does get on the team has some high investment in the project.
Indeed, a request for a short video call filters out most of the people who are looking to pad their resume with LLM-automated contributions, while adding an extra layer of welcome to genuine newbies who want to join the community.
I'm not sure if AI can do those today, but they probably can in the near future. (probably we will be able to see obvious "that can't be human" for a while longer)
I would not be at all surprised if Github adds a first party reputation system. It would be a clever way to increase network effects - imagine if you host on Codeberg you're inundated by AI PRs but on Github you can easily filter them out.
I can't see those pull request limits working very well. It's like trying to filter email spam by just rate limiting people. It's going to be annoying for the people you actually want to talk to, and you're still going to get at least 1 spam message from every spammer out there.
I understand this is a general problem in OSS, but I also hope the irony isn’t lost that this article is specifically complaining about AI slop PRs to the Open Claw repo.
If the maintainers are that tired of it, they should update OpenClaw to prevent it from submitting PRs to their repo.
It would be wonderful if the instructors at those schools built relationships with open source maintainers and the maintainers knew when their students were submitting PRs.
Could be used as a teaching experience that many maintainers would be happy to participate in, instead of feeling attacked with random low quality PRs.
You might be underestimating the number of little schools, and computer shops. I can recall even back in 2005, there were HTML shops popping up here and there, in little cities around the world.
Open source contributions being a great way to learn and to pad out your CV has been considered good advice on all sides of the various seas I’ve lived throughout my career too - it’s not just a dubious code camp thing.
A robust open source profile is my single favorite hiring profile indicator. However, with the current state of things, if I get a whiff of AI-driven "contribution" it becomes an instant black mark against the candidate.
Every single job application form that has a field for your github profile is at fault for this. Juniors trying to break into the industry are trying very hard to check every box.
I've never asked for or looked at anyone's github or personal code as part of a job interview. Too easy to fake, and too much risk that it's something proprietary that could put me in a bad spot.
I never ran into that. I always ask the recruiters to include my GitHub account in the summaries they submit to the technical teams reviewing applications. But they never do.
AI agents who review the slop created by other AI agents is not the answer here.
I much prefer a blanket ban on PRs and issues created by AI agents (which is what I personally do for my repos; so far I have closed one[1]). In fact I would love a github alternative which considers AI contributions to be a breach of their terms of use and ban any people who let AI agents loose on their platform.
Personally I just stopped accepting public contributions entirely. File issues, sure, but no PRs apart from accounts I added who have contributed before the slopageddon started.
Maybe the whole web-of-trust idea will make a comeback for code contributions, it seems like a clean solution.
I think the comparison to email spam is apt. The answer to that problem was automated spam filters.
Imagine the difficulty you might find interacting with the world if your inbox was set up such that all emails not literally written by a human were auto-deleted. No account recovery, no receipts, etc. Individuals might choose to do that for themselves but it's not the general case answer.
That's different though - those are services you explicitly agree to and sign up for, be it at checkout, be it at service signup time, be it because you are making a google account on the google platform.
For example, a github cicd automerge pipeline is still good.
One interesting workflow I've seen is that the project maintainer simply rewrites and implements the pull request themselves and closes the PR.
LuaJIT has operated this way since 2012, though with a thanks and mention in the commit message. It seems like a good way to filter out people who prioritizes leveling up their github profiles.
Something a little bit similar, when I was hosting a social game server we had mods. And players always beg for mod status. At first I tried naming the admin group something weird like sandals, but eventually people would ask if they could be sandals too.
What worked best in the end was just hiding it completely making regular players see mods as other regular players. (mods would see who is a mod though)
I would also personally never make someone who asks a mod as it's almost always a sign of wanting power for the sake if it. I would instead just passively observe behavior until I trusted the player and make them a mod. I would then tell them that I don't expect them to exercise their power, but would demote if I see abuse of power.
But what about the good AI driven contributions though? Do you categorize all AI changes as slop by default or only the real bad ones that mix refactoring and tons of other unrelated changes with a fix?
Some can fix real issues, with a well targeted fix (not rewriting the world), well defined test and write up. If you accepted PRs before for other issues, you should be able to review and accept those too.
I have never gotten a good PR from an AI agent (that I know of) so I guess I’ll deal with it when it happens. I suspect I will still just reject it out of principal.
Why do you ask me to do the categorizing? If you're sending me a PR, then you should be filtering the bad ones from the good. If you're just going to send me drive-by PRs, then I don't have time for you.
I mean, sure, I have to make the final determination. But you should not be sending me uncurated slop.
https://news.ycombinator.com/item?id=48621645
People spamming Open Source repos with AI PRs aren't trying to help Open Source, they're trying to build a brand, some kind of credible online presence with their username on it, or whatever else. It's purely selfish and completely opposite to the spirit of Open Software imo
I am certain many of them honestly believe that they are doing the right thing and that they are helping. After all hey, they implemented a feature or fixed a bug for the community! It's a grim worldview if you think they are all just selfish.
The high school kid who volunteers at a homeless shelter and hopes it will help their college app is likely doing it both out of altruism and self-interest.
(Actually, the person who helps people because it feels good is also acting out of self-interest).
Given many ways to be altruistic, people will usually pick the ones that coincide more with their self interest. And in turn, self interest can warp a lot of the outcomes, even if people are trying to help.
It may happen on smaller projects with few users but not in meaningful large projects.
Building a brand doesn’t require submitting to someone else’s open source project. You can do the same thing by creating your own OSS project.
For a lot of them it’s probably a little of column A and a little of column B.
If people are submitting in their real name it’s more likely they’re building a brand. I also think it’s possible for someone to genuinely think they are helping without trying to build reputation.
Think about it from the perspective of a non-programmer, or even total non-technical person. Vibe coding to someone like that looks like complete magic. Suddenly to that person, a whole new world has opened up. Ideas, features, bug fixes they've always wanted but could never do now look possible. That particular group of people don't see it as spamming the maintainer, they genuinely feel like they're finally able to help.
yeah but, did they really?
All IMHO of course, but:
If they understand what they did, it follows that they understand someone has to approve/disapprove that contribution for it to land in the repo, and therefore, size their contributions accordingly to make reviewers lives easier.
If they do not understand what they did, they should not be attempting to land high-value high-complexity contributions yet; they should start with something smaller precisely so they can learn.
Edit: I realize I probably sound too grumpy about it, its just that they could be doing it in their own project, in their own repo, where they're free to go for anything they are comfortable with.
I wonder if hiring adjusts to that but I doubt it. It might only push it even more towards "marketing matters most" instead of actual ability.
Tech hiring/interviews have almost nothing to do with assessing the candidates' ability to do the job.
Now that Claude is the best leetcoder in the world it would be great if companies which intend to hire humans would reconsider asking such dumb questions.
Measuring open source contributions as a way to judge prospective employees used to be a good measurement.
Of course, prospective employees started to not only contribute to OS projects because it was good, but to make sure their contributions were high and noticeable — contributing not for the good of the project but for their own good, and now with amplification of AI 'contributions'.
So, measuring contributions to open source projects is now approximately worthless for evaluating prospective employees.
I think most AI generated code is people that want to help the project, but maybe aren’t familiar with the standards and norms.
I wonder how long it'll take before "I don't use LLMs for coding" carries weight.
For PRs/issues this is not applicable.
I can't see those pull request limits working very well. It's like trying to filter email spam by just rate limiting people. It's going to be annoying for the people you actually want to talk to, and you're still going to get at least 1 spam message from every spammer out there.
If the maintainers are that tired of it, they should update OpenClaw to prevent it from submitting PRs to their repo.
Could be used as a teaching experience that many maintainers would be happy to participate in, instead of feeling attacked with random low quality PRs.
I much prefer a blanket ban on PRs and issues created by AI agents (which is what I personally do for my repos; so far I have closed one[1]). In fact I would love a github alternative which considers AI contributions to be a breach of their terms of use and ban any people who let AI agents loose on their platform.
1: https://github.com/runarberg/markdown-it-math/pull/48#issuec...
Personally I just stopped accepting public contributions entirely. File issues, sure, but no PRs apart from accounts I added who have contributed before the slopageddon started.
Maybe the whole web-of-trust idea will make a comeback for code contributions, it seems like a clean solution.
I think the comparison to email spam is apt. The answer to that problem was automated spam filters.
Imagine the difficulty you might find interacting with the world if your inbox was set up such that all emails not literally written by a human were auto-deleted. No account recovery, no receipts, etc. Individuals might choose to do that for themselves but it's not the general case answer.
For example, a github cicd automerge pipeline is still good.
LuaJIT has operated this way since 2012, though with a thanks and mention in the commit message. It seems like a good way to filter out people who prioritizes leveling up their github profiles.
Something a little bit similar, when I was hosting a social game server we had mods. And players always beg for mod status. At first I tried naming the admin group something weird like sandals, but eventually people would ask if they could be sandals too.
What worked best in the end was just hiding it completely making regular players see mods as other regular players. (mods would see who is a mod though)
I would also personally never make someone who asks a mod as it's almost always a sign of wanting power for the sake if it. I would instead just passively observe behavior until I trusted the player and make them a mod. I would then tell them that I don't expect them to exercise their power, but would demote if I see abuse of power.
Some can fix real issues, with a well targeted fix (not rewriting the world), well defined test and write up. If you accepted PRs before for other issues, you should be able to review and accept those too.
I mean, sure, I have to make the final determination. But you should not be sending me uncurated slop.