# Code review at AI pace: Matching scrutiny to risk

> AI-driven development has changed how we ship code. To keep review fast and keep quality high, match scrutiny to risk, use evidence instead of assertion, and design deployments that make mistakes cheap.

Source: https://www.bluewise.fr/code-review-at-ai-pace-matching-scrutiny-to-risk  
Author: Marc Morel  
Published: 2026-09-12  
Category: Engineering  
Series: Code review at AI pace, part 1

## When writing code stopped being the hard part

AI made code cheap to write, so review is now where speed is won or lost. The answer is not to review less, but to review wisely: match scrutiny to risk, and ask every change to prove itself.

One engineer with a coding agent can open five pull requests before lunch. [DORA's research](https://dora.dev/insights/balancing-ai-tensions/) names the tension well: higher AI adoption brings more throughput and more instability at the same time, and the hours saved writing code are often re-spent verifying it.

Rubber-stamping quietly erodes trust. Reviewing everything the old way turns review into a waiting room. There is a better path for everyone involved, built on three ideas: **scrutiny proportional to risk**, **evidence over assertion**, and **deployments that make a missed bug cheap**.

This first part covers the first idea: who reviews what, and how deeply. The other two, along with the case for not reading code at all and what regulators require, follow in Part 2 — Earning the Right to Read Less.

## Three tiers of sensitivity

Every change gets a tier before anyone reads it: machines review low risk, one person reviews medium risk in minutes, two people review high risk in depth.

|  | Tier 1 — Low risk | Tier 2 — Medium risk | Tier 3 — High risk |
| --- | --- | --- | --- |
| **Review mode** | Fully automated | Quick human review | Deep human review |
| **Typical changes** | Copy and translations, documentation, dependency patch bumps, config behind a disabled flag, test-only changes, internal tooling | New UI screens, non-critical API endpoints, refactors inside one bounded context, new feature behind a flag | Payments, authentication and authorization, personal or financial data, pricing and fees, schema migrations on shared data, cryptography, regulatory reporting |
| **Blast radius** | Cosmetic or none, instantly reversible | One feature or one team, reversible with a flag or a rollback | Money, customer data, compliance or many teams; hard or impossible to reverse |
| **Who approves** | CI gates and an AI reviewer, then auto-merge | One human reviewer from the owning team | Two humans: a domain owner and a senior or principal engineer |
| **Mandatory evidence** | Green pipeline, AI review with no blocking findings | Tier 1 evidence plus visual proof for UI changes and a short test summary | Tier 2 evidence plus design note, threat model, rollout and rollback plan, observability proof |
| **Target turnaround** | Minutes | Same half-day | Scheduled, typically 1 to 2 days |

That evidence travels as a **proof pack**: the screenshots, traces and test reports the pipeline attaches to every pull request. Part 2 shows how to build one.

**Break-glass: a fourth lane, for incidents only.** When production is on fire, the normal path is too slow, and a team without a sanctioned shortcut will invent an unsanctioned one. Break-glass makes the shortcut explicit, narrow and visible:

- **Tied to a declared incident.** The lane opens only with an incident reference, never for an urgent feature or a deadline.
- **The queue is skipped, not the pipeline.** Build, critical tests and security scans still run. What changes is the approval: one qualified approver from the on-call rota, or two people pairing live for a Tier 3 domain.
- **The smallest fix first.** Flip the flag or roll back before writing new code; a forward fix under pressure is where the next incident is born.
- **Rights that expire.** Break-glass permissions are granted for the incident and revoked when it closes, and every use is logged with who, why and which incident.
- **The review still happens.** Within one business day, the change goes through its full tier, evidence included, and any follow-up lands as a normal change.

Count break-glass uses every month. A rising number is a signal, either of quality problems upstream or of a normal path that has become too slow to trust.

## Let the pipeline decide the tier

The tier is computed from the diff; people can raise it, never quietly lower it.

Keep a **risk map as code** next to your ownership rules: path patterns for `payments/`, `auth/`, `ledger/`, migrations, and anything touching personal or card data. A CI check applies the map to each pull request and publishes the tier as a required status, so branch protection enforces the right number of approvals on its own.

[embedded content: tier routing · 2 decisions, 3 tiers, escalation only upward\]

A critical path means Tier 3; any other change in runtime behaviour means Tier 2; the rest is Tier 1. Large size, new dependencies, schema changes and irreversible data migrations push a change up a level.

Two rules keep it honest. Anyone, human or AI reviewer, can escalate, while a downgrade needs the domain owner's logged decision. And the risk map itself is a Tier 3 file, because whoever edits it decides what everyone else may skip.

## Move review to the author's side

The fastest review happens before the pull request opens: the author, helped by agents, hands over a change that is small, pre-checked and easy to read.

This is the biggest shift of 2026. Instead of pointing AI at the reviewer's queue, point it at the author's loop, where a finding costs seconds to fix. DORA recommends exactly this: deliver AI feedback to the author while writing, not to the reviewer afterwards.

- **Self-review with an agent first.** Run a local AI review before pushing, such as `/code-review` in Claude Code or Copilot in the IDE. The pull request arrives with the obvious findings already gone.
- **One intent per pull request.** When an agent produces a sprawling change, split it into a stack: the mechanical refactor first, which lands in Tier 1, then the behavioural change, now small enough for a real review. [GitHub's native stacked pull requests](https://github.blog/changelog/2026-07-30-stacked-pull-requests-are-now-in-public-preview/), in public preview since July 2026, make this painless, for people and agents alike.
- **A two-line reviewer's guide.** *Start with the ledger service; the other twelve files are a rename.* One sentence like that can halve review time.
- **The risk question, answered up front.** Every description says what could go wrong, and how we would know.

## Tiers 1 and 2: light touch, real care

Low-risk changes merge on green automation; medium-risk changes get one reviewer for about fifteen minutes, evidence first.

**Tier 1** layers machines. Deterministic gates run first: build, tests, static analysis, secret scanning, dependency policy. Then an AI reviewer reads the diff with repository context. Today's multi-agent reviewers, such as [Claude Code Review](https://code.claude.com/docs/en/code-review), GitHub Copilot code review, CodeRabbit, Greptile or Qodo, verify their own findings before posting, which keeps the noise down. Brief yours with your written conventions, and ask it to challenge the tier as well as the code. Everything auto-merged appears in a daily digest, and one change in twenty is read after the fact: that sample tells you whether your boundaries are in the right place.

**Tier 2** follows the same short path every time:

1. **Intent.** Is this the right change for the problem? A cache in front of a slow endpoint may be hiding an endpoint that runs forty queries per request.
2. **Evidence.** Do the screenshots and trace match the intent? Do the tests assert behaviour a user would notice, or merely mirror the code?
3. **Edges.** Empty states, error paths, retries, a user who double-clicks. AI-written code is often excellent on the happy path and quietly naive everywhere else.
4. **Decide.** Approve, request changes or escalate. Silence is not an option.

Comments carry their weight, *blocking*, *suggestion* or *nit*, and are phrased as questions where possible: *what happens if this webhook arrives twice?* teaches more than a verdict. A comment written twice becomes a lint rule or a line in the AI reviewer's instructions, never a third comment.

## Tier 3: deep where it matters

Critical changes get two prepared reviewers, a design conversation before any code, and a rehearsed rollback.

This is where the time saved elsewhere is reinvested. In payments, authentication, personal data or pricing, one defect costs money, trust or a regulator's attention.

- **Design before diff.** A one-page note settles data flow, idempotency and what happens to money in flight when a dependency times out. For an agent, that note doubles as its specification.
- **Two lenses.** The domain owner checks business rules: rounding, currencies, refund and chargeback states, audit trail. A senior or principal engineer checks the system: consistency, retries, blast radius, partial failure.
- **Patience for one-way doors.** A public contract, a data model or an irreversible migration deserves the slow path; a flagged, reversible change does not.
- **A small threat model.** Who could abuse this path, and which control stops them? For authorisation changes, the proof pack shows the forbidden requests being refused.
- **Proof at production fidelity.** Logs, metrics and audit events from a staging run on realistic data. In regulated contexts, sign the proof pack as a build attestation, so the evidence itself joins the audit trail.
- **A rollout the reviewers sign off.** Internal accounts first, then one per cent of traffic, with an automatic halt if authorisation rates drift below baseline.

For the largest changes, thirty minutes of live walkthrough often replaces three days of comment threads.

## What's next

Part 2 of this series, **Earning the right to read less**, explores how to make lighter review safe through evidence-based proof packs, deployments that contain mistakes, and continuous learning through incident analysis. We'll also cover what DORA and PCI-DSS require, how to align with existing standards, and how to build a system that keeps pace with AI-driven development while maintaining safety and compliance.