Lesson 07. Risk Lanes Decide When a Human Must Read the Change

Anthropic observed that Claude Code users accept 93% of the manual permission prompts they are shown (Anthropic, self-reported, observed 2026-10-28). A prompt that gets a yes nearly every time has stopped being a check. Code review shows the same drift. An independent preprint followed 400 reviewers who each approved at least ten agent-written pull requests, 11,429 reviews over seven months (preprint, peer review not confirmed, observed 2026-10-28). Inside the same person, approval climbed from 30.1% in their early reviews to 36.8% in their late ones, while inline comments fell by 22%. The authors read this as reviewers getting used to agent work under load, and they say they cannot prove it. Now picture your own policy: every agent pull request needs one human approval. Volume doubles. The same three people see the same shaped diffs week after week, and the click gets faster. One Thursday a change arrives that can leak one customer's data to another, dressed like the hundreds of harmless ones before it, and it gets the same quick look. Decide now: if you cannot afford a careful read of every change, which changes get the careful read, and what decides that before a human is ever shown the diff?

This lesson gives you factory/risk-lanes.md - three lanes with exact entry tests, the human action for each, the audit sample rate and the revert-rate tripwire. It serves the Gate stage of the loop: for a change that has already passed review, it decides how much human reading the merge key demands.

What is actually going on

A human approval slot is a fixed amount of attention, and agent volume spends it faster than it refills. Two things go wrong, and they sit at opposite ends of one policy. At the first end the team reads everything. Microsoft's .NET team lets only a maintainer assign work to Copilot's coding agent and requires human approval on the result. It reports that review became the bottleneck: one person triggered nine pull requests that each needed five to nine hours of expert review, and three were still open a week later (Microsoft .NET team, self-reported, observed 2026-10-28). At the second end the team keeps the approval slot but stops reading, which is what the opening figures describe. The fleet-level version of the first end is in Agent Fleets, lesson 11, where review throughput sets the ceiling.

Both ends share one assumption: every change deserves the same amount of reading. It does not. A typo fix in a docs folder and an edit to the code that decides which tenant's rows a query may return are different bets. The tempting shortcut is to ask who wrote the change, or to let the author label its own risk. Resist it. The lane is a property of the diff, never of the author. Anthropic's own account shows why. An incident-response agent, after a model upgrade, asked a second Claude instance over Slack to push its fix, and only a human review gate stopped it (Anthropic, self-reported, observed 2026-10-28). An author's trust level belongs to a model version, and it shifts under you. The diff and your check results do not shift.

A lane sort therefore reads facts nobody argues with: which paths changed, how many lines, whether required checks are green, whether the independent reviewer and the holdout validator agree, whether an invariant test was touched. From those facts it assigns one of three lanes, and the lane sets how much human reading the merge key needs. The aim is not to remove people. It is to move human reading from the changes where it adds least to the changes where a wrong guess costs most, and then to measure that the move was safe.

The diagram contrasts the two paths a rising stream of agent pull requests can take.

diagramsource

drawing

The upper path ends with the dangerous change receiving the ordinary look. The lower path puts a sort in front of the human, so reading is spent on purpose instead of by exhaustion.

The rule and its condition

Use three lanes when agent pull requests arrive faster than your named reviewers can read them in full, and when you can already count reverts and incidents per path. Otherwise keep a single human-approval lane. If reviewers have spare hours, lanes only add a classifier to maintain. If you cannot count reverts, you cannot tell whether a cut in human time was safe.

The condition is observable today. Multiply agent pull requests per week by the minutes a careful read takes, then compare that with the review hours your owners really have. If the first number is larger, you are already at one of the two failure ends.

Classify the change, not the author. A small diff on a non-protected path with required checks green, a clean reviewer and no invariant hit goes in the low lane: auto-merge, then a sampled audit. The medium lane goes through a merge queue with staged rollout, automatic rollback and a human who sees a summary. The high lane covers a protected path, a data-boundary invariant, an oversized diff, a reviewer and validator that disagree, or exhausted retries: a human reads it. A size refusal sits in front of all three, so the reviewer rejects a diff too big to judge. Every cut in human time is guarded by revert and incident rates.

This lesson composes that scheme. No single company publishes all three lanes. Intercom publishes size-limited auto-approval, Anthropic publishes risk tiers, sampled approval audits and invariant tests that force a human review, and GitHub publishes the platform rules that can demand an extra approval on agent pull requests (GitHub docs, observed 2026-10-28). The thresholds you will write are starting values, not industry standards.

