AI can reduce the cost of producing code faster than it reduces the cost of understanding, validating, and operating that code. The gap is review debt: behavior enters the system faster than the organization can build justified confidence in it.
Review debt is not measured in generated lines. It appears as oversized changes, shallow approvals, duplicated abstractions, unowned dependencies, weak failure policy, and incidents whose code nobody can explain.
Optimize for verified change, not output #
Commit volume is an activity measure. The delivery unit is a change whose intent, risk, tests, rollout, and owner are clear.
An AI-assisted pull request should answer:
Intent: what user or operational outcome changes?
Invariant: what must remain true?
Evidence: which tests or measurements support the change?
Boundary: what is deliberately not changed?
Rollback: how is exposure stopped or reverted?
Owner: who can explain and operate it?The human author owns every generated line. “The model wrote it” is provenance, not accountability.
Bound the review surface #
Large generated diffs are cheap for the author and expensive for every reviewer. Set constraints on behavioral scope rather than arbitrary line counts:
- one migration phase per change;
- no unrelated refactor in a reliability fix;
- generated dependencies require explicit justification;
- public API changes include compatibility tests;
- security-sensitive changes require named reviewers;
- generated tests must prove observable behavior, not mirror implementation.
Ask the tool to produce a plan, risk list, and smallest testable patch before implementation. This makes assumptions reviewable earlier, when correction is cheap.
Use risk-tiered evidence #
| Change | Minimum evidence |
|---|---|
| copy or internal tooling | lint, tests, preview |
| ordinary application behavior | unit and integration tests, staged rollout |
| schema or data migration | compatibility proof, backfill plan, rollback |
| auth, payments, tenant isolation | threat review, negative tests, audit trail |
| infrastructure control plane | failure injection, canary, runbook |
AI assistance does not lower the evidence required. It may help generate it, but generated evidence must itself be checked.
Measure system effects #
Track review wait time, change failure rate, rollback rate, escaped defects, median change size, time to understand incidents, and concentration of ownership. Compare AI-assisted and conventional work by risk class. Avoid turning acceptance rate or suggestions per developer into performance targets; they reward volume rather than outcomes.
The SPACE framework is useful here because developer productivity has multiple dimensions—satisfaction, performance, activity, communication, and efficiency. A single throughput number can improve while system comprehension deteriorates.
Failure boundaries #
- Never send secrets or regulated data to an unapproved model endpoint.
- Pin or record relevant tool and model versions for sensitive changes.
- Reject code whose license or provenance cannot be resolved.
- Do not let an agent merge, deploy, and validate its own high-risk change without an independent gate.
- Keep production permissions narrower than repository write permissions.
Trade-offs #
Stricter gates reduce raw speed and can frustrate experienced teams. Loose gates maximize experimentation but shift cost into review and operations. The practical policy varies by risk: fast lanes for reversible, observable changes; strong evidence for irreversible or high-blast-radius changes.
The leadership task is not to maximize AI usage. It is to preserve understanding as the marginal cost of producing code falls.