Patrick Debois: review isn't the bottleneck in an AI factory, risk is
Oct 28, the DevOps co-founder argues that when agents open PRs faster than people can read them, the fix isn't a better reviewer but four controls that let a change earn the right to proceed: prevent, verify the outcome, locate the risk, and contain the damage.
In Review Isn't the Bottleneck. Risk Is. on the Tessl blog, Patrick Debois (who coined "DevOps") starts from a familiar picture: an AI software factory generates a change, runs tests, and opens a pull request before a human has finished reviewing the previous one. Review looks like the bottleneck because that's where work stops. His point is that the approval button is carrying five jobs at once (defects, intent, architecture, security, release safety), and adding reviewer agents clears some of the queue without answering the real question: how much confidence is enough, given what could go wrong?
He splits the answer into four controls, none of which substitutes for the others:
- Reduce the likelihood. Tests, static analysis, and policy checks run as part of normal factory execution, and architectural limits are enforced rather than written into a prompt. Adversarial reviewer agents help only when they do distinct work: "Several agents repeating the same assumption do not make it safer."
- Verify the outcome. A green suite proves what the suite checks. An independent verification agent should test acceptance scenarios against the running result, with access to the requirements rather than the coder's account, and the factory should attach an evidence bundle to the exact version up for release.
- Locate the risk. The same evidence justifies different decisions on an internal dashboard and on payment authorization. Dependency centrality, incident history, and reversibility (a revert doesn't undo a data migration) all feed the release policy.
- Reduce the impact. Cells, circuit breakers, flags, rate limits, and tested rollback decide how much room the factory has to be wrong. Autonomy should grow because a failure has been shown to be detectable and containable, not because a rollback procedure exists on paper.
Why it matters for code review
This is the clearest statement yet of what lets an always-on factory keep moving overnight without a person reading every diff: autonomy is granted per decision (edit, merge, expose, modify data) and spends a risk budget that humans set and adjust as successful runs and near misses pile up. It also complicates the "more throughput wins" story. A factory with weak containment has to send everything to a human, so its sustained speed tops out at reviewer speed. His closing line puts it well: factories won't become autonomous by making review perfect, but by making mistakes survivable.