Episode 5 of the AI-Augmented Parallel SDLC series.
The pillar article laid out the blueprint: discover once, run three workstreams in parallel, converge at one gate. Episode 4 covered how to label what fails at that gate. This one is about the review queue feeding it, and what happens to that queue when agents write most of the code.
A town gets a building crew with new nail guns. Houses that took a month to frame now go up in a week. The town’s one inspector still works the same hours, with the same clipboard.
For a while she keeps up by moving faster: a glance at the wiring, a nod at the beams, a signature. Then a porch gives way at a house she signed off in eleven minutes. After that she checks everything, nail by nail, and the street fills with finished houses nobody can move into.
She isn’t bad at her job. She is spending a fixed amount of attention as if every house still took a month to build.
I’ve watched software teams go through both of those phases in a single quarter.
Two lines on a Thursday
In a Parallel Delivery model, AI agents draft the code and a named engineer reviews, signs off and owns every merge. That rule held up well, right until the agents got good.
On one recent project, a few weeks after every developer started pairing with a coding agent, pull requests went from roughly eight a day to just over thirty. Our lead reviewer kept up. Average review time per PR fell from about twenty minutes to under five, and for a fortnight the dashboard looked like a success story.
Then an agent, fixing a display bug, tidied up a shared currency helper on its way past. Two lines changed. Rounding moved from half-up to half-even. The diff was clean and the tests passed, because no test had ever pinned the rounding mode. It went through in a batch of eleven approvals just before lunch.
APPROVED · Tidy currency helper · PR #0731 · +2 −1 · reviewed in 3 min
Three weeks later a client’s finance team asked why invoice totals were drifting by small amounts. That same week, the same reviewer had spent forty minutes going back and forth on button spacing in a settings screen.
We hadn’t run out of review. We had spent it in the wrong place.
Why review became the bottleneck
For most of software’s history, writing code was the slow part. Review rode along at roughly the pace of production: someone wrote for a day, a colleague read for half an hour.
Coding agents broke that ratio. Production is now close to free. Review still runs at human speed, and a senior engineer’s sharp hours don’t grow because the repository does. The gap has to go somewhere, and it goes one of two ways.
- The rubber stamp. Reviewers keep the queue moving by reading less. Approval times fall, the dashboard looks great, and the risk moves into production where nobody is counting it. This is the Quality Slip from Episode 4.
- Gridlock. Reviewers hold the line and read everything properly. Quality holds, but PRs wait for days, the parallel streams stall, and developers sit on finished work.
Production climbs the week agents arrive; review capacity doesn’t. The gap between the lines has to be paid for somewhere.
AI didn’t remove the bottleneck. It moved it to the one thing you can’t buy more of: a senior engineer’s attention.
Both failures come from the same mistake: treating every pull request as if it deserves the same attention. It doesn’t. Most of what an agent writes is low-risk and easy to prove. A small part of it can quietly cost real money. The job is to tell them apart before anyone starts reading.
Two questions, three depths
Treat reviewer attention like a budget. Every reviewer has a fixed amount of genuinely sharp review in a day, in our experience about three hours, and every PR draws on it. The only real decision is where it goes.
Good building inspectors already work this way. They walk the foundation, the wiring and the load-bearing walls in person. They don’t inspect the paint. So before anyone opens a diff, we route it by asking two questions, in order.
Question 1 — Does it touch a red zone?
Red zones are the parts of the system where a quiet mistake is expensive: money, access and permissions, stored data and migrations, and shared core code that many features call. If a PR touches one, it’s a Deep Read, whoever or whatever wrote it. Small diffs get no exemption.
Question 2 — Can a machine prove it’s right?
Outside the red zones, ask whether tests, types and snapshot checks fully cover what changed. If they do, it’s a Fast Pass: the owner confirms the change does what it says and the gates are green. If they don’t, it’s a Spot Check: a reviewer reads the intent and the tests, and samples the diff.
The routing check. Two questions, asked in order, send every PR to exactly one review depth before anyone reads a line.
| Deep Read (red zone) | Spot Check (standard) | Fast Pass (machine-proven) | |
|---|---|---|---|
| Qualifies when | It touches money, access, stored data or shared core code. | It sits outside red zones but isn’t fully covered by checks. | It sits outside red zones and tests, types and snapshots cover it. |
| Who reviews | A senior engineer, with the author walking through it. | Any engineer on the team. Juniors pair here. | The owner of the change. |
| What they check | Every line, every caller, every failure path. | Intent, tests, and a sample of the diff. | That it does what it says and the gates are green. |
| Typical time | 30–60 minutes | 10–15 minutes | 2–3 minutes |
| A spike means | Red zones are drawn too wide, or the design is too coupled. | Test coverage is lagging behind the code. | Healthy, as long as escapes stay near zero. |
What each depth means, who spends the attention, and what a rising count is telling you.
Notice what doesn’t change between the tiers. Every merge still carries a name. The budget only decides how deep that name has to look.
Blast radius, not diff size
The first instinct is to route by size: big diffs get senior eyes, small ones get waved through. In an AI-assisted codebase that is exactly backwards. Agents produce large, uniform, well-tested changes all day, and the dangerous edits are often tiny.
Two agent-written PRs from the same afternoon. The big one is safe and proven; the tiny one sits under every invoice. Route by where a change lands, not how long it is.
So we draw a red-zone map at kickoff, in the same group discovery session from Episode 2, and commit it to the repository as a list of paths. Routing then reads the map, not the reviewer’s mood. Three ground rules keep it honest.
- Paths, not opinions. Whether a PR touches a red zone is a lookup, not a debate. If someone thinks a path is missing, they change the map in its own PR, not the tier of the one in front of them.
- Authorship doesn’t matter. A red-zone change from your most senior engineer gets the same Deep Read as one from an agent. The rule protects the system, not anyone’s reputation.
- The one-minute rule. If a reviewer can’t place a PR in a tier within a minute, it goes up one tier by default. A change that’s hard to classify is already telling you it deserves more attention.
Let AI sort, never sign
AI makes routing almost instant, as long as you hold to the rule that runs through this whole series: AI does the legwork; people make the call.
- A brief before the read. An assistant checks the diff against the red-zone map and hands the reviewer a one-screen brief: what changed in behaviour rather than structure, which callers are affected, which changed lines have no test, and where to look first.
- Evidence from the author. The authoring agent attaches proof to the PR: the tests it ran, before-and-after output, screenshots for UI changes. Reviewers judge evidence, not a confident description.
- Never the last word. An AI reviewer checking AI-written code shares many of its blind spots. Its job is to narrow where a person looks. It never approves a merge.
The assistant prepares the brief and suggests a tier. A named reviewer confirms it and reads the lines that matter. The machine never merges.
The assistant does: summarise the change, flag red-zone paths, list untested lines, and suggest a tier.
People do: confirm the tier, read the risky lines, decide whether it ships, and own the result.
Schedule attention like a meeting
A budget only works if you protect it. Sharp review is a morning resource for most people, and it doesn’t survive being chopped up between stand-ups and chat notifications.
- Deep reads go first. Two per reviewer per day, in a protected block before the meetings start. A third one waits for tomorrow or goes to another senior.
- Fast passes get batched. Fifteen of them in one twenty-minute sitting cost far less attention than fifteen interruptions spread across the day.
- Spot checks grow reviewers. They are the right place for juniors to review alongside a senior, which is how next year’s red-zone reviewers get made.
One reviewer’s day. Roughly three sharp hours, spent on purpose: deep reads in the morning block, spot checks after lunch, fast passes in a single batch.
When the budget runs out, the queue should get longer, not the reviews shorter.
That line is the whole discipline. A longer queue is visible: everyone can see it, and someone can add a reviewer. A shorter review is invisible until a client’s finance team finds it for you.
Reading review health at a glance
Track two numbers together: how long PRs wait for review, and how many defects escape to production. As with True Bugs and Scope Shifts in Episode 4, either number on its own will mislead you.
The four combinations each tell a different story. The Rubber Stamp is the one leaders most often celebrate: short queues, fast approvals, a quiet tracker. It usually means the escapes haven’t been found yet. Gridlock looks responsible, and it quietly kills the parallel model by making every developer wait on the same senior.
One more number is worth a glance: the share of review time spent on Fast Passes. If it creeps past a fifth, people don’t trust the automated gates, and the fix is better tests, not more reviewers.
And if anything escapes from a red zone, don’t start with the reviewer. Start with the map: either the zone was missing, or it was drawn too wide to read properly.
Reading queue time and escaped defects together. The healthy team sits bottom-left; a fast, quiet tracker can be the Rubber Stamp in disguise.
Spend judgement where it counts
Coding agents changed the economics of software in one direction: making things is cheap now. They didn’t change the other side. Deciding whether something is right is still slow, human and scarce, and it’s the part that carries your name.
Before your next sprint, write down your red zones, set three review depths, and route every PR by the map instead of by arrival order or diff size. Then protect the morning block like you’d protect a client meeting.
Code is cheap now. Judgement isn’t. Spend it like it costs something.
In this series
The AI-Augmented Parallel SDLC — the full blueprint: discovery once, three parallel workstreams, one gate.
Episode 1: The Handoff Chain — Why Your Team Is Mostly Paying Handoff Debt
Episode 2: The Joint Discovery Session — Why Five Perspectives Beat One Requirements Document
Episode 4: Stop Calling Everything a “Bug”
Next up — Episode 6: Who Remembers the Project? When agents hold the decisions, rules and history, someone still has to keep that memory honest. Here’s how to stop a project’s context from quietly drifting.
Try this, five minutes: pull up the last twenty PRs you approved. How long did you spend on the one that could have cost the most money?
Top comments (0)