When 60-80% or so of your PR can be refactored away then it’s a crap PR and honestly never should have been one.
So their time savings in getting AI help to write their code means that you spend more of your presumably more expensive time doing reviews and educating them about slop removal instead of some higher-value activity. Sounds like you’re veering into negative ROI for the AI use if that’s true.
Luckily, I don’t review PRs very often, I have people to do that. But the general principle is that the content of a PR is the responsibility of the submitter, regardless of its source. Wrong algorithm? Their fault. No-good UTs? Their fault. Inappropriate or unsafe dependencies? Their fault. Slop? Their fault.
Luckily, with the work we do, there’s often nothing someone could train an LLM on, so we don’t see all that many PRs with AI-generated content, unless we’re using some well-known commodity library or framework in a common way. And that was always the easy stuff anyway.
A slop PR should be the submitter’s responsibility, but if they’re trying to push out unreviewed slop, you know they’re just going to ask an LLM to refactor it instead of looking at it themselves. The best response is just to reject it outright and have someone else work on a new solution.
I have had a fair amount of success getting AI to do those refactorings, reducing 2000 lines of code to 400, and generating 3000 lines of documentation (including flowcharts) explaining how the 400 lines work, adding 1200 lines of automated testing to prevent regressions, etc. etc.
The shotgun approach with AI is extremely terrible. That’s where you basically give the AI your code, a description of the bug/feature, and ask it to deliver. That’s insane levels of laziness. It’s unprofessional. I’ve done it, hence I know it’s a bad idea. I usually spend more time fighting the AI in these cases because the code turns into a poison. Its context gets filled up with the bad styling, bad decisions, … the code smell gets baked into the attention layer itself, propagating through anything the AI session spits out.
I have much better results when I orchestrate the AI session. I have put together several standard SKILL.md files for doing code-review, grill-me, feature-design, … and I end up using these in whichever order I prescribe to be best. The idea is, I want to guide the session context in the best possible way in order to receive the best possible output from the machine.
I still review output and argue with it a bit, but much less now. I’ve also noticed token consumption go down when I put useful information in things like AGENTS.md
.
So their time savings in getting AI help to write their code means that you spend more of your presumably more expensive time doing reviews and educating them about slop removal instead of some higher-value activity. Sounds like you’re veering into negative ROI for the AI use if that’s true.
Luckily, I don’t review PRs very often, I have people to do that. But the general principle is that the content of a PR is the responsibility of the submitter, regardless of its source. Wrong algorithm? Their fault. No-good UTs? Their fault. Inappropriate or unsafe dependencies? Their fault. Slop? Their fault.
Luckily, with the work we do, there’s often nothing someone could train an LLM on, so we don’t see all that many PRs with AI-generated content, unless we’re using some well-known commodity library or framework in a common way. And that was always the easy stuff anyway.
A slop PR should be the submitter’s responsibility, but if they’re trying to push out unreviewed slop, you know they’re just going to ask an LLM to refactor it instead of looking at it themselves. The best response is just to reject it outright and have someone else work on a new solution.
I have had a fair amount of success getting AI to do those refactorings, reducing 2000 lines of code to 400, and generating 3000 lines of documentation (including flowcharts) explaining how the 400 lines work, adding 1200 lines of automated testing to prevent regressions, etc. etc.
Exactly.
The shotgun approach with AI is extremely terrible. That’s where you basically give the AI your code, a description of the bug/feature, and ask it to deliver. That’s insane levels of laziness. It’s unprofessional. I’ve done it, hence I know it’s a bad idea. I usually spend more time fighting the AI in these cases because the code turns into a poison. Its context gets filled up with the bad styling, bad decisions, … the code smell gets baked into the attention layer itself, propagating through anything the AI session spits out.
I have much better results when I orchestrate the AI session. I have put together several standard SKILL.md files for doing
code-review,grill-me,feature-design, … and I end up using these in whichever order I prescribe to be best. The idea is, I want to guide the session context in the best possible way in order to receive the best possible output from the machine.I still review output and argue with it a bit, but much less now. I’ve also noticed token consumption go down when I put useful information in things like AGENTS.md