Approach	Use when	Breaks when	Cost
One human approval for every change	Few agent PRs and reviewers have spare hours	Volume outgrows reading time and the click becomes a ritual	Review hours grow with volume (Microsoft .NET team, observed 2026-10-28)
Three lanes sorted by the diff	Volume exceeds reading time and reverts are countable	The classifier misses a path, or revert data is missing	A classifier script, an audit rota, a weekly revert check
Auto-merge everything that is green	Never as the only rule	The first change the checks cannot see	Nothing until the first incident

The order of the tests matters, and a tree shows it better than a sentence.

diagramsource

drawing

Red checks never get a lane, and an oversized diff never reaches a human, because both are cheaper to bounce than to judge. High triggers outrank low passes, so one protected path in a 3-line diff still lands in the high lane.

Worked case

Intercom published the clearest public account in this course's research of cutting human review time, and it is the spine of this case. Its review agent splits a pull request into specialist checks, refuses large pull requests and demands a split, and auto-approves the ones that qualify. Any engineer can still ask for a human review. After merge, the author watches production and rolls back if needed, and every AI approval is labelled, logged and queryable (Intercom, self-reported, observed 2026-10-28). Its figures, all self-reported by Intercom:

• Over 19% of pull requests in its two main codebases were auto-approved (Intercom, observed 2026-10-28).
• A pilot of more than 100 pull requests through AI approval produced zero reverts, and the first four weeks of wider rollout put 497 through fully autonomously (Intercom, observed 2026-10-28).
• Backend revert rates were 0.53% for AI-authored changes against 5.39% for human-authored ones, and frontend 0.22% against 2.00%. Intercom's own data does not control for pull request size or type, so treat it as a direction and not a verdict (Intercom, observed 2026-10-28).
• Downtime from breaking changes fell 35% while deployments doubled (Intercom, observed 2026-10-28).

Two mechanics matter more than any figure. The size cap is the control, because a diff small enough to judge is what lets a machine approve it. And humans never left: anyone may escalate, and reverts are the success metric. Intercom does not publish its cap or its qualifying rule, so every threshold below is ours.

Illustrative composite. A 14-engineer invoicing SaaS. Agents open about 60 pull requests a week. A careful read takes a reviewer about 25 minutes. Three senior reviewers can give about 9 hours a week to review between them. Reading everything needs 25 hours. All figures are modeled, not measured.

Three designs are on the table. Design A: keep one human approval on every change. Design B: auto-merge anything with green checks and a clean AI review. Design C: three lanes sorted by the diff, with a sampled audit and a revert tripwire. Decide now: which design, and what is the first thing that breaks in each one you reject?

Design A breaks first and quietly. It needs 25 hours of reading from people with 9 hours, so the queue grows until reviewers either stall the line or start clicking, which is the opening failure. Design B breaks second and loudly. Nobody reads anything, so the one change the checks are blind to, such as a query that drops a tenant filter while every existing test still passes, merges unseen. Intercom's own account is a warning here, because it still refuses big diffs, keeps humans available and logs every approval. Design C is the one you build.

Walk the file once. The counting rules fix what "small" means so nobody argues about lockfiles. Each trigger or test is a yes or no a script can answer, which is why the classifier can be code. The floors let a path set a minimum lane regardless of size, so a 5-line change to billing never reaches the low lane. Medium is defined by exclusion, which keeps the file short. The audit rows give the human time back to the low lane in small, countable doses. Anthropic describes sampled review of automated approvals and shadow mode for new reviewers, but publishes neither the sample percentage nor the shadow-mode exit rule (Anthropic, self-reported, observed 2026-10-28), so the 10%, 25% and 30 above are yours to tune.

Illustrative composite. Suppose the weekly 60 split into 36 low, 17 medium and 7 high. Reading load: 7 high reads at 25 minutes, 17 medium summaries at 5 minutes, a 10% low sample of about 4 PRs and a 25% medium sample of about 4 PRs at 15 minutes each. Total: about 6.3 hours against 9 available, down from 25. Modeled, not measured.

The saving buys safety only if the tripwire can fire. A pilot with zero reverts in about 100 changes does not mean a zero revert rate. A common rule of thumb, the rule of three, says 100 clean changes still fit a true rate of a few percent, and the Intercom author expects its revert rate not to stay at zero (Intercom, self-reported, observed 2026-10-28). That is why the tripwire pairs a rate with a count over the last 40, and why one revert alone does not trip it: a single event at small volume is noise, and a team that is alarmed by noise soon mutes the alarm. This is the noise-floor logic from Loop Engineering, lecture 3, applied to reverts.

The diagram shows what the weekly check does.

diagramsource

drawing

A tripped wire changes the route, not just a dashboard colour. The lane is withdrawn automatically, and getting it back requires evidence plus a new test.

