“Compliance only ever ratchets up; it never ratchets down.” Paul Stovell, founder and CEO of Octopus Deploy, wrote that in July 2026, and the mechanical image carries the whole argument. A pawl drops into a tooth. The wheel turns one way. It does not come back.
It reads as a complaint about bureaucracy. The accounting underneath is what should worry you. Every control your organization has ever added after an incident is still there. The change advisory board that was supposed to be temporary. The second approver on production config. The mandatory security review that was scoped to one service and quietly grew to cover all of them. Nobody removed any of it, because removing a control requires someone to sign their name under the sentence “this safeguard is no longer necessary,” and nobody wants that signature on file when the next incident happens.
Compliance Velocity Is the Metric Nobody Publishes
Stovell’s sharpest observation is about attention. “We keep talking about developer velocity,” he writes, “but rarely talk about compliance velocity.” Organizations track deploy frequency, lead time, change failure rate. They do not track how fast their own approval and audit machinery can absorb work, which is the actual ceiling.
Push more changes into a pipeline whose safety machinery did not change, and the machinery responds the only way it can. More changes produce more incidents in absolute terms even when the per-change failure rate holds steady. More incidents produce more controls. The controls slow throughput back toward where it started. Stovell’s framing: “If AI makes you ship faster without making you ship safer, you’re not getting more productive, you’re just winding the compliance ratchet a little tighter, and that one doesn’t wind back.”
That last clause is the part worth arguing about. It makes the whole thing irreversible.
We have argued before that review is the constraint AI does not relieve and that cheap generation carries expensive quality costs downstream. Stovell adds a property those arguments did not have: direction. The cost locks in place rather than arriving late and washing out.
A tradeoff can be re-balanced later. You buy speed now, discover it cost you stability, and dial it back next quarter. The ratchet does not work that way. The throughput gain is temporary and the process weight is permanent. Eighteen months after an AI-driven acceleration program, an organization that never invested in change safety sits at roughly its old delivery rate carrying a review process that is materially heavier than the one it started with. The AI spend bought a procedure.
Stovell also names the failure mode teams reach for when the pain arrives: fix it locally, hard. His example is the team that responds to an access incident by deciding that “nobody gets production access, ever, for anything.” As he puts it, that “solves the immediate problem and creates a dozen new ones.” The local fix is always available and always ratchets the wheel one more tooth. It also tends to arrive wearing a new name, which is how a team convinces itself it removed a control while adding one.
What Neither Article Actually Measured
Both of the pieces this analysis draws on are worth reading, and both should be read for their argument rather than their evidence. Neither contains a single measured statistic.
Every number in Stovell’s essay is a hypothetical illustration he constructs to make the mechanics legible. The hundred changes a day becoming two hundred, the leaks per year, the hours of UI tests: those are figures in a thought experiment, not observations from Octopus Deploy’s install base. He does not claim otherwise. Anyone citing them as industry data is manufacturing evidence that does not exist.
GitHub’s contribution is stranger. Dalia Abuadas, an engineer on GitHub’s Copilot Agent Control Plane team, published an argument about the economics of accepting AI-generated changes without citing a single figure from GitHub’s own Copilot telemetry. GitHub has more data on this exact question than almost any organization on earth. That absence is part of the story, and it is worth holding in mind when the argument feels persuasive.
Both authors are also vendor-affiliated in ways that align with their conclusions. Octopus Deploy sells deployment and compliance tooling; a world worried about compliance velocity is a good world for Octopus. Abuadas builds Copilot’s subagent governance layer; a world that needs constrained, governed agent output is a good world for that layer. The arguments still hold. They hold as arguments.
Generation Is Cheap. Ownership Is Not.
Abuadas supplies the mechanism Stovell’s essay leaves implicit: “AI lowers the cost of producing a candidate. It does nothing to lower the cost of owning one.”
Owning a change means reviewing it, understanding it, defending it in an incident review at 2am, and modifying it in six months when the requirement shifts. None of those costs moved. Her formulation is precise: “A change is not cheap just because the code was cheap to generate. It’s cheap only if a human can confidently review and own the result.”
This reframes what an AI-generated patch is for. Abuadas calls the first attempt “a price check, not the product.” Its job is to reveal what solving the problem would cost in ownership, and the shape of what comes back is the answer. A tidy diff in the files you expected means the work was as small as you thought. A sprawl across five packages with a new configuration surface means the request was larger than the ticket admitted.
Her sharpest category is the change that turns out to be “a product decision wearing an implementation costume.” An agent asked to handle an edge case will happily invent a policy for it, encode that policy in a conditional, and hand it back as engineering work. Nobody in the review chain notices that a product decision was just made by a model and ratified by a reviewer who thought they were approving a bug fix.
The Constrained Attempt
The artifact worth stealing from Abuadas’s piece is the contract she attaches to a first attempt. Five rules, given to the agent up front:
- Make the smallest possible patch.
- Keep it behind the existing feature flag.
- Do not change the public contract.
- Add or update tests.
- List every file touched and call out anything risky.
The mechanism sits in what happens on failure. If the agent cannot satisfy the contract, the request was bigger than you thought. The contract stops being a style guide and becomes an instrument: a cheap, automatic sizing probe that runs before any human spends attention.
Behind it sits her review checklist, five questions to ask of the diff rather than the code:
- Did it touch the files you expected, or sprawl across five packages?
- Are the tests obvious, or does the change resist testing?
- Does it preserve the existing abstractions?
- Does it quietly require a new product decision?
- Would you be comfortable owning this in six months?
That last question is the pricing model. Everything else is instrumentation for answering it.
Do This Now
Pick your next ten AI-assisted changes and route them through one rule: no review budget is spent until the change has passed a constrained attempt. Write the five rules into your agent prompt or your PR template this week. When a change fails the contract, do not fix the patch. Split the ticket.
Then run one number for your leadership team. Take your controls added in the last twenty-four months, count how many were removed, and put both figures on the same slide. In most organizations the second number is zero. That is the ratchet, measured on your own machinery rather than in someone’s illustration, and it is the only version of this argument your CFO will find persuasive.
The organizations that come out of the next two years ahead will be the ones that spent their scarce review attention only where ownership was genuinely expensive, and refused to wind the wheel for anything else. Code volume will have very little to do with it.
This analysis synthesizes The Compliance Ratchet (Octopus Deploy, July 2026), The cost of saying yes has changed (GitHub, July 2026).
Victorino Group helps engineering organizations price changes by cost of ownership and spend review capacity where it actually pays. Let’s talk.
All articles on The Thinking Wire are written with the assistance of Anthropic's Opus LLM. Each piece goes through multi-agent research to verify facts and surface contradictions, followed by human review and approval before publication. If you find any inaccurate information or wish to contact our editorial team, please reach out at editorial@victorinollc.com . About The Thinking Wire →
If this resonates, let's talk
We help companies implement AI without losing control.
Schedule a Conversation