There’s a version of this conversation that happens on almost every fast-moving team. A deadline is close, confidence is high, the change is “just a small fix”. The pull request gets merged without review. It works fine — until it doesn’t.
Code review isn’t bureaucracy. It’s the cheapest form of quality assurance available.
What review actually catches
The obvious answer is bugs. But that undersells it. Code review also catches:
- Logic that works but will break under conditions the author didn’t consider — the edge cases that only surface when someone reads the code without the context of writing it
- Architectural drift — small decisions that individually seem fine but collectively push the codebase in a direction it shouldn’t go
- Knowledge silos — the one person who understands how a system works, which only becomes a problem when they leave
- Naming and structure problems — code that’s correct but will confuse the next person who reads it, including the author in six months
None of these appear in your test suite. Tests verify behaviour under conditions you anticipated. Review surfaces conditions you didn’t.
The compounding effect
The cost of skipping review isn’t linear. Each unreviewed change makes the next one harder to review. Architectural decisions get baked in. Patterns get copied. What started as a shortcut becomes the established way of doing things.
By the time the compounding cost surfaces — in a production incident, a slow refactor, an onboarding that takes three weeks instead of three days — the original time saved is long forgotten.
Keeping it fast
The legitimate complaint about code review is that it creates waiting. Someone has to stop what they’re doing to look at your work. This is a process problem, not a review problem.
A few things that help:
Keep changes small. A 50-line pull request takes five minutes to review. A 500-line pull request gets a cursory approval because no one has time to actually understand it. Small, focused changes are faster to write, faster to review, and easier to revert.
Write a description. Not what the code does — the code does that. Why it does it, what tradeoffs were made, what you’re uncertain about. A good description cuts review time in half.
Review your own code first. Before requesting review, read the diff as if you didn’t write it. You’ll catch half the comments yourself.
Set expectations on turnaround. A team norm of “reviews within four hours during working hours” removes the uncertainty that makes review feel like a blocker.
On solo projects
Review still matters when you’re working alone. The discipline of writing code as if someone else will read it — because future-you is someone else — produces better work. Self-review, writing clear commit messages, and occasionally explaining a decision in a comment serve the same function: they slow you down just enough to catch what you’d otherwise miss.
The slowdown is the point.