Code review best practices - reviews that don't slow the team down

How to keep code review fast and useful at the same time - small PRs, clear review levels, latency norms, and what reviewers should actually look for (and skip).

Mar 26, 2026 · 4 min read · Kash Gohil

Code review is the highest-leverage quality practice most teams have - and the most common bottleneck. The failure modes are opposites: rubber-stamp reviews that catch nothing, or thorough reviews that take three days and stall every branch. This guide is the set of practices that keep review fast and useful, drawn from what consistently works on small teams.

What is code review actually for?

Rank these, because they conflict under time pressure:

Catching problems the author can't see - design flaws, missed cases, security holes. Not style.
Spreading knowledge - after review, two people understand the change. This is how teams avoid single-person silos.
Keeping the codebase coherent - one system, not an archipelago of personal styles.

What review is not for: formatting and lint-catchable issues (automate those - a human pointing out a missing semicolon is the most expensive linter ever built), and re-litigating the approach after the work is done. Approach belongs in the RFC, before the code exists.

Why do reviews take days, and what fixes it?

The size problem. Review quality collapses with diff size - a 100-line change gets ten careful comments; a 2,000-line change gets "LGTM." Large PRs are also intimidating, so they sit. The single highest-impact practice on this page: keep changes under a few hundred lines, stacking dependent PRs rather than accumulating one giant one. Small PRs are reviewed same-day almost automatically.

The latency norm. Set an explicit team expectation: first response within N hours (same-day is the common choice), and review passes batched two or three times daily rather than interrupt-driven - review is important enough to schedule and not urgent enough to break someone's focus block.

The ambiguity problem. Every PR should declare what kind of review it needs. A one-line label works: careful (new design, security-adjacent), normal, or glance (config bump, rename). Most review-latency pain is careful-grade effort applied to glance-grade changes.

What should a reviewer actually look at?

In order, stopping when time runs out:

Does it do the right thing? Read the linked issue or spec first, then ask whether this change achieves it. The most valuable question and the most skipped.
What happens at the edges? Empty inputs, failures midway, concurrent access, the unhappy paths the author didn't walk.
Will the next person understand it? Naming, structure, and whether the tricky part has the comment it needs.
Are the tests testing anything? A test that can't fail is decoration.

And a discipline for comment tone: distinguish blocking ("this breaks X") from non-blocking ("consider Y - your call"). Reviews stall when every suggestion implicitly demands another round-trip. Prefix nits as nits, and let authors merge past them.

How does AI change code review?

Two ways, pulling in opposite directions. AI reviewers (first-pass tools, or an agent reviewing the diff) are genuinely good at the mechanical middle of the list - edge cases, inconsistencies, forgotten error paths - and they never get tired or embarrassed. Let them run first, so humans spend their attention on questions 1 and 3, which need product and team context AI lacks.

Meanwhile agents writing code multiply the volume needing review - review becomes the bottleneck of an agent-forward team almost immediately. The practices above stop being nice-to-haves: small described changes, explicit review levels, and a spec attached to the PR so the reviewer can check intent, not just correctness. In Rezee, the PR carries its issue and spec with it in Code & Ship, and review discussion stays anchored to the code it's about - the structure that keeps "did it build the right thing?" answerable.

What norms make this stick?

Author prepares the review. A description that says what, why, and how to verify; a self-review pass first (authors catch a third of issues just re-reading their own diff in the review UI).
One primary reviewer, explicitly named - "anyone" reviews nothing. Add a second only for careful changes.
Merge is the author's job once approved - don't let approved PRs rot.
Disagreements escalate to a conversation, not a comment thread past three round-trips. Ten minutes of talking resolves what ten comments can't.

FAQ

How long should a code review take?

Minutes-per-line, not days-per-PR: a well-sized (100-300 line) change deserves 15-30 focused minutes. If reviews routinely need an hour, the PRs are too big - fix the size, not the reviewer.

Should every change be reviewed?

Every change to shared code, yes - but not at the same depth; that's what review levels are for. Teams that exempt "small" changes discover that outages arrive disproportionately through them.

How many reviewers per pull request?

One named primary for most changes; two for high-risk ones. More reviewers dilute responsibility - everyone assumes someone else read it carefully.

Are AI code reviews good enough to replace human review?

No - they're a strong first pass, not a replacement. AI reviewers excel at mechanical issues and edge-case spotting but can't judge whether the change is the right change for the product and the team. The winning setup is AI first, then a human on intent and design.