code-review

Code Review

Overview

Catch issues before they cascade. Every change gets reviewed systematically before it ships.

Core principle: Review early, review often. Fresh eyes find what familiar ones miss.

The Iron Law

NO MERGE WITHOUT REVIEW. NO REVIEW WITHOUT EVIDENCE.

When to Use

Mandatory:

• Before merging to main/production branch
• After completing a major feature
• After completing each task in a plan
• Before deploying

Optional but valuable:

• When stuck (fresh perspective)
• Before refactoring (baseline check)
• After fixing complex bugs
• When learning a new codebase

When NOT to Use

• Reviewing auto-generated code (migrations, scaffolds) — verify output instead
• Reviewing dependency lock file diffs — use dependency-audit
• One-character typo fixes (just commit it)

Anti-Shortcut Rules

YOU CANNOT:
- Say "code looks good" — review every changed file, every function
- Say "logic is correct" — trace execution with edge case inputs (null, empty, max, negative)
- Say "tests are sufficient" — verify error paths are tested, not just happy paths
- Say "security is fine" — check for injection, auth bypass, data exposure explicitly
- Say "performance is acceptable" — check for N+1 queries, unbounded loops, missing pagination
- Skip unchanged files in the diff — context matters (does the change break callers?)
- Rubber-stamp small PRs — small bugs in small PRs cause large outages
- Review only the code, not the tests — tests ARE deliverables

Common Rationalizations (Don't Accept These)

Rationalization	Reality
"It's just a small change"	Small changes cause most production incidents. Review it.
"The tests pass"	Tests can't catch what they don't test. Check coverage.
"I trust this developer"	Trust is not a review strategy. Evidence is.
"We're in a hurry"	Shipping a bug is slower than reviewing code.
"It's the same pattern as before"	Same pattern ≠ correct pattern. Maybe the pattern is wrong.
"LGTM"	Not a review. Name one thing you verified.