The Review Bottleneck: Software Engineering After Code Becomes Cheap

1. The Capacity Limit

The old constraint was implementation time. A feature waited because someone had to write the code, wire the tests, fix the integration edge cases, and get the branch into a reviewable state. AI compresses that part of the loop. It does not compress the obligation to understand what changed.

Public research is already describing the shift. A 2026 longitudinal study of professional engineers found less time spent on writing code and more work spent directing, evaluating, and correcting AI output. The authors call the new category supervisory engineering work. That phrase matters because it names the real job: not typing implementation, but controlling a production system that now emits implementation.

The anti-pattern is measuring AI adoption by PR volume. PR count is not throughput when review is saturated. It is inventory. Inventory hides defects, ages context, increases merge conflict probability, and pressures reviewers into skimming. The team feels faster until the queue starts laundering unread risk into production.

2. The Review Contract

A reviewer should not have to infer the system contract from a diff. That was wasteful before AI. Under agentic generation, it becomes negligent.

The review contract is the smallest document that makes a generated change reviewable. It states the intent, touched ownership boundary, invariants, forbidden behaviors, validation evidence, observability signal, and rollback condition. Without that contract, the human reviewer is not reviewing implementation correctness. They are reconstructing requirements under time pressure from code they did not ask for in that shape.

review_contract:
  intent: "What user or system behavior changes?"
  boundary: "Which module owns the behavior after merge?"
  invariants:
    - "What must remain true?"
    - "What input states must be rejected?"
  generated_by: "human | agent | paired"
  validation:
    tests: "Specific tests added or changed"
    runtime_signal: "Metric, log, trace, or dashboard"
  rollback: "How this change exits production"
  reviewer_budget: "small | medium | senior-critical"
        
      

This is not paperwork. It is a scope limiter. It moves ambiguity out of review and into the authoring step, where it belongs. The review stops being a forensic exercise and becomes a contract check.

3. Risk Tiers

Not every AI-generated change deserves the same review path. Treating a copy edit, a CSS cleanup, a payment-path change, and a data-retention change as the same kind of PR destroys the queue. The queue needs triage before review, not after fatigue has already made the decision.

Low-risk changes can move through lightweight review when the contract is narrow and the blast radius is local. Medium-risk changes need domain-owner review and targeted validation. Senior-critical changes touch public contracts, auth, data, persistence, deployment topology, cross-team dependencies, or rollback complexity. Those changes should not enter review without a written contract and explicit owner signoff.

This is where engineering leaders have to reject false speed. A saturated senior-review lane is not a staffing inconvenience. It is the control point for system memory. If that lane is overloaded, the answer is not to normalize skimmed approvals. The answer is to reduce change size, split risk, defer low-value work, or stop generation until review capacity exists.

4. Agent Review

Review agents are useful when they reduce mechanical load without pretending to own judgment. They can detect missing tests, summarize touched files, compare the PR description against the diff, flag suspicious input handling, and ask whether a rollback path exists. They should not be treated as an approval authority.

The reason is structural. Agent-written PR descriptions can be wrong in ways that look professionally plausible. A 2026 study of agent-authored PRs found message-code inconsistency across real pull requests, including descriptions that claimed changes the code did not implement. High-inconsistency PRs had lower acceptance rates and took longer to merge. The review system has to verify the narrative, not merely read it.

The right model is a two-pass system. Agents do pre-review and evidence assembly. Humans retain merge authority for intent, ownership, and risk acceptance. That keeps automation in the part of the workflow where it scales and keeps accountability in the part where it cannot be delegated.

5. Refusal Lines

A serious AI engineering process needs refusal lines. Otherwise every review policy turns into guidance that gets waived under schedule pressure.

Refuse large generated diffs without a review contract. Refuse PRs where the description cannot be mechanically checked against the changed files. Refuse senior-critical changes that arrive without rollback evidence. Refuse changes that expand ownership ambiguity. Refuse any workflow where passing tests is treated as proof that the system behavior is acceptable.

The teams that win with AI will not be the teams that generate the most code. They will be the teams that preserve judgment under higher code pressure. Code got cheaper. Review did not. Architecture now lives in the gap.