Requiring more approvals does not reliably make code safer. One engaged reviewer who reads a small change beats three who skim a large one. Published guidance from DORA and Google points the same way: keep review light enough that changes stay small and get read.
Myth: three approvals are safer than one
Fact. DORA lists heavyweight code review as a pitfall of trunk-based development. Multiple required approvals discourage small changes, so developers batch their work. Reviews become large and hard to assess, and defects slip through.
Each extra required approval also spreads responsibility. When three people sign off, each can assume the others looked closely.
Myth: reviewers should hold out for perfect code
Fact. Google's review standard says reviewers should approve a change once it clearly improves the health of the codebase, even if it is not perfect. It says there is no perfect code, only better code. It also says changes that clearly harm code health should not merge, with emergencies as the only exception.
That standard has a security reading. Block on things that make the system less safe. Do not block on taste.
Myth: slow review is careful review
Fact. Delay is not depth. DORA notes that asynchronous review delays increase merge conflicts, and recommends reviewing synchronously when code is ready. Google's guidance says not to let a change sit because author and reviewer cannot agree, and describes escalation steps if talking it through fails.
A reviewer who answers within hours and reads thoroughly is worth more than one who answers in three days with a rushed look.
Myth: the second reviewer will catch what the first missed
Fact. Sometimes. But a second reviewer is better used deliberately. Instead of a blanket rule, route by risk:
- Ordinary changes: one approval from a peer.
- Changes to authentication, authorization, cryptography, build and deploy configuration: one approval from someone who owns that area, enforced by code owners.
- Anything touching secrets handling or permissions: owner approval plus a named security reviewer.
This puts attention where the danger is, without taxing every typo fix.
What to do instead of adding approvals
- Keep changes small so the first reviewer can really read them.
- Make automated checks mandatory: tests, static analysis, dependency checks.
- Mark comments as blocking or optional. Google's guidance suggests labeling minor polish as a nit that authors may ignore.
- Require approval from someone other than the last person to push.
- Measure time to first review and time to approval.
Review is one layer. Reachability analysis and dependency scanning in Safeguard add automated reading of what a change pulls in, which no human approver will do reliably. Try the free scan at gold.safeguard.sh/scan.
Quick check
Should security-sensitive paths have a second approver?
Often yes, but make it targeted with code owners for those paths, not a blanket rule on the whole repository.
Can a reviewer approve code they would write differently?
Yes. Google's standard says to approve when the change improves code health, and to settle style questions with the style guide and technical facts, not personal preference.
Sources
Last reviewed: 19 October 2026.
