Read the comments on a typical pull request and count how many concern something a tool could have flagged. Naming, spacing, import order, a missing type annotation. Those comments consume the reviewer's attention budget and the author's patience, and they crowd out the questions only a person can answer — is this the right approach, does it handle the failure case, will this be maintainable.
Improving review is mostly about removing everything that does not need a human.
What changed in 2026
- AI-assisted review became common. Automated first-pass review catching obvious issues before human review shifted what reviewers spend attention on.
- Volume increased. More code generated more quickly meant review capacity became a visible constraint rather than an assumed resource.
- Latency got measured. Teams began tracking time-to-first-review as a cycle time metric, which surfaced how much waiting dominates.
- Risk-based review spread. Applying different scrutiny to different change types, rather than uniform review of everything, became more accepted.
What belongs where
| Concern |
Handled by |
| Formatting and whitespace |
Formatter, automatically, no discussion |
| Naming conventions and lint rules |
Linter in CI |
| Type correctness |
Type checker |
| Test coverage thresholds |
CI gate |
| Common bug patterns |
Static analysis, and increasingly automated review |
| Is this the right approach |
Human |
| Does this handle the failure case |
Human |
| Will this be maintainable |
Human |
| Does this match the intended behaviour |
Human |
| Security implications of a design |
Human, with tooling support |
The top half should never generate a review comment. If it does, the fix is a tool configuration change, not a conversation — and making that fix once removes the comment permanently rather than repeating it on every pull request.
Latency, size, and clarity
Three practices do most of the work.
Keep diffs small. Defect detection falls as diff size grows, and beyond a few hundred lines review becomes approval theatre. Splitting large work into a reviewable sequence is what stacked diffs workflow exists for.
Review quickly. A pull request waiting a day for first review costs a day of cycle time and forces the author to context-switch back. For most changes, a prompt adequate review is worth more than a delayed thorough one. Teams that treat review as an interrupt to handle within a few hours ship substantially faster than teams that batch it.
Label comment intent. The single largest source of review friction is ambiguity about whether a comment blocks merging. Prefixing comments to indicate blocking, suggestion, or observation removes an entire category of misunderstanding, and it costs nothing.
Match scrutiny to risk. A configuration tweak, a copy change, and a change to payment processing do not warrant the same review depth. Making that explicit — through ownership rules as in code owners guide, or simply through team norms — lets attention go where it matters.
For generated code specifically, the review question shifts. The relevant checks are whether the author understands it, whether it is tested, and whether it fits the codebase — not whether a human typed it. The disclosure side of that is covered in AI disclosure at work.
Common mistakes
- Style comments from humans. Configure the tool instead.
- Large pull requests. Get approved, not reviewed.
- Slow first review. Dominates cycle time more than review depth does.
- Unclear blocking status. The main friction source, trivially fixed.
- Uniform scrutiny. Spends the same attention on a typo fix and a schema migration.
- Approving generated code without understanding it. The author owns it regardless of how it was produced.
FAQ
How many reviewers should a pull request need?
One is usually sufficient with good automation. Two for high-risk paths. More than two rarely improves detection and reliably slows things down.
Should reviewers run the code?
For anything with subtle behaviour, yes. Reading catches structure; running catches behaviour.
What about disagreements?
Escalate quickly rather than iterating in comments. A five-minute conversation resolves what ten comment exchanges will not.
Is AI-assisted review worth it?
As a first pass catching obvious issues before a human looks, generally yes. As a replacement for human judgment on design questions, no.
Where to go next
For keeping changes reviewable, read stacked diffs workflow. For routing, code owners guide, and for capturing design decisions outside review, architecture decision records.