Ask HN: Etiquette giving feedback on mostly AI-generated PRs from co-workers
6 comments
10 Find one tiny error somewhere
20 Post something like "I found this error, but I have no time now. I'll review the rest later."
30 Wait until they fix the tiny error
40 GOTO 10
Edit: Similar idea from Joel Spolsky, in the old good times when there was no AI. https://www.joelonsoftware.com/2001/12/25/getting-things-don...
20 Post something like "I found this error, but I have no time now. I'll review the rest later."
30 Wait until they fix the tiny error
40 GOTO 10
Edit: Similar idea from Joel Spolsky, in the old good times when there was no AI. https://www.joelonsoftware.com/2001/12/25/getting-things-don...
Why not demand that code be accompanied by comments that describe the solution at a higher level of design abstraction? Perhaps also a justification of design choices, and comparison with similar implementations in off-the-shelf libraries?
If you're the author/core maintainer of the codebase, well the norm is to ignore the PR entirely. But thank them for the improvement idea/bug report.
If you're just one of the people with commit access, probably your regression testing setup is due.
If you're just one of the people with commit access, probably your regression testing setup is due.
> which part of it reflects their genuine opinion and intellect (which I'd be hesitant to criticize) and what is AI-fluff I can rip apart without stepping on their toes?
Are you able to ask them this directly? They might appreciate it.
Are you able to ask them this directly? They might appreciate it.
Some options:
1. "Your PR is bad and you should feel bad"
2. Use AI to reject the PR
3. Does it fill an immediate business need? Then Ship it. Most code is slop anyways, even before AI era. Otherwise, it's an unjustified continuous maintenance burden - drop it.
Remember all your competitors are also using AI slop. You're in good company...
1. "Your PR is bad and you should feel bad"
2. Use AI to reject the PR
3. Does it fill an immediate business need? Then Ship it. Most code is slop anyways, even before AI era. Otherwise, it's an unjustified continuous maintenance burden - drop it.
Remember all your competitors are also using AI slop. You're in good company...
Here's a take:
Consider a new job that doesn't involve (A)uto(I)nfantillization.
You're destroying humanity.
Usually, when someone does a lot of work, which we used to be able to measure in lines of code, it would seem unfair to criticize them afterwards. A good development process with ticket discussions would ensure that someone doesn't do a lot of work before there is agreement on the general approach. But now, with AI, this script no longer works, partially because it's "too easy" to do it before even deciding this.
So I'm asking myself and now HN: is it OK to point out when an entire PR as such is garbage and should simply be discarded? How can I tell how much "brain juice" a co-worker has spent on it and how attached they might be to it by now if I don't even know whether they even know the code they submitted or not?
I have to admit that I hate reviewing huge PRs and the problem with AI generated code is that often it would have been much better to find and use an existing open-source library to get the task done rather than (re-)generate a lot of code for it. But how will I know this until I've actually taken the time to review and understand the big, new proposed contributions? And even if I now do spend the time to actually understand the code and implied approach, how will I know which part of it reflects their genuine opinion and intellect (which I'd be hesitant to criticize) and what is AI-fluff I can rip apart without stepping on their toes? If the answer is "let's have a meeting", then I'd say the process has failed.
Not sure there is a right answer here, but I would love to hear people's take on this.