The craft of code review — what to look for, how to give feedback, and the practices that make review a force multiplier, not a bottleneck.
The first post in a practical series on code review — what the practice is actually for, what it is not, and why treating it as a collaboration rather than a gate is what makes it worth the time it costs.
The opener to a code-review series: what review is actually for — catching defects early, better design, knowledge sharing, collective ownership — and what it isn't (gatekeeping, style bikeshedding), plus the healthy team norms that make it work.
A reviewer's mental checklist ordered by leverage — design first, then correctness, then tests, then readability, with style and formatting handed off to the tools that were built for it.
A reviewer's checklist ordered by leverage: design first, then correctness and edge cases, then tests, then readability — and what to leave entirely to tools (formatting, lint) so human attention goes where it matters.
How to write code-review comments that improve the code and the relationship at the same time — commenting on the code not the coder, labeling severity so the author knows what blocks, asking instead of decreeing, teaching the why, and knowing when a thread belongs on a call.
Writing review comments that improve the code and the relationship: comment on the code not the coder, be specific and actionable, label severity (nit/suggestion/blocking), ask questions when you lack context, and pick your battles.
The author's side of code review — turning a pull request from an ego threat into a growth loop by separating your identity from your code, responding to every comment, and pushing back with reasoning instead of feelings.
The author's side: separating your identity from your code, assuming good intent, responding to every comment, pushing back with reasoning (not ego), and turning review into a growth loop instead of an ego threat.
Half of review quality is decided before the reviewer ever opens the diff — by the author. Small focused PRs, a description that states what and why, a self-review pass, and clean commits are how you optimize the one resource a review really spends: the reviewer's attention.
Half of review quality is set before the reviewer arrives: small focused PRs, splitting big changes, great descriptions (what/why/how-to-test), self-review first, and keeping refactor noise out of behavior changes.
The two specialist lenses a reviewer switches on for a diff — thinking like an attacker to catch the injection and the missing authorization check, and thinking like production to catch the N+1 query — while knowing exactly where the human eye stops and a scanner, profiler, or load test has to take over.
The specialist lenses: security review (untrusted input to a sink, missing authz/BOLA, secrets, SSRF, new dependencies) and performance review (N+1 queries, unbounded queries, missing indexes) — flag the smells, defer depth to scanners and profilers.
How to run code review across a whole team or organization without turning it into a bottleneck: treat review latency as a first-class metric, distribute the load, let automation handle the toil, and measure the things that actually predict quality.
Making review work across a team without becoming a bottleneck: review velocity as a first-class metric, ownership and routing (CODEOWNERS), automating toil so humans do judgment, healthy SLAs, and measuring the right things.
The series finale — where LLM reviewers genuinely help on every pull request, where they quietly fail, and how to build a human-plus-AI workflow that speeds review up without letting judgment or accountability leak away.
The capstone: using AI/LLM reviewers well and where humans stay essential — AI as a tireless first pass that clears the noise, its limits (design judgment, contextual security, accountability, hallucinations), and a healthy human+AI division of labor.
This series is part of a larger body of work by Pratik Dhanave, an Agentic AI Architect writing about production AI systems, distributed systems, and cloud-native engineering. Explore all course series, browse every post, or find topics via the tag index.