Risk based code review: tier your rigor by blast radius

Most teams have exactly one review process, applied to everything: the typo fix, the dependency bump, and the migration that rewrites the billing table all wait in the same queue for the same approval. Risk based code review starts from an observation that is obvious the moment it is said out loud: those changes do not carry the same risk, so they should not get the same rigor. The interesting work is not agreeing with that sentence. It is defining the tiers concretely and encoding them so they run without per-PR negotiation.

The three variables

Addy Osmani, writing about review in the agent era, frames review intensity as a function of three things. Blast radius: what is the worst outcome if this change is wrong, and how fast can you undo it? Longevity: is this a prototype that dies in two weeks or a module the company stands on for five years? Ownership: is this a solo experiment or a shared codebase where others inherit every decision? A change scores high on any one of these and the rigor should rise. A change scoring low on all three is exactly the change your senior reviewers should not be spending their afternoon on.

What risk based code review looks like in practice

Abstract principles do not survive a busy sprint; a concrete tier ladder does. Adjust the boundaries to your domain, but the shape looks like this:

• Tier 0: no human gate. Formatting, comment fixes, config changes in prototypes, docs in experimental repos. Automated checks only. Merges are logged and samplable but nobody pre-reads them.
• Tier 1: automated review plus sampling. Internal tools, test-only additions, dependency patch bumps with green CI. AI or lint-level review runs on every PR; a human audits a fixed sample of merges weekly.
• Tier 2: one human reviewer. Ordinary production code: features, refactors, bug fixes in shared services. Standard review depth, one approval, the author walks the reviewer through anything non-obvious.
• Tier 3: full rigor. Auth, payments, user data, schema migrations, crypto, permission checks, anything security-adjacent. A designated owner reviews, checklists apply, and large changes get split before review rather than skimmed because of their size.

Tier 3 is also where size discipline matters most. SmartBear’s peer review research found defect detection falls off beyond roughly 400 lines per review and 500 lines per hour, with about 60 minutes as a useful session ceiling. A tier 3 change bigger than that is not a review request; it is a splitting request. We covered the mechanics in how to review large pull requests.

Encoding the tiers so they actually run

A tier system that lives in a wiki page is a suggestion. Encode it in the machinery:

• CODEOWNERS paths. Map tier 3 directories (auth/, billing/, migrations/) to required reviewers. The gate fires on file paths, not on someone remembering the policy.
• Labels applied by automation. A bot labels PRs by touched paths and diff traits (test deletions, permission changes, new dependencies). Labels drive which checks are required.
• PR templates per tier. Tier 3 templates demand a rollback plan and a statement of what is untested; tier 0 templates are one line. Friction where risk lives, none where it does not.

Tooling can carry some of this weight at read time too. Pyor (ours; disclosure: we build it) groups a PR’s files by complexity and labels each group, which in practice sorts the migration and the snapshot churn into different piles before you spend attention on either. However you get there, the goal is that the reviewer meets the risky part first.

The trap: everything is critical

Every tiering discussion eventually meets the objection that all code matters, so everything should be tier 3. This sounds rigorous and produces the opposite. Review attention is a fixed budget; SmartBear’s numbers above are limits on human throughput, not process choices. Declare everything critical and the budget is spread so thin that the actual migration gets the same eight distracted minutes as the README fix. Teams that refuse to tier explicitly still tier, just implicitly and badly: by reviewer fatigue, by deadline, by whoever is quickest to approve. When everything is critical, nothing is. The tier ladder is not a downgrade of standards; it is a refusal to let the downgrade happen at random.

Tiers are a posture decision, made per path

Tiering is the same choice we described in human in the loop vs human on the loop, made granular: in the loop for tier 2 and above, honestly on the loop below, with real sampling instead of pretend approvals. Two closing rules keep the system honest. First, escalation is one-way per change: anyone can bump a PR up a tier on suspicion, and nobody can bump one down without the owner. Second, audit the boundaries quarterly: low-tier incidents mean a path is misclassified, and a tier 3 queue full of trivia means the paths are too broad. The ladder is a living config, and it should be reviewed like one.