this post was submitted on 29 Aug 2026
224 points (96.7% liked)

Linux

14914 readers
472 users here now

A community for everything relating to the GNU/Linux operating system (except the memes!)

Also, check out:

Original icon base courtesy of lewing@isc.tamu.edu and The GIMP

founded 3 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[โ€“] queerlilhayseed@piefed.blahaj.zone 0 points 1 week ago (1 children)

How is treating one contributor fairly unfair to another contributor? If you want to add a "check this box to get your PR dumpster'd" checkbox I guess go nuts, but I'm unconvinced that's a good long-term solution. I find it easier to ask "Do I know this contributor, or did they follow the new contributor guidelines and submit a small, single-issue PR?", and if the answer is "no" then the PR gets ignored or, if I'm feeling gregarious and have the time, rejected with change requests. It's a pretty easy rubric.

Humans have been perfectly capable of generating huge volumes of trash code, and code that looks good at first glance but has tricky bugs or vulnerabilities, since long before LLMs were a thing. The only real change now is the pace at which shitty code can be ripped out. IMO the solution is just: don't accept more code than you can review and test. If that means rejecting 10x or 100x more LoC than you did five years ago, then... ok. It is more busy work, and it is annoying. But I don't think trusting contributors to self-declare LLM use is an answer to the problem. There are better ways of rate-limiting eager beavers, regardless of what tools they use.

[โ€“] FiniteBanjo@feddit.online 4 points 1 week ago

How is treating one contributor fairly unfair to another contributor?

Because sloppers do not actually do the work and in the vast majority of cases are not even capable of doing so. A slopper can produce 10 worthless products in the time a person can produce 1 good product.