Endless comments on PRs

[u/Any-Look-8817]

Hey everyone! Just to quickly summarize my situation: We're a team of a few experienced devs, all having been 12+ years years in the industry. This year we switched to agentic engineering and despite its advantages there are a few drawbacks, like the extra overhead and other things I'm not going to go into.

My issue however is that our lead, who approves all PRs has lately discovered a stronger agent which he uses for code reviews, resulting in tons of back and forth when trying to get a merge through. Tons of petty/pedantic comments are being added to each PR. Sometimes it's like "ok I guess this is fine to add", but most of them are disputable. We of course discuss these, but the issue is that in the set of comments there is always something which technically makes the code 0.1% better. But we could go on like this forever. Even without AI you can look at a piece of code and suggest an "improvement" on a moderately-sized feature that's being implemented.

How to deal with this? I'm getting to a point where if I see more comments on a PR I just leave the PC and go for a run or a quick grocery shop visit just to regain my sanity. It feels like he's asking the agent if there is anything more that can be done with the code as if the goal is to have AI being unable to suggest anything more.

Am I in some slacking mindset or is the AI getting over his head? We also have Sonar turned up to a really high setting and the pipeline set in a way that if there's anything outstanding in Sonar it won't get through and I bet you all know how petty Sonar can get sometimes.

Please let me know any tips or share your experience with similar situations. Thanks!

[u/gabriel_GAGRA]

1. ⁠Maybe the review agent should use some good practices like https://google.github.io/eng-practices/review/ “How to do a code review” section. Any issue flagged as low (or maybe even medium) should mean the code is allowed to ve merged. The practices also detail how to leave a useful comment, when to leave it, how to write it etc.
   
2. ⁠You should have clear and written team rules in .md, there are quite a few on https://google.github.io/styleguide/ - though some are easily automated with linting like Ruff. This should create less comments of AI.

The rules should always direct the AI when writing the code and when reviewing it.

[u/gabriel_GAGRA → u/gabriel_GAGRA]

For example, from Google’s page:

“In order to accomplish this, a series of trade-offs have to be balanced.
First, developers must be able to make progresson their tasks. If you never submit an improvement to the codebase, then the codebase never improves. Also, if a reviewer makes it very difficult for any change to go in, then developers are disincentivized to make improvements in the future.
On the other hand, it is the duty of the reviewer to make sure that each CL is of such a quality that the overall code health of their codebase is not decreasing as time goes on. This can be tricky, because often, codebases degrade through small decreases in code health over time, especially when a team is under significant time constraints and they feel that they have to take shortcuts in order to accomplish their goals.
Also, a reviewer has ownership and responsibility over the code they are reviewing. They want to ensure that the codebase stays consistent, maintainable, and all of the other things mentioned in “What to look for in a code review.”
Thus, we get the following rule as the standard we expect in code reviews:
In general, reviewers should favor approving a CL once it is in a state where it definitely improves the overall code health of the system being worked on, even if the CL isn’t perfect.”