Automated review has a poor reputation earned honestly: a bot that leaves fourteen comments on a six-line change, most of them restating what the code does, trains everyone to collapse its output unread. Once that habit forms, the genuinely useful comment it produces next month is also unread.
Used deliberately, though, an agent reviewing a diff is good at a specific and valuable thing: the exhaustive mechanical sweep that humans perform badly because it is boring. The design question is entirely about where it sits and how much it is allowed to say.
Where agents genuinely help
- Consistency sweeps across a large diff — the third of five call sites that was not updated, the error case handled differently from its neighbours.
- Checking the change against conventions stated in the repository, which is tedious for a human and exact for a machine.
- Test gap analysis: which changed branches have no covering test. Mechanical, and reliably useful.
- Explaining unfamiliar code to the reviewer rather than commenting on it — often the highest-value use, and invisible in the pull request.
- Pre-review on the author's machine, before anyone else sees it, where a false positive costs nobody but the author.
That last placement matters more than any tuning. An agent reviewing your own change before you open the pull request has a completely different cost profile: you can ignore the noise instantly, at no social cost, and the useful catches never consume a reviewer's attention at all.
Where it does not
Judgement about whether a change should exist, whether the abstraction fits the direction the team is heading, whether the complexity is warranted for the problem — these require context that is not in the diff and frequently not written down anywhere. An agent will produce a confident opinion on all of them, and its confidence is not correlated with its accuracy.
Security review is the most dangerous one to delegate quietly. Agents catch the obvious injection patterns and miss authorization logic errors — which is the category that actually causes breaches in business applications, because it requires knowing who is supposed to be able to do what.
The failure is not a wrong comment. It is fourteen right-but-trivial comments that teach the team to stop reading.
Reviewing what an agent wrote
The harder problem, now that a large share of changes are agent-assisted, is that generated code reads well. It has consistent naming, plausible structure and comments in the right places, which makes a reviewer's pattern-matching report 'fine' faster than it should. The defects are not stylistic — they are a subtly wrong edge case, an assumption that does not hold in this codebase, or an approach that works and is not how anything else here does it.
- Review generated code more sceptically than handwritten code, not less. Fluency is not evidence of correctness.
- Require the author to have run it and to be able to explain why it works. Submitting a change you cannot defend is the actual problem, whatever produced it.
- Keep the diff small. All of the usual limits on review attention apply, and generation makes large diffs much easier to produce.
- Trust tests and types over reading. Verification scales with generated volume; careful reading does not.
My current arrangement: an agent reviews locally before the pull request opens, a narrow automated pass runs in CI for mechanical rules only, and human review concentrates on design, risk and authorization. The reviewers' time goes to the questions that need a person, and the comment thread stays short enough that people read it.