What Is Risk-Based Code Review?

Quick answer
Risk-based review classifies a change by what happens if it is wrong, then assigns review depth accordingly.
The classification is about blast radius, not diff size: a five-line authorization change outranks a 300-line rename.
Useful signals are the paths touched, whether the code runs without a human, and whether the change is reversible.
The point is to spend scarce reviewer attention where it changes outcomes, not to skip review everywhere else.
Automate the low-risk tier with tests, linters, and an AI reviewer, and reserve humans for the high-risk tier.

How do you classify a change by risk?

Ask three questions. What can this code reach — data, money, other users’ records, infrastructure? Does it run without a human present, such as a cron job, webhook, or agent? Can it be undone quickly if it is wrong?

A change that touches authentication for a public app, writes to a shared table, and cannot be rolled back is high risk regardless of how many lines it has. A change to an internal dashboard’s copy is low risk even if it is large.

| Tier | Examples                                          | Review                              |
|------|---------------------------------------------------|-------------------------------------|
| High | auth, payments, migrations, infra, agent tools    | Named human reviewer, tests required|
| Med  | API handlers, background jobs, config            | Human review, automated checks      |
| Low  | docs, tests, internal UI copy, renames            | Automated checks, spot review       |

How do you route changes automatically?

Code owners and path filters do most of the work: a change under the auth or migrations directory requests the owning team. Add labels from file paths, and require an approval from that team for high-risk paths.

Keep the rules visible in the repository. A reviewer who cannot see why their team was requested will either rubber-stamp or resent the process, and both erode the mechanism.

What does low-risk review look like?

Automated checks, an AI reviewer for obvious defects, and a human spot check on a sample. That is not no review; it is review matched to consequence. The sample matters, because it catches systematic problems that per-change review would miss.

Reclassify when the change is wrong about its own tier. A “docs” change that edits a deployment script is high risk, and the label is not the truth.

How does this interact with agent-generated code?

It makes agent volume manageable. If every generated change receives the same deep review, the queue collapses. If high-risk paths get deep review and low-risk paths get automation plus sampling, the team can absorb more changes without lowering the standard where it matters.

The caveat is that agents are good at producing changes that look low risk. Review the classification itself when a change touches more than its label suggests.

Where this bites vibecoders
A generated pull request will describe itself as a small refactor even when it changes a permission check, because the model describes intent rather than consequence. Classify by the paths and behaviour, not by the description.

Where AI coding assistants get this wrong

Classifying by diff size instead of blast radius.
Trusting the change’s own description of its risk.
Letting low-risk automation become no review at all.
Forgetting background jobs and webhooks, which run unattended.
Leaving routing rules undocumented.
Never re-checking whether the tiers still match reality.

Checklist

List the paths that are always high risk.
Set code owners for those paths.
Label changes automatically from file paths.
Require tests for the high-risk tier.
Sample the low-risk tier instead of skipping it.
Reclassify changes that touch more than they claim.

FAQ

Is risk-based review just triage?

It is triage with a policy. Triage decides what to look at now; risk-based review decides in advance how much scrutiny a class of change receives, so the decision is consistent and visible rather than dependent on who is on duty.

Does it conflict with mandatory review rules?

No. Compliance regimes typically require review of specific change types, which lands naturally in the high-risk tier. The tiering decides depth and routing; it does not remove required approvals.

How small can a high-risk change be?

A single line can change who can read a record. That is exactly why the tier is based on the path and the behaviour rather than on size. Small high-risk changes are the ones most likely to be approved without thought.

What is the failure mode of this approach?

Misclassification. A low-risk label on a change that reaches production data means the automation approves it and nobody looks. Audit the classification periodically, and require an explicit acknowledgement when a change touches a high-risk path.