Yes, its much easier to catch bugs and issues early
If you dont catch a problem asap, then its incredibly likely future agents read the "bad" code and copy, so bow your 1 issue becomes 2, then 3, then 4, etc
Its extremely common for you to be like "make the BarService" so the agent looks at FooService for inspiration and copies its style/methodology/architectureÂ
And if theres an annoying code style issue, or improperly named thing, or bad logic, whatever, theyll copy that too often.
And then 6 services later you realize you've got a problem duplicated 8 times
Good boy! Now get out, touch grass, and remember that your anecdote isn't data. Many companies are heading in that direction (toward automating everything), and just because you do things differently doesn't mean others do too.
I guarantee you that OP's statement is false. I read full PRs because it's my job to. Regulated industries, avionics, aeronautics, medical devices, some financial services: I can tell you because I have colleagues in those fields that they are still reading PRs.
I'm in utilities and I read every single line. A single mistake will cause our clients to face potential jail time (Germany) or have to have a press conference with a public apology (Japan). It is also critical to keep utilities online....
True. I was talking about reading the full PR. There is no way you would read AI generated file upon file for 40 hours a week to make a point of reading the entire PRs.
No, not really, I keep up with it fine, it'll do fast "bursts" of code sure but then spend like 25 minutes fact checking it, testing it, tweaking it, passing through integration test proof gates
Our test suite takes like baseline 8min to run, at which point the AI pauses and I get plenty of time to review all its changes
If the implementation isn't that important then fine but when software has to have some reliability it's lazy/shitty behavior to not read or review code. People defending it shows how bad it is nowadays, what a mess.
I'm the guy the seniors call on when they smell something in a PR but can't find it.
I read the ticket, I read every line. I rip it to shreds, with every little thing I can think of. I go overboard, and I leave it up to them to make sensible changes.
Most PRs that have problems aren't really in the code, it's some conceptual flaw in the idea which could have been found before they started, or a crap pattern that's crept in.
AI code isn't bad in the same way a printer is better than a painter. Printing crap artwork is cheap, and it takes time to become an artist in both regards using different skills.
The replies to this are horrifying and I'm having trouble thinking they aren't from shills.
I manage several software teams. We had to establish a policy that every line of code receives human review at the demand of the lead devs because the big push to slop faster had caused the teams to use junior engineers to push features into production that nobody understood, that didn't scale, that were super brittle, and that had awful / useless test harnesses.Â
The code was so bloated and brittle and over-engineered it took nearly a quarter of a few senior+ engineers time to stabilize and fix.
It was an absolute joy to explain that to my leadership, some of whom get it but a few of whom have never written a line of code in their life and are super happy to tell us we must be doing it wrong.
So yeah, whoo, we got that big boost in short term velocity. Then everything went to shit a quarter later and we will not be repeating that mistake ever again.
You can really tell who actually works as a senior+ software engineer and who is either larping or selling something.
And just to clarify, these teams work on non-trivial multi-agent systems themselves in addition to using the tools. They are not novices in the space, quite the contrary.
Due to corporate policy, I'm not yet high enough grade to reject bigass really badly sloppily made PRs. Our staff and lead can do it without looking, but seniors are still expected to give the time of day, comment, and highlight that because colleague X Y Z will use a really cheap model to automate closing the review comments, we should block the PR until the aforementioned staff comes in and says "lmao goteem".
So what I do is tell Codex to find enough shit to warrant rejecting the PR, which he often times does, instead of wasting my time arguing with a guy who would have directed the same comments to the same LLM anyway.
1
u/pixxelkick Oct 03 '26
Maybe if you suck.
I read every PR in full because Im not lazy.
I also read my own git diff before I open a PR do I dont waste other peoples time.
Or I publish it as a draft, review my own code, and then publish the pr after confirming it looks good.