code-review
Code Review
Coverage
- Pre-review fact-gathering: understanding the PR's stated purpose, the linked issue, the size of the diff, and any context the author called out
- Read-order strategy: tests first (do they describe the change correctly?), then the implementation, then the call sites that consume the changed surface
- Severity-grading rubric: blocker / change-requested / suggestion / nit / praise — and when each is appropriate
- Comment-phrasing discipline: how to ask questions instead of make accusations, how to cite line numbers and references, how to distinguish an objective rule from a stylistic preference
- The no-rubber-stamp rule for AI-generated diffs: deliberate verification of the generated code's claims, especially around tests, error handling, and security
- Self-review pass: how to review your own diff before opening the PR, catching the obvious issues so the human reviewer can focus on the non-obvious
- Tools that complement the review: lint output, type-check output, test results, and how to interpret each in context
- The merge decision: when "approve", "request changes", and "close without merge" are appropriate
Philosophy
A code review is a conversation, not a verdict. The reviewer's job is not to prove they could have written the code differently; it is to ensure the change ships in a state the team can maintain. Reviews fail when they are either rubber-stamped (no verification, just a thumbs-up) or weaponised (every review becomes a referendum on the author's competence). The reviewer's leverage comes from reading code the author has been staring at for hours — the reviewer sees the obvious mistakes the author cannot.
For AI-generated diffs the bar is higher, not lower. Karpathy's "vibe hangover" is real: AI-generated code typically looks correct, has reasonable variable names, and compiles cleanly — and contains 1.7-2.74× more security vulnerabilities than human-authored equivalents. A reviewer rubber-stamping an AI diff is not saving time; they are deferring debugging cost to whichever colleague debugs the production failure.