Code review is one of the highest-leverage activities on a team and one of the easiest to do badly. Done well, it catches bugs cheaply, spreads knowledge, and keeps a codebase coherent. Done badly, it becomes a queue of stale pull requests, a venue for style arguments, and a rubber stamp. This guide covers both sides of the review: how to give a useful one and how to write a PR that is easy to approve.
What changed in 2026
- AI review runs first. Tools built into GitHub, GitLab, and standalone reviewers leave automated comments before a human looks. They catch obvious issues but generate noise, so the norm is to treat them as a checklist, not an approval.
- Linters and formatters ended style debates. With formatters like Prettier, Ruff, and gofmt enforced in CI, almost no one reviews whitespace anymore, which frees human attention for logic.
- Stacked PRs gained traction. Tooling for stacked diffs makes it easier to keep individual reviews small even on large features.
- Review SLAs became explicit. More teams set a target like "review within one business day" because stale PRs, not bad code, are the common bottleneck.
What to actually look for
A useful review focuses on the things tools cannot judge:
- Correctness. Does the code do what the description says? Are edge cases, error paths, and concurrency handled?
- Design. Does this fit the existing architecture, or is it a one-off that will rot? Is there a simpler approach?
- Tests. Do they cover the new behavior and a failure case, not just the happy path?
- Readability. Will the next person understand this in six months without the author present?
- Security and data. Any untrusted input, secrets, or migrations that need a closer look?
Skip the things a machine should own: formatting, import ordering, and trivial naming preferences. If you find yourself typing "nit:" a lot, automate it instead. When a review surfaces a real defect, the next step is to debug it faster rather than guess at a fix in the comments.
Author and reviewer responsibilities
| Stage |
Author does |
Reviewer does |
| Before review |
Self-review the diff, write a clear description, link the issue |
— |
| Size |
Keep it small and focused (one logical change) |
Push back on giant PRs rather than skim them |
| Tests |
Add tests for new behavior and an edge case |
Check tests actually exercise the change |
| Comments |
Respond to every comment, push fixes |
Be specific, suggest, mark blocking vs optional |
| Approval |
— |
Approve promptly once concerns are resolved |
| Disagreement |
Explain reasoning, escalate if needed |
Distinguish "must change" from "I would prefer" |
How to keep reviews fast
- Cap PR size. Aim under ~400 changed lines. Beyond that, review quality drops sharply and reviewers start approving on trust.
- Write the why. A two-line description of the problem and approach saves the reviewer ten minutes of reverse-engineering.
- Self-review first. Read your own diff before requesting review. You will catch the obvious things and add explanatory comments where the code is subtle.
- Mark severity. Reviewers should label comments as blocking or optional so authors are not guessing what stops the merge.
- Set a response norm. A same-day review target keeps work flowing. A perfect review three days late costs more than a good review today.
Common mistakes
- Style policing. If a linter could have caught it, a human should not be commenting on it.
- Vague feedback. "This feels off" wastes a round trip. Point at the line and say what and why.
- Blocking on preference. Reserve a block for correctness, security, and real design problems, not taste.
- Trusting AI review as the gate. It misses context, security nuance, and intent. Use it to clear the obvious, then review the substance yourself.
FAQ
How big should a pull request be?
As small as the change allows, ideally under about 400 lines. Smaller PRs get genuine review attention; large ones get skimmed and approved on trust.
Should I block a PR over style?
No. Enforce style with a formatter and linter in CI so it never reaches a human reviewer. Reserve blocking comments for correctness, security, and design.
Can AI replace human code review?
Not yet. AI review is a strong first pass for obvious issues but misses business context, architectural fit, and subtle correctness. Use it to filter noise, then have a person review intent.
How fast should reviews happen?
Treat same-day as the target. A stale PR queue slows the whole team more than the occasional bug a slightly faster review might miss.
Where to go next
Debug faster when reviews surface bugs, adopt a clean Git workflow, and pick CI/CD tools that automate the checks.