AI coding assistants have made pull requests bigger and smoother. A change that used to be 80 lines is now 400, neatly formatted, with tests. Reading every line with the same attention no longer works. Reviewers either slow the team down or start skimming, and skimming is how bugs get approved.
The diff is the wrong starting point
Most review tools open on the diff, so that is where we start. But the diff only shows how something was done. The questions that matter come before it: what problem is this solving, why this approach, and what could break?
When a human wrote every line, the code itself carried a lot of that reasoning. Generated code doesn’t. It is plausible by design, which makes it easy to approve and hard to question.
Ask for the intent up front
I now ask for three short things in every pull request description:
- What and why. One or two sentences, in business terms.
- The decision. Which approach was chosen and which obvious alternative was not.
- The risk. What could go wrong in production, and how we would notice.
If the author can’t fill those in, the change isn’t ready, however clean the code looks. It is also a great prompt for the author to actually read what their assistant produced.
Then review where it hurts
With the intent clear, I spend my attention where mistakes are expensive and skim where they are cheap:
- Boundaries: public APIs, database migrations, anything other teams depend on.
- Security and data: authorisation checks, input handling, what gets logged.
- The tests themselves. Generated tests often check that the code does what the code does, not what the business needs. One good failing case beats twenty green ones.
Formatting, naming and small refactors are for linters and for the author. Not for a senior engineer’s afternoon.
Smaller changes still win
AI makes it tempting to do everything in one go, because generating code is nearly free. Reviewing it isn’t. Asking for smaller pull requests is still the single best thing you can do for review quality, with or without AI.
Code review was never really about finding typos. It is how a team keeps a shared understanding of its system. That job matters more now, not less.
