Back Pressure: The Risk Model Is the Approval Surface

Amplitude reports tripling pull requests in six months at the same headcount, cutting PR cycle time from 5.2 hours to 44 minutes, and dropping monthly bug reports from 715 to 319 while merging three times the code. The metric that usually moves the wrong way, defect volume, fell 55%. Their engineering org attributes this to one design decision: a risk model scores every change, and the score decides who, or what, approves the merge.

That decision answers a question most teams frame badly. The “light factory versus dark factory” debate, humans review everything versus agents ship unattended, gets argued as a philosophy. It is a pricing rule. Addy Osmani gave it a name in July 2026: back pressure.

Back pressure is a pricing rule

Osmani’s formulation is precise: “Back pressure is the rule that you can only hand a loop as much autonomy as you can cheaply and reliably verify, and not one inch more.” Autonomy is a quantity you purchase, and the currency is verification. A change you can check for free with a fast, trustworthy oracle can run unattended. A change whose only check is a senior engineer reading it carefully cannot, because that check is neither cheap nor high-frequency.

This reframes the whole light-versus-dark argument. The two factories are two ends of a dial, and the dial position for any given change is set by how good your verification is for that change. Where you can verify cheaply, the loop earns the dark. Where you cannot, a human stays in the loop. The failure mode is treating the dial as a switch and flipping the whole codebase to one setting.

What Amplitude actually built

Amplitude’s engineering, product, and design org runs the production version of this rule. Per their account of it, every proposed change is scored by a risk model on concrete dimensions: change size, scope, the part of the codebase touched, test coverage, and whether it modifies a public API or a data model. A low-risk change with all review comments resolved merges automatically, with zero human clicks. Medium and higher risk routes to code-owners for human review.

The learning loop is the part worth copying. When a change slips through and causes a problem, the miss-merge feeds an eval suite that retunes the risk model. The model that decides autonomy is itself under test and improving from its own mistakes. This is back pressure made operational: verification quality is measured, and autonomy expands only as that quality is demonstrated on real misses.

Wade Chambers, Amplitude’s Chief Engineering Officer, frames the throughput numbers as a byproduct of this discipline rather than the goal. Frontend CI dropped from 30 minutes to 3 or 4. Treat these as self-reported: the announcement carries no publication date and “same headcount” is not externally verifiable. The mechanism, not the exact figures, is the transferable part.

What makes a check good enough to trust

Not every green check earns autonomy. Osmani’s “earns the dark” checklist names the properties a verification must have before a loop is allowed to run on it unattended. The check must be cheap to run, high-frequency, hard to fake, immediate, and non-drifting. A test that takes an hour is not high-frequency. A metric an agent can trivially game is not hard to fake. A check whose meaning erodes as the codebase changes is drifting, and yesterday’s green tells you nothing today.

The oracles that qualify are familiar: green-or-red test suites, type gates, property-based tests, and a review agent working from a real rubric rather than a vibe. Amplitude’s risk dimensions map onto this cleanly. Test coverage is a proxy for how good the automated oracle is. Public-API and data-model flags mark exactly the changes where a cheap check cannot catch the expensive failure, so those route to a human. The risk model is, in effect, a running estimate of whether the available verification is strong enough to buy autonomy for this specific change.

SOC2 does not need a human to click approve

The objection every regulated team raises: compliance requires an approver. Amplitude’s answer, per their account, is that SOC2 is satisfied by documented criteria, logged decisions, and override paths, not by a human pressing a button. The auto-merge is auditable because the criteria that authorized it are written down, the decision is logged, and a human can override. Approval and validation are recorded as separate signals, so an auditor can see both what was allowed and what was checked.

This is the argument most governance writing misses. Auditors want provenance and reproducibility. A logged, criteria-driven, overridable automated decision is more auditable than a human who clicked approve on 40 PRs in a hurry, because the automated path records why. Compliance is a reason to build the risk model, since the model produces exactly the documented, logged decision trail an audit demands.

The liability that accumulates in the dark

There is a cost to running the dial too far toward dark, and Osmani names it: comprehension debt. His case study is a fully automated factory that ran for about four months with no human reading the code. It ended in a major failure that required painstaking manual debugging, by people who had never built a mental model of the system they now had to repair. The autonomy was real. So was the debt it accrued, invisible until the bill came due.

Comprehension debt is what back pressure prices in. Every change that ships without human comprehension is a small loan against future debuggability. If your verification is strong, the loan is cheap and worth taking at volume. If your verification is weak and you ran the loop anyway, you borrowed against a system nobody understands, and the interest is paid in a four-month unwind. Amplitude keeps humans on medium-and-higher risk precisely so comprehension tracks the changes most likely to need it.

Do this now

Pick your ten highest-frequency change types from the last month of merged PRs. For each one, name the check that would let it merge without a human, and run it against Osmani’s five properties: cheap, high-frequency, hard to fake, immediate, non-drifting. The change types that pass all five are your candidate dark set. The ones that fail are where a human stays, and the specific failing property tells you what to build to move them later. That single sheet is your risk model, version zero. Wire the auto-merge for the passing set, log every automated decision with its authorizing criteria, and add one rule Amplitude proved: when an auto-merge causes an incident, feed it back and retune. You now own a dial instead of a switch, and you can prove to an auditor exactly where it is set and why.

---

This analysis synthesizes Software Factories, Light and Dark (Addy Osmani, engineering leader at Google Chrome, July 2026) and Speedrunning software (Amplitude EPD × AI, with Chief Engineering Officer Wade Chambers, 2026).

Victorino Group helps engineering organizations turn per-change autonomy into a documented, auditable risk model instead of an all-or-nothing switch. Let’s talk.