How to Do Code Review in 2026
Style went to the linters. The review that's left is two questions: is this what was actually needed, and what does it touch beyond the diff.
The diff is clean. The tests pass. The naming is textbook. And none of it tells you whether the change should exist.
That gap is the whole story of code review in 2026.
The review you learned was tuned to how humans fail: formatting drift, inconsistent naming, the off-by-one nobody caught, code a colleague won’t understand in six months. Reasonable checks — for code written by hand. AI code fails differently. It arrives well-formatted, consistently named, patterned like the textbook — and confidently wrong. The model optimizes for the prompt it was given, not the problem you actually have, and it never flags the difference.
So the review moved. Style — formatting, naming, patterns, local bugs — went to the machines: linters, formatters, review bots. Automate all of it without guilt. What’s left for the human is the part no bot holds: whether the system, not just the diff, still does what it should.
Review for intent
Intent is the gap between what was asked and what was needed. A change passes on intent when it solves the actual problem, in the right place — not when it satisfies the ticket’s wording. Checking that gap is the reviewer’s first job now, because a model will close the ticket as written even when the ticket is wrong. Ask for retry logic around a flaky call and you’ll get retry logic, exponential backoff and all — even when the actual fix was one timeout value in a config.
Four questions, in order:
- Is this actually what was needed? Not “does it work” — should it exist.
- What’s the blast radius — what can this touch beyond the lines on screen?
- What breaks outside the diff? Contracts, consumers, cron jobs, the pages the diff doesn’t show.
- Is there a fundamentally better approach? A model will happily build a working version of a bad idea.
If you have attention for only one, take the first. Nothing else about a change matters if it shouldn’t exist.
Measure the blast radius
Blast radius is how far a change reaches beyond the diff: the files it touches, the shared utilities it leans on, the contracts it bends, the data it reshapes, the consumers downstream who never saw the PR. A fast proxy: one to three files with local effects is a low radius. Ten-plus files, or anything that crosses an API contract or a schema, is high.
Radius alone isn’t risk, though. Test coverage is the net under the change — what catches the pieces that fall. Risk is the radius times the holes in the net:
| Blast radius | Test coverage | Risk | Strategy |
|---|---|---|---|
| Low (1–3 files) | High (>80%) | Low | Fix in place |
| Low (1–3 files) | Low (<30%) | Medium | Fix, add tests in the same PR |
| High (10+ files) | High (>80%) | Medium | Incremental refactor |
| High (10+ files) | Low (<30%) | High | Tests first, then strangler fig |
Act on the matrix
Low radius, high coverage: approve and move on. AI speed is pure profit here; don’t tax it with ceremony.
Low radius, low coverage: the fix is fine, the net isn’t. Tests land in the same PR as the change — the follow-up ticket never happens.
High radius, high coverage: no big-bang merge. Ask for the change split into steps that land one at a time, so the coverage can tell you which step broke what.
High radius, low coverage: stop. First put tests around what the old code actually does — pin the current behavior before anyone changes it. Then strangler fig: build the new path alongside the old one and move traffic over piece by piece instead of rewriting in place. A model will offer you the whole rewrite in one glorious diff. That’s the offer to refuse.
None of this made review smaller. Style was the part you could do tired. Intent and blast radius take everything you know about the system — the contracts, the consumers, the history, the reasons things are the way they are.
AI didn’t shrink the reviewer’s job. It promoted it.