Our team recently adopted agentic engineering, and while it has helped us move faster, our pull request process has become painfully slow. Our lead approves every PR and now uses a powerful review agent that generates a constant stream of comments, many of them minor, stylistic, or technically valid but not important enough to block a merge. We can debate every suggestion, but there always seems to be another 0.1% improvement to make, so the process feels endless.
We already use strict static analysis and a heavily enforced quality gate, which creates even more noise. I'm starting to feel burned out whenever a new batch of review comments appears. I know code can always be improved, but expecting every change to be flawless seems unrealistic and is turning the lead into a bottleneck.
How can we establish a reasonable definition of "good enough," distinguish blocking issues from optional improvements, and discuss this with the lead without making the situation hostile?
5 Answers
An AI reviewer should be configured to prioritize issues instead of reporting every possible improvement. Tell it to consider the scope of the change, avoid stylistic comments covered by formatting tools, and only flag something when there is strong evidence that it could cause a bug, security problem, operational issue, or significant maintenance cost.
You can also have a separate agent summarize or challenge low-confidence findings before they reach the human reviewer. That keeps the lead focused on decisions that actually require judgment.
I would avoid starting with escalation or an aggressive confrontation. Have a direct conversation first: explain that the review agent produces an unlimited supply of marginal suggestions, ask what risks the lead is trying to prevent, and agree on a stopping rule. For example, once tests pass, quality checks are clean, and no high-severity issue remains, the PR should be approved.
If the conversation does not help and the review process continues to block the team, then involve the next manager with data about the delays and propose a concrete alternative. The issue is not that you are unwilling to improve code; it is that the current process has no cost-benefit limit.
This sounds like a process problem that belongs in a team discussion or retrospective. Bring concrete examples showing how many review cycles and hours are being spent on marginal changes, then ask what benefit the extra polish provides compared with the delivery and morale cost.
The goal should not be “the agent can find nothing else to say.” A review is successful when the change clearly improves the system and does not introduce unacceptable risk. Perfect code is not a realistic shipping criterion.
A human still needs to exercise judgment. The fact that a suggestion would make the code marginally better does not mean it belongs in the current PR. If the lead wants a particular design or standard applied consistently, that should be agreed on before implementation and documented as a team rule, not rediscovered through dozens of review comments.
It is also worth questioning why one person approves every change. Peer review or clear ownership boundaries could reduce the bottleneck while preserving accountability.
The team needs explicit review rules. Separate correctness, security, architecture, and maintainability problems from suggestions, style preferences, and future improvements. Only the first group should block a merge. The rest can become follow-up tickets or be noted for a later change.
It may also help to use categories such as blocking, non-blocking suggestion, and nit. If formatting and style are automated, reviewers should not spend time debating them in PRs.
That makes sense. The difficult part is getting the lead to accept that “technically improvable” is not the same as “must change.” I think bringing examples and proposing severity rules will go over better than arguing about individual comments.