Realistically what happens is the code review is done under time pressure and not very thoroughly.
Petter1@discuss.tchncs.de 3 weeks ago
Well, AI code should be reviewed prior merge into master, same as any code merged into master.
We have git for a reason.
So I would definitely say this was a human fault, either reviewer’s or the human’s who decided that no (or AI driven) review process is needed.
If I would manage devOps, I would demand that AI code has to be signed off by a human on commit taking responsibility with the intention that they review changes made by AI prior pushing
Limerance@piefed.social 3 weeks ago
TehPers@beehaw.org 2 weeks ago
This is what happens to us. People put out a high volume of AI-generated PRs, nobody has time to review them, and the code becomes an amalgamation of mixed paradigms, dependency spaghetti, and partially tested (and horribly tested) code.
Also, the people putting out the AI-generated PRs are the same people rubber stamping the other PRs, which means PRs merge quickly, but nobody actually does a review.
The code is a mess.
heluecht@pirati.ca 2 weeks ago
@TehPers @Limerance why hadn't you time to review it? Every minute in review pays off because it saves you from hours of debugging and handling with angry customers.TehPers@beehaw.org 2 weeks ago
Because if I spent my whole day reviewing AI-generated PRs and walking through the codebase with them only for the next PR to be AI-generated unreviewed shit again, I’d never get my job done.
I’d love to help people learn, but nobody will use anything they learn because they’re just going to ask an LLM to do their task for them anyway.
This is a people problem, and primarily at a high level. The incentive is to churn out slop rather than do things right, so that’s what people do.
Limerance@piefed.social 2 weeks ago
Sure, that’s the theory. In practice code review often looks like this:
- a quick glance to see if the code plausibly does what it claims for longer patches
- A long argument about some stylistic choice for short patches
In other words – people were barely reading merge requests before. Code reviews have limited effects as well. You won’t catch all bugs or see if it actually works just by looking at the code. Code reviews mainly serve to spread knowledge about the code among the team. The more code exists in a project, the harder it is to understand. You don’t want huge areas of code, that only one person has ever seen.
heluecht@pirati.ca 2 weeks ago
@Petter1 @remington at our company every PR needs to be reviewed by at least one lead developer. And the PRs of the lead developers have to be reviewed by architects. And we encourage the other developers to perform reviews as well. Our company encourages the usage of Copilot. But none of our reviewers would pass code that they don't understand.Petter1@discuss.tchncs.de 2 weeks ago
🥰nice!
heluecht@pirati.ca 2 weeks ago
I'm a lead developer. And often I hear from my architect when I missed stuff in some PR that I just checked.
I worked in a lot of different software companies over the last 35 years. And this company has by far the highest standards. It's sometimes really annoying when you maybe coded 8 hours for a use case, just to spend 10-12 additional hours just for the test cases and may some 1-2 additional hours because the QA or the PO found something that needs to be changed. But in the end we can be proud of what we coded.
pinball_wizard@lemmy.zip 3 weeks ago
And you would get burned. Today’s AI does one thing really really well - create output that looks correct to humans.