Review Depth Follows Blast Radius

Spend review attention where a mistake travels furthest: deep read infrastructure, careful read of shared code, proof read of isolated leaf code. Then earn the right to read less with feature gates and proof in every PR.

This builds on John Kim’s video How I Review AI Code; the three tiers are my refinement of his trunk-and-leaf picture.

The problem

Agents mean far more code: more features, more tests, several agents running in parallel for one person. Nobody can review even their own output line by line any more. Two camps have formed: “if you’re still reading code, you’re too slow” and “agents still make basic mistakes, so read everything”. The useful answer is it depends: review is a gradient, and what the change can break sets where you are on it.

The codebase is a tree

• Trunk: entry points, infrastructure (networking, rendering, build), shared state that everything reads. If it breaks, the whole app breaks.
• Leaves: code written in isolation or fully behind a feature gate: a new component, a new endpoint that isn’t wired in yet.

Knowing your codebase is what makes this fast: you spot straight away when a diff touches a dangerous zone.

Three review depths

Tier	What lives here	Review depth	What I check
Infrastructure (trunk)	CI/CD, infrastructure as code, auth, permissions, secrets, migrations, dependency changes	Deep read: every line, run it if possible, a second reviewer	Least privilege, anything irreversible (data, state), rollback path, new dependencies
Shared code (trunk)	Libraries, shared state, shared components, API contracts, schemas	Careful read: understand the change and its callers	Ungated behaviour changes to existing paths, backwards compatibility, downstream side effects
Isolated leaf code	A gated screen, a single handler, a script with no dependants	Proof read: skim for anything obviously off, trust the proof	Does it match the ticket; does it reach into shared areas

The tier comes from the codebase, not the PR title. Label each PR by the highest tier it touches (CODEOWNERS or path rules do this automatically). A leaf PR that edits one shared file is a shared-code PR.

Four questions that set the depth

1. What’s the existing behaviour that must not change?
2. If this goes wrong, how bad could it be?
3. Can I roll it back? Is it behind a gate?
4. Is it a one-way door? The harder it is to reverse, the longer I read.

Make it safe to read less

• Gate from the plan, not afterwards. Separate the new isolated code from where it plugs into the existing code, and put those integration points behind feature flags (a boolean is enough to start). Gated code is effectively leaf code until it’s switched on.
• Proof in every PR, so the reviewer checks evidence instead of re-deriving the logic:
  • Tests. Skim the test names and assertions, and give the agent a rule against tests that assert nothing.
  • Runtime evidence: logs from the change actually running.
  • Visual evidence: a screenshot or short recording for anything visual.
  • A confidence level from the agent on each part of the change.
• Agents check their own work while building, so the obvious mistakes are fixed before a human looks.
• A PR template, so every PR has the same important parts. The summary should never be longer than the diff.

Let machines take the nits

Style comments and “how I’d have written it” aren’t worth human review time any more. Linting, type checks and an AI reviewer handle them, and with refactoring this cheap, arguing about taste in review doesn’t pay.

For the AI reviewer, use a fresh, adversarial agent: one without the context of the session that wrote the code. An agent reviewing its own conversation anchors on it and marks its own homework. A scheduled agent can also babysit the PR, picking up review comments, fixing them, rerunning validation and pushing again, so you don’t have to.

Merge-ready isn’t launch-ready

Landing everything behind gates is the broad strokes: about 80 % of the work. The last 20 % takes about as long again, and it’s where human judgement and taste go. Audit the whole feature (agents help) for performance, bugs, security and how well it matches the spec, then refactor and polish.

Then launch behind the gate with an experiment or a canary. Even without enough users for a meaningful A/B test, ramping traffic up gradually surfaces crashes and alerts while the blast radius is still small (Blue-Green Deployment).

What I’d prioritise in an AI-assisted team

• Map the trunk once and make it visible: CODEOWNERS, path labels, and a short “dangerous zones” list in the repo docs or the agent instructions.
• Keep each PR within one tier (Slicing Pull Requests), so a big leaf change can’t hide a small trunk change.
• Look for the AI-specific smells in trunk code: new or invented dependencies (AI-Era Supply Chain: What to Trust When Anything Can Be Generated), tests that mirror the implementation, duplicated helpers instead of reusing what exists, quietly widened permissions, and changes outside the ticket.
• Shrink the trunk by design. Bounded contexts and contracts turn more of the codebase into leaves (A Safe Path for AI Agents in a Large Codebase, Planes and Bounded Contexts), and fitness functions keep it that way (Architecture Fitness Functions).
• The author is accountable for what they merge, whoever typed it.

This sits between two poles. One is “read everything”. The other is the case for verifying rather than reading at all (Don’t Read the Code? Verifying AI-Written Code). Blast radius tells you where on that line each change belongs.

Open questions

• Should infrastructure-tier changes ever be written by an agent, or only with an agent’s help?
• How do you tell whether review attention is landing in the right place? Escaped defects and review time, per tier, is my first guess.
• As models improve, what evidence should justify reading a tier less deeply?