There's a tension at the heart of code review.
Review too thoroughly, and you slow down delivery. Developers wait days for feedback. Context is lost. Momentum dies.
Review too quickly, and quality suffers. Bugs slip through. Technical debt accumulates. The codebase degrades.
The goal is the Goldilocks zone: reviews that are rigorous enough to catch real problems but efficient enough to keep work flowing.
The Review Anti-Patterns
The Rubber Stamp (Too Fast)
Symptoms:
- PRs approved within minutes of opening
- Zero or minimal comments
- Review time doesn't scale with PR size
- High rework rate after merge
Why it happens:
- Reviewers are overwhelmed and taking shortcuts
- Cultural pressure to unblock teammates quickly
- Trust (misplaced or not) that the author did good work
- Lack of clear review standards
The cost:
- Bugs reach production
- Technical debt compounds
- Knowledge doesn't spread (reviewer didn't actually read the code)
- Code standards erode
The Perfectionist (Too Slow)
Symptoms:
- Multiple review rounds over many days
- Many comments on style/preference, not substance
- Reviewer rewrites code in comments
- Authors feel demoralized
Why it happens:
- Reviewer ego ("I would have done it differently")
- Unclear distinction between "must fix" and "nice to have"
- No time pressure on reviews
- Reviewer using reviews to demonstrate expertise
The cost:
- Velocity tanks
- Developer frustration and attrition
- Authors stop taking review feedback seriously (noise vs. signal)
- PRs languish, accumulating merge conflicts
Finding the Balance
Metric 1: Review Depth Score
We calculate Review Depth as:
Review Depth = (Comments + Discussions) / (Lines Changed / 100)
This normalizes for PR size. A 500-line PR should have more comments than a 50-line PR.
Healthy range: 0.3 to 1.5
- Below 0.3: Probably rubber-stamping. PRs are being approved without meaningful engagement.
- Above 1.5: Probably over-reviewing. Too much discussion relative to code size.
Track this per reviewer to identify patterns. Some reviewers consistently rubber-stamp; others consistently over-review.
Metric 2: Review Time vs. Quality Outcome
Plot review time against post-merge outcomes:
- Rework rate (code changed within 21 days)
- Bug rate (bugs filed against the PR)
- Revert rate
You'll often find a curve: very short reviews correlate with quality problems. But after a certain point, longer reviews don't improve outcomes—they just slow things down.
Find where the curve flattens. That's your target review time.
Metric 3: Comment Categories
Not all review comments are equal:
High-value comments:
- Bug identification
- Security or performance concerns
- Architectural misalignment
- Missing edge cases
Low-value comments:
- Style preferences (should be automated)
- Naming bikeshedding
- "I would have done it differently"
If most review comments are low-value, reviews are taking time without adding quality. Invest in automation (linters, formatters) and reviewer training.
Implementing Review Standards
Define "Good Enough"
Create explicit criteria for what "approved" means:
Must check:
- Logic correctness
- Test coverage
- Security implications (especially auth, data handling)
- Performance for hot paths
- Error handling
Should defer to author:
- Implementation approach (if it works and is maintainable)
- Naming (unless truly confusing)
- Style (should be automated)
When reviewers know what's expected, they can calibrate effort appropriately.
Separate "Must Fix" from "Consider"
Comments should be categorized:
- Blocking: Must be addressed before merge
- Non-blocking: Suggestions the author can choose to address or not
This prevents the perfectionist trap where every observation becomes a required change. Most comments should be non-blocking.
Set Time Expectations
Establish team norms:
- First review within 4 hours
- Each review round should take < 1 day
- Total review time target: < 2 days for typical PRs
Track against these norms. When PRs exceed targets, investigate why.
The Data View
Velocinator provides review analytics that help teams find their Goldilocks zone:
Review Efficiency Dashboard
- Average review time by team/reviewer
- Review depth score trends
- Comment categorization (if using PR templates with categories)
Quality Correlation
- Review time vs. post-merge rework rate
- Review depth vs. bug rate
- Identifying the "sweet spot" where adequate review meets efficient velocity
Reviewer Patterns
- Which reviewers are consistently fast? Are they rubber-stamping?
- Which reviewers are consistently slow? Are they blocking velocity?
- Coaching opportunities based on data
The Culture Piece
Metrics only work if the culture supports them.
Reward Quality and Speed
Don't just celebrate shipping fast. Celebrate catching bugs in review. Celebrate maintainable code that doesn't need future rework.
Make Review Time Visible
If PRs are waiting, make it visible. Daily standups should include: "Any PRs blocked on review?" No shaming—just awareness.
Protect Review Time
Reviews are work, not interruptions. If developers are too busy coding to review, reviews will either be rushed or delayed. Neither is good.
Learn From Escapes
When a bug reaches production that could have been caught in review, do a brief retrospective. Not to blame—to improve the review process.
The Feedback Loop
Review quality improves through iteration:
- Measure: Track review metrics (time, depth, outcomes)
- Analyze: Identify patterns (rubber-stamping, over-reviewing)
- Adjust: Change standards, training, or expectations
- Remeasure: See if outcomes improved
Over time, you'll converge on the Goldilocks zone for your team: reviews that are thorough enough to maintain quality but efficient enough to maintain velocity.
Neither too hot nor too cold. Just right.
