this post was submitted on 07 Jun 2026
80 points (95.5% liked)
Technology
85184 readers
3871 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related news or articles.
- Be excellent to each other!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
- Check for duplicates before posting, duplicates may be removed
- Accounts 7 days and younger will have their posts automatically removed.
Approved Bots
founded 3 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
That is just mostly wrong. Around 90% of the time, when you do a review, just fixing the issue that you found is much faster than explaining the issue and saying what needs to be done instead.
Reviews plainly are for educating the contributor to what constitutes "non-shit"(using your terminology) code on the repo. If that wasn't the case, you could just not do a review and just change the code, without any interaction at all. Why would you communicate the change that needs to be done otherwise?
Rarely of course, something is so complicated that it actually takes more time to come up with the right code than do a review. But that is only a rare thing.
I don't need to explain the issue, that's what the issue report does
I'm sure every project is a little different. The one I maintain has well over 1000 merged PRs now (2000 if you count the old repo), and I'd be dead if I did even 1/4 of the work contributors do
Plus, even maintainers must have a code review and functional testing on their PRs, so doing the work yourself doesn't relieve the human workload that must be done. It actually increases total maintainer effort to do the work yourself
I'm not talking about the work contributors do, obviously that is invaluable.
But if you do a review, and you see that a function should be extracted at one point to avoid code duplication, is it really faster to tell the contributor that a function needs to be extracted there, compared to just extracting it yourself as you see it?
The value of a review is collaborative truth finding and learning. If there is an LLM on the other end, that's just not happening.
The value of any given contribution is the same, regardless of whether the code was written by a seasoned developer, a neophyte as a first project, an LLM, a team of high school students learning the language, or space aliens - the code is the code, it helps or hurts exactly the same when merged with zero connection to who or what wrote it.
Caring about who or what wrote the code is applying prejudice. Prejudice works well in a lot of cases, but it's no guarantee.
If you are accepting submissions from anonymous, or insecurely identified (same thing, really), contributors, they should all be treated with zero prejudice. You might think you know who or what wrote the code based on the name in the linked e-mail address, the way comments are (or aren't) written, or a million other "tells" in the code that aren't about the function of the code - that's really irrlelevant. What's relevant is: what does the code actually do after it's merged.
If you're trusting code because you think its "tells" track with seasoned developers, be prepared - very very soon - for maliciously crafted code full of "seasoned developer" tells to slip in backdoors and other malware, because bad actors are already using AI to mimic the things you want to see in a submission in order to gain your trust and lower your guard against them slipping in the things they want in your code base.