Human review only for Red (architectural)

At L5 (Autonomous), the vast majority of code changes - feature implementations, bug fixes, refactors, dependency updates, test additions - flow through the Green/auto-merge pipeline without any human review. Human engineers only review changes that the automated evaluation system has classified as Red: architectural changes, security-sensitive modifications, changes to core business logic, or anything the system has low confidence in evaluating correctly.

This is the endpoint of the review maturity journey. At L1, humans reviewed 100% of code. At L2, AI suggestions made each review faster. At L3, AI agents handled the first pass. At L4, 60%+ of PRs auto-merged without human involvement. At L5, human review is no longer a default step - it's an exception triggered by specific criteria.

The Red classification criteria at L5 are precise and narrow. Red isn't "I'm not sure" or "this looks complex" - it's a specific list of conditions: changes to authentication and authorization primitives, modifications to cryptographic implementations, changes to billing and financial transaction logic, architectural boundary modifications that could affect multiple downstream services, removals of existing public API contracts, and changes where the AI review agent's confidence score falls below a defined threshold.

Everything else - the tens or hundreds of agent-generated PRs per day that implement features, fix bugs, add tests, update documentation - flows through Green auto-merge. Humans set direction (through tickets, acceptance tests, strategic decisions) and review exceptions (Red PRs). The routine execution is autonomous.

The "human review only for Red" model is the natural conclusion of the efficiency progression, but it also represents a genuine philosophical shift in the role of human engineers:

• Human attention is deployed where it creates unique value - Architectural judgment, security intuition, business logic correctness, product sense - these are things humans contribute that automated systems can't yet replicate reliably. Reserving human review for decisions that require these capabilities is the right use of scarce human attention.
• Review becomes a strategic activity - When humans review 100% of code, review is an operational task. When humans review only Red PRs, review is a strategic activity: the decisions being reviewed are consequential, the reviewers are thinking carefully, and the output of review is meaningful judgment.
• Developer satisfaction improves - Engineers who spend their days reviewing straightforward implementation PRs are not using their skills well. Engineers who review architectural decisions, security changes, and complex business logic are doing work that matches their expertise. The routing of complex decisions to humans isn't just efficient - it's more satisfying.
• Scale becomes possible - A team with 5 human engineers and 100 agents can produce code at 100x the rate of the humans alone, provided the automated quality gate is trustworthy. Human review is the bottleneck that doesn't scale linearly. Reserving human review for Red PRs is what makes the agent fleet model economically viable.
• Accountability is preserved where it matters - For the decisions that are genuinely consequential (architecture, security, business logic), human engineers are still on record as having reviewed and approved. The automation hasn't removed accountability - it's concentrated it on the decisions that warrant it.

The model requires a well-calibrated Red classification. If too many changes are classified Red, human engineers are reviewing more than necessary and the efficiency gain is lost. If too few changes are classified Red, consequential decisions are auto-merging without human oversight. Calibration is ongoing work, not a one-time configuration.

Arriving at the "human review only for Red" state is the result of succeeding at L2-L4, not a direct jump:

1. Define the Red criteria explicitly - What are the specific conditions that require human review at your organization? Write them down. "Architectural changes" is not specific enough - "modifications to service boundaries, addition of new external API dependencies, or changes to shared data schemas" is specific enough. The criteria must be precise enough for an automated system to evaluate them.
2. Implement Red classification in your evaluation pipeline - The Green/Yellow/Red evaluation system from L4 is the mechanism. The L5 evolution is tightening the Red criteria to only the cases where human judgment is genuinely non-substitutable, while routing everything else to Green or Yellow with automated review.
3. Establish a Red review SLA - If human review is only for Red PRs, what's the turnaround time? A 4-hour SLA for Red review is reasonable. Longer means the agent fleet is blocked waiting for human decisions; shorter may not be achievable given the genuine complexity of Red cases.
4. Create specialized review tracks for different Red types - Architectural Red PRs should go to the architects. Security Red PRs should go to the security team. Financial Red PRs should go to the engineers with payment system expertise. Routing Red PRs to the right human reviewer is as important as identifying that they're Red.
5. Monitor the Green rate and post-merge defect rate together - At L5, the key health check is whether the automated quality gate is trustworthy. Track both: Green rate (is the gate being appropriately selective?) and post-merge defect rate (is code that auto-merges causing problems?). If the defect rate rises, investigate and tighten the quality gate.
6. Preserve the ability to increase human review - The system should be reversible. If a security incident suggests the Red criteria were too narrow, the team should be able to temporarily broaden them and add more human review. Never architect a system where increasing human oversight requires significant engineering work.

Making humans feel disposable. If engineers perceive the L5 model as "AI replaced me in review," the cultural impact is negative. The reframe: humans are being promoted from operational review work to strategic review work. They're reviewing the decisions that actually require human judgment, not the routine changes that don't.

Red criteria that never shrink. Some teams add Red criteria liberally (out of caution) but never remove or narrow them (out of inertia). The Red list should be managed actively. Schedule quarterly reviews of the Red criteria: has confidence in any of these areas grown enough to shift to Yellow?

Insufficient Red review capacity. If the team has 5 human engineers and 100 agents producing Red PRs at a rate the engineers can't review, the model breaks down. Design the agent fleet size and task assignment to produce a manageable Red rate, or hire for the Red review capacity needed.

No feedback loop from Red reviews to agent improvement. When a human reviewer finds an issue in a Red PR, that finding should improve the system: update the AI review configuration, add a lint rule, improve the acceptance tests. Red reviews are not just about the individual PR - they're a quality improvement feedback loop.