PR review is not a rubber stamp, not a gatekeeping ritual, and not something you optimize by minimizing time-to-merge. Structured review workflows with explicit checklists, role-based expectations, and velocity metrics that actually matter.
Most engineering teams measure code review by velocity: how fast do PRs merge? The metric that matters isn’t speed. It’s defect escape rate multiplied by blast radius.
A PR that merges in 15 minutes and ships a regression that takes 3 hours to diagnose is not a fast PR. It’s a fast mistake. The goal of a PR review workflow is not to minimize time-to-merge. It’s to maximize decision quality per review minute.
Not every PR needs the same depth of review. Classify by risk:
Level 1 — Trivial (no review needed)
Formatting changes, dependency bumps with no API changes, typo fixes, comments. These should merge automatically if CI passes. Do not block human attention on them.
Level 2 — Standard (single reviewer)
Bug fixes with controlled blast radius, new features in well-encapsulated modules, refactors with test coverage. Needs one qualified reviewer. The reviewer should understand the domain but doesn’t need to audit every line — they need to verify that the approach is sound and the tests cover the failure modes.
Level 3 — Deep (two reviewers + design sign-off)
Architecture changes, public API modifications, database schema migrations, security-sensitive code. Needs two reviewers, one of whom should be a domain expert. The second reviewer focuses specifically on blast radius and test coverage, not implementation style.
The classification lives in the PR template. The author self-assigns the level. Abuse (marking Level 3 changes as Level 1) is a coaching signal, not a process failure.
A review checklist prevents the “looks right to me” trap by forcing the reviewer to verify specific things. Print this on a card. Put it in your PR template. Make it a checkbox list in every review:
□ Problem: Does the diff solve the problem described in the ticket?
□ Test coverage: Are there tests for the positive case? The edge cases?
□ Blast radius: What else calls the changed functions? Any negative impact?
□ Naming: Do names reflect what the code does, not how it's implemented?
□ Complexity: Is there unnecessary indirection? Is the simplest fix the one chosen?
□ Security: Any user-controlled input paths? Any SQL/command injection vectors?Five minutes per checkbox. If a reviewer can’t check every box with confidence, the PR goes back to Draft.
“Looks Good To Me” is the most dangerous phrase in code review. It means “I read the diff and I’m comfortable with this change.” Too often it actually means “I skimmed the first file and the tests pass, ship it.”
The fix isn’t to ban LGTM. The fix is to make the review checklist the path of least resistance. When a reviewer opens a PR, the template already asks them to check boxes. LGTM becomes a summary, not the review itself.
A good review comment looks like this:
“Line 142: this prepared statement uses a user-controlled value without type casting. The query is safe from injection because of PDO parameter binding, but $id should be cast to int before being used in any context. Also checked: the four call sites in InvoiceController and ReportGenerator — no other consumers affected. Approved with that fix.”
That’s not LGTM. That’s a review.
Stop measuring these:
Measure these instead:
A team with a 0% defect escape rate and 3 concrete comments per PR is doing better than a team merging in 4 hours with a 12% escape rate.
The worst PR workflow is “someone will get to it.” No one does.
Assign the first reviewer at PR creation. The reviewer has a SLA: 4 business hours for Standard, 8 hours for Deep. If the reviewer doesn’t start within the SLA, the PR author escalates to the engineering manager.
The escalation isn’t punitive. It surfaces a capacity problem: the reviewer has too many reviews assigned, or the author is opening PRs outside the reviewer’s domain. Both are manageable once visible.
The best reviewers don’t block PRs. They teach the author to write better code.
When you find a problem, don’t just say “fix this.” Say what pattern you expected, why the current approach is risky, and what an alternative would look like. A review comment that teaches costs 30 more seconds to write and saves hours of future review cycles on the same mistake.
The knowledge base in Calibre (the playbook) is built on exactly this principle: every review teaches a pattern, every pattern gets captured, and the next PR from any author benefits from every prior review.
Related: This is the same discipline that Calibre applies in its PR review phase — evidence-gated checklists, blast radius analysis, and structured feedback that compounds into the playbook. Every review teaches something.