51–60 of 162 posts
The problem is really behavioural, not the tooling. People that do not understand, test and document their decision making in their PRs should not be submitting them, regardless of what tooling (AI or otherwise) they used to create them. This problem existed before AI, but it is now just worse due to the spamming nature of these "contributors". It's another form of endless September where people unfamiliar with the n…
what is the appeal of blindly blasting open source projects with high-volume PRs? If you're trying to help the project to accomplish something, it doesn't follow that a firehose approach is tenable, if only for the fact that reviewing the code takes time.
The prestige of being "the one that added feature X to OSS project Y". The things that would've been actually useful (bug diagnostics/troubleshooting, merging duplicate issues & PRs) do not offer the same level of prestige.
what is the appeal of blindly blasting open source projects with high-volume PRs? If you're trying to help the project to accomplish something, it doesn't follow that a firehose approach is tenable, if only for the fact that reviewing the code takes time.
It’s starting to feel like we may need to go back to the model where you need to be invited to be able to submit code or PRs. The barrier is just too low now for popular projects.
It’s not just popular projects. On a small utility I have I received a PR that was more lines than the project had. I’m happy to be a good maintainer, but reviewing something that’s effectively an AI rewrite isn’t something I care to review and since I can’t vet it, can’t blindly accept it.
Something like a big emulator is very complex and has a LOT of motivated users who aren’t going to be able to make quality submissions.
So they get it in volume where it may be nearly impossible to deal with.
We've seen a few takes on this kind of issue, but the solution I liked the best was the linux "developers take full responsibility" approach. The "Assisted-by:" tag was a pretty nice touch too. The article unfortunately feels more like a rant than a good exploration of the problem space.
I've struggled with this "responsibility" take. What does it mean in the context of an open source project? As far as I understand it, the original contributors of bugs are often not the ones fixing them (though they can be). Is it that if you write enough buggy code you get banned as a contributor? Is it that you're not allowed to say Claude ate my homework?
If this is a consistent issue, your contribution would (ideally) be continuously put into a backlog until someone else with no connection to you verifies that it's as bug-free as it appears to be. (Excluding non-obvious security & performance issues)
> Is it that you're not allowed to say Claude ate my homework?
Yes. As the contributor, you should be the first one to look over the code, not someone else.
The problem is really behavioural, not the tooling. People that do not understand, test and document their decision making in their PRs should not be submitting them, regardless of what tooling (AI or otherwise) they used to create them. This problem existed before AI, but it is now just worse due to the spamming nature of these "contributors". It's another form of endless September where people unfamiliar with the n…
[flagged]
what is the appeal of blindly blasting open source projects with high-volume PRs? If you're trying to help the project to accomplish something, it doesn't follow that a firehose approach is tenable, if only for the fact that reviewing the code takes time.
Maybe they use Claude or whatever and tell it to fix the problem and then just blindly submit it.
I could see people doing that without knowing enough to be able to compile and test the code, ignoring whether it’s good or not. So they just submit it and hope it gets merged to “fix” the problem, having no understanding of what’s involved or how much of a burden that is.
Now imagine a whole bunch of people doing that for a whole bunch of really complex bugs in 75 different games. It’s not like the PlayStation three was a simple system.
I'm curious what percentage of PRs are just the AI blindly writing code and submitting a PR without testing, and which have at least been locally tested to some degree. Any OS maintainers have any insights on this?
Thats the thing, what if the codebases had CLAUDE.md / AGENTS.md files, which clearly dictated that A) tests need to pass B) anything you write needs tests C) the code quality must adhere to these standards etc.etc.... Helping the LLMs that people Vibe code with, produce better quality results. By not having these in place, it means people who want to help out, cant. because htey dont understand whats going on. addin…
The motivation to help the OSS project should also come with the obligation to learn how the software operates, at least on a conceptual level. The desire to help does not grant people the pass to sledgehammer their way into adding in a feature.
It’s starting to feel like we may need to go back to the model where you need to be invited to be able to submit code or PRs. The barrier is just too low now for popular projects.
Logistically & brand-wise, they're messy to deal with, but they result in a "filter" of sorts that the original project can pick & choose to upstream back into their code.
I’ve read so many stories like this that I’ve actually gotten scared of making PRs open source projects. There’s one in particular where a feature I really wanted didn’t exist, so I forked and had Codex 5.5 assist with building the feature on my local version. It works perfectly. My life has been improved in being able to have this feature now. Normally I’d want to share it back with the community so others can benef…
First, you don't have to feel guilty of anything, since forking open source projects to make changes tailored to your use case is as old as open source itself. It is, in fact, the primary benefit of open source. Second, it is not a given that your change would be accepted regardless of who wrote it. Maybe the feature is too niche for its complexity, maybe it is better implemented with more generality or extensibility…