# How to Review AI-Generated Code: By Risk, Not by Diff Size
The policy is the bottleneck, not the people. Two readers on a money tool, one on a reversible write, none on a read-only change, and a count of what escapes.
6 min read · Intermediate · Lesson 5 of 13 in Running delivery · Updated 2026-10-03 · By Akash Das
Canonical: https://akash-coded.github.io/aws-bedrock-agentcore-strands/learn/review-ai-generated-code/
> **In short.** Review AI-generated code by the **risk band of the most dangerous thing a change touches**. That is
> two named readers on money, identity or policy, one reader on a reversible or hard-to-reverse write,
> and the harness alone on read-only changes. Enforce the band with a path rule nobody sets for their
> own work, and report three numbers monthly so the policy survives: slots needed, days in the queue,
> and escapes from the no-reader lane.
**In this lesson** you'll learn:
- how to measure a review queue, and why capacity is not the lever;
- how to band every change by what it touches, and enforce the band with a path rule;
- how to open a no-reader lane safely, and the three numbers that keep the policy alive.
## Sound familiar?
- Nine pull requests, a four-day queue, and two senior reviewers who cannot read any faster.
- A one-line change to a payment limit got one quick approval because it was small.
- The review that happens is a scroll to the bottom and an approve.
The policy treats every change as equally dangerous. Agents produce changes faster than people can
read them, so a policy that ignores risk will always produce a queue.
## Why review by risk?
When agents write most of the code, **reading becomes the scarce resource**. Hiring a reviewer takes
months; the agents will produce more changes long before then. So the only lever you control is how
much reading each change needs, and the size of a diff is the wrong way to decide it. A one-line
change to a refund cap is the most dangerous change of the week; a large refactor of a read-only
report may be the safest.
## Change the policy, step by step
### Step 1 · Measure the queue
**Queue time = review slots needed ÷ review slots available per day.** Count slots, not pull requests:
a change needing two readers takes two. Measure slots available from reviews actually completed over
the last four weeks, not from a job description. At SkyWays, nine changes on a two-senior-reviewer
policy needed 18 slots against 4.5 a day: **a four-day queue**.
### Step 2 · Band every change by what it touches
Give every tool and path a band from the authority budget (R1 read-only, R2 reversible write, R3
hard-to-reverse write, R4 money, R5 irreversible) and let a change inherit the band of the most
dangerous thing it touches. No band is ever decided by the size of a diff.
### Step 3 · Put the band in a path rule nobody sets for their own work
Generate a rule file in the repository (a `CODEOWNERS` file, for example) from the authority budget,
so the band of a change is decided by the paths it touches, not by the author. Self-assessed risk is
not a control.
### Step 4 · Route the readers by band
| Band | Readers | What the reader is for |
| --- | --- | --- |
| **R4 · R5** | Two, named | The authority: does this change what the tool may do, or the limit it may do it to? |
| **R2 · R3** | One | Correctness and blast radius, after the harness has already run |
| **R1** | None | The harness alone |
At SkyWays routing cut the slots needed from 18 to **7** and the queue from four days to **1.6**, with
the same people reading at the same speed.
### Step 5 · Open the no-reader lane, and count the escapes
A lane with no reader is exactly as safe as its harness, so **count the escapes** (defects that reach
production through it) every week. Zero escapes over *n* merges bounds the escape rate at about
**3 ÷ n** (the rule of three): 3% after 100 merges, 1.5% after 200. Write the lane's charter before
opening it, including the condition that closes it, and close it on the first escape.
### Step 6 · Report three numbers, monthly, together
Report **review slots needed**, **days in the queue** and **escapes from the no-reader lane**, and
report the escape count even when it is zero. Any one alone can be argued with; together they answer
whether you went faster without going blind.
## Where you'll use it
- **As an engineering lead**, the week the queue passes two days.
- **As a programme manager**, reading the review queue off the board every week.
- **In a security or audit review**, where the path rule shows that money changes can never skip two readers.
## Why it matters
Adding reviewers is slow and does not scale with agents. Changing the policy takes an afternoon and
cuts most of the queue, while *raising* the scrutiny on the changes that can actually do harm.
## Try it
This week's changes: three touch only report queries; four change reversible write tools; two change
the refund tool. The current policy is two reviewers on everything, and the team clears 4 slots a day.
**What is the queue now, and after routing by band?**
Show the answer
**Now: 18 slots ÷ 4 = 4.5 days.** Nine changes × two readers. **After routing: 8 slots ÷ 4 = 2 days.**
The three read-only changes need none, the four reversible writes need one each, and the two refund
changes keep two each: 0 + 4 + 4 = 8. The refund changes lose nothing; the queue halves.