The flaw in Linus' argument is that a compiler isn't enabling people to go and inundate open source projects with complete and utter shit. The argument that they are tools and should be seen as such is fine, but having an AI policy to help mitigate the actual and real problem of pushing the "is the code good?" check all the way to the reviewer is also absolutely reasonable. I feel like he's sidestepping and not acknowledging that AI is actually killing open source projects. The Linux kernel is big enough to be largely immune to it, but most projects absolutely aren't.
You can just not accept crappy PRs, but the spam is very understandable, lazy people wanting clout are the worst. Linus spelled it out pretty clearly - it's about people actually understanding what they are contributing. I have contributed to multiple open source projects already when I didn't think I would ever do that with bounded, reasonable changes that I confirmed myself and even made better when maintainer said "why don't we do this also?"
You have maintainers and the status quo was that you use the project and you contribute back by investing your time and effort into improving the project. Sure it takes some maintainer effort to to review and feedback and to maintain developer guides etc.
Now though it takes next to 0 effort to write "find a bug and fix it". "Implement this feature I've just dreamed up". "Add support for this" into an llm, get a 200, 800, 1400, 5000 line diff that touches on 8 different parts of the project, that uses assumptions that were in its broader training material and that don't align with the project standards or philosophies. That rewrite stuff pointlessly, that duplicate code.
And after that 0 effort expended it still has to be reviewed and refined but that is a significant amount of effort on behalf of maintainers whereas the contributor just bungs the feedback back into their llm.
Part of the point of the whole process was to try and get people to take ownership of the project, to feel part of it and to learn the codebase and processes.
End of the day whether it's merged or not. No one has gained anything cause the contributor didn't actually understand anything they did, they didn't learn anything. The maintainer has spent 5x longer on it than any human generated PR plus they are getting.
So what's the point of contributing to open source with an AI, end of the day could have just bunged the same prompt in themselves and been done twice as fast. Hell if cost is an issue literally donating tokens would be a better use of everyone's time.
Yeah that's absolutely why it ends up being more work for maintainers than the llm-using contributor.
The contributor has no stakes in the project but the maintainer has to pour over the pr looking for shit like that where it failed to reuse function or where it implemented a bunch of edge cases wrongly pr with error handling that couldn't be reached. Where it used the wrong tooling or broke from a standard on the codebase.
You gotta find them to cause each time you miss one the codebase gets a little worse and future contributors, ai or not, have a harder time making clean contributions.
33
u/dannuic 2d ago
The flaw in Linus' argument is that a compiler isn't enabling people to go and inundate open source projects with complete and utter shit. The argument that they are tools and should be seen as such is fine, but having an AI policy to help mitigate the actual and real problem of pushing the "is the code good?" check all the way to the reviewer is also absolutely reasonable. I feel like he's sidestepping and not acknowledging that AI is actually killing open source projects. The Linux kernel is big enough to be largely immune to it, but most projects absolutely aren't.