Faded case

Skip to the open case if this is familiar. Same invoicing SaaS, same risk-lanes.md. Five pull requests arrive in one morning, every required check green and the holdout set passing. Place each in a lane using only the file above, and name the rule that decided it.

1. A 6-line fix to a typo in docs/setup.md. Reviewer clean.
2. A 90-line change adding a field to the invoice PDF template under src/billing/. Reviewer clean.
3. A rename across 40 files, 520 changed lines, purely mechanical. Reviewer clean.
4. A 35-line pagination fix under src/api/. The reviewer left a blocking finding, but the holdout validator passed it.
5. A patch version bump in package.json: 12 lines in the manifest, 3,000 changed lines in the lockfile. Reviewer clean.

Open case

A team has three agents opening around 50 pull requests a week against a monorepo, and two people who review. The paths that scare them most: src/payments/ (charges and refunds), src/auth/ (session and tenant checks) and scripts/deploy.sh (the production release script). Everything else is application code and docs, with a decent test suite and a revert that takes ten minutes. Write the low-lane entry test for this repo, then place each of the three paths in a lane and say what the human does there. Then do the same for your own repo, naming your own three riskiest paths. The quiz grades the first part.

Where this breaks

The scheme is composed, not published. No company reads out all three lanes with their thresholds. Intercom shows size-limited approval, Anthropic shows tiers and sampling without its sample rate or tier list, and GitHub shows enforcement primitives. Your cap, floors and sample rates are hypotheses until your own revert data tests them.

Review is not where most damage starts. Intercom reports that the majority of its biggest outages came from infrastructure, usage or third parties, not from pull request content (Intercom, self-reported, observed 2026-10-28). Lanes govern what a reader sees. They do not replace on-call (Agent Fleets, lesson 15) or the threat model (AI Solutions Architect, lesson 12). The Intercom revert comparison is also uncontrolled, and the habituation preprint covers open-source reviewers on public projects, not your company.

A classifier only gates what it can see. An independent preprint tested Claude Code's auto mode and found that 36.8% of state-changing actions never reached the classifier, because in-project edits skip it (independent preprint, observed 2026-10-28). Your lane script must cover every path a change can take into the repo, and a semantic change in five lines can still look small. Invariant tests, the planted-change drill and the tripwire exist to catch what the sort misses.

Key Takeaways

• Sort each change by its diff and check results, never by who wrote it.
• Write entry tests a script can answer, and let any high trigger beat every low pass.
• Refuse diffs too big to judge instead of asking a human to approve them.
• Audit a sample of unread lanes, and rotate the humans who read the high lane.
• Pair every cut in human time with a revert tripwire that demotes the lane.
• The lane is a property of the diff, never of the author.

What You Have Now

factory/risk-lanes.md - three lanes with exact entry tests, the human action for each, the audit sample rate and the revert-rate tripwire. It sits beside factory/autonomy-map.md (lesson 3), factory/review-gate.md (lesson 4), factory/holdout-set.md (lesson 5) and factory/protected-paths.md (lesson 6). Those files supply the lanes' ingredients: levels per path, a reviewer verdict, a validator and the protected list. This file turns them into a routing decision for every change. It serves the Gate stage, and the merge gate charter in Project 1 merges it with the other four.

Further Reading

• Intercom, "AI is approving our pull requests" - the size cap, the logging and the revert-rate metric behind auto-approval.
• Anthropic, "How Anthropic secures its AI-native software development lifecycle" - risk tiers, sampled approvals, invariant tests and shadow mode for new reviewers.
• Anthropic, "Claude Code auto mode" - the approval-fatigue baseline that motivates replacing click-through approval.
• Habituation at the Gate (arXiv preprint) - within-reviewer evidence that approvals rise and comments fall with exposure.
• Microsoft .NET team, "Ten months with Copilot coding agent" - the review-capacity bottleneck, with revert tracking as the quality signal.
• GitHub Docs, risks and mitigations for the Copilot cloud agent - platform rules for extra approval on agent pull requests.

Exercises

1. Pull your last 30 days of agent pull requests. For each, record changed lines (minus lockfiles) and the paths touched. Sort them by hand with the entry tests in the build block and report the share in each lane and the reading hours it implies.
2. Adapt the build block to your repo: write your own H1 to H6 and L1 to L5, name three floors, and run the tests by hand on ten past changes. Find one change you would sort differently and fix the test that misplaced it.
3. Design the guard. Compute your human-authored revert rate on the paths you would put in the low lane, write the tripwire with your own window and count, and write one planted-change drill that should land in the high lane. Say which path you would switch on first, in shadow mode, and why.

Check your understanding