Measuring Success and When to Roll Back

What success means

A climb has succeeded when the phase's constraint moved and its stability held, both measured against a baseline taken before the AI arrived. Anything less is activity. Earlier chapters showed what happens when the definition is looser. In the pilot described in When Code Gets Cheap, the Bottleneck Moves, pull requests rose 13.6% while quality-adjusted output rose 1% and rework rose 2.6 times (Denisov-Blanch, September 2025 slides, T3). Judged on volume, that pilot was a win. Judged on quality-adjusted output, it barely moved, and it bought that 1% with 2.6 times the rework.

Two kinds of number never count as success criteria, and Economics, Risk and Measurement gives the full reasons.

• Self-report. In METR's 2025 trial (T1), experienced open-source developers working on large, mature repositories they knew well took 19% longer with AI, yet afterwards believed it had made them 20% faster. Other trials, on other tasks and tools, found gains; the point here is the size of the gap between feeling and measurement, not the sign of the effect. Surveys can tell you whether people like a tool. They cannot tell you whether to keep a level. The maturity model's evidence rule applies to success as it does to placement.
• AI's share of the code. It counts input, its definition moves from one statement to the next, and it rises whether or not anything ships faster or breaks less (see volume is not value).

Even a vendor that sells AI measurement says the same. DX's AI Measurement Framework organises its metrics into "three key dimensions: utilization, impact, and cost". It warns that "Metrics like code generation volume are particularly susceptible to gaming", and it "strongly caution[s] against top-down mandates or using metrics for individual performance evaluation" (vendor framework, as of October 2026). Utilisation tells you whether the tool is in use, and only impact can justify a climb. The last warning matters beyond measurement. Once an AI metric enters someone's performance review, people optimise it, and the number stops telling you about the system. People: Roles, Skills and the Junior Pipeline covers what to measure about people instead.

Take the baseline first, because you cannot take it later. METR's 2026 attempt to rerun its trial found that "30% to 50% of developers" were choosing not to submit some tasks because they did not want to do them without AI. METR concluded that "the data from our new experiment gives us an unreliable signal of the current productivity effect of AI tools" (METR, February 2026, T1). Once a tool is part of how people work, the people who would form the control group stop existing. The same thing happens inside a company. If you have not recorded flow and stability for the task type before the agent starts, you will never know what the agent changed. The 90-Day Pilot builds the baseline window into the pilot plan.

One flow metric, one stability metric

The rule is simple. For every phase and task type you climb, pick one metric that should improve if the climb works (flow) and one that would show it backfiring (stability). Report them together, and never report one without the other.

The template is a randomised trial on production work that measured both halves. Google gave half its developers ML-suggested fixes for broken builds for eleven weeks and measured a "~2% increase in CL throughput". It also looked for harm and found "no observable increase in safety risks or bugs", with no detectable difference in rollback rates (Google, April 2024; told in full in Case Studies).

The effect was small, and the verdict is trustworthy because the stability half was measured. A 2% gain with no rise in rollbacks is a result you can keep. The same 2% with an unmeasured rollback rate is a guess.

For the organisation as a whole, DORA's delivery metrics remain the common language. The Thoughtworks Technology Radar (Vol 34, April 2026) places DORA metrics, including rework rate, in its Adopt ring, with a sentence that sums up this chapter: "If lead times don't decrease and deployment frequency doesn't increase, faster code generation doesn't translate into better outcomes." That is practitioner opinion. It matches the evidence.

Each Part II chapter already names its own pairs. The grid below collects them in one place and points back to each chapter's Metrics section; it adds nothing those chapters do not justify.

Notice how often the stability column says "against human changes of the same class". That comparison is also the L3 entry requirement, and almost nobody publishes it. The only public revert comparison between an agent and everything else in the same repository, in this book's evidence, is dotnet/runtime's: 3 of 535 merged agent pull requests reverted (0.6%), against 33 of 4,251 other merged pull requests (0.8%), a difference its author says is not statistically meaningful (Microsoft, March 2026, T2). Even that is not a clean agent-versus-human figure: the 4,251 include 666 merged pull requests from bots such as dependency updaters, alongside 3,585 from people.

You will have to build your own baseline. Most of it already sits in version control and your incident tracker. What is usually missing is attribution: if agent changes are not labelled, you cannot separate their reverts from anyone else's.

The scorecard

The book's proposal is to keep one row per phase and task type, not one number per programme. Each row records the level and the evidence for it, the two metrics with their baselines, the trigger that would send the row down a level, and who owns that decision. The example below is illustrative and describes no real organisation. Templates carries the blank pilot scorecard and rollback-trigger sheet.

SCORECARD (the book's proposal; illustrative values, no real organisation)

PHASE / TASK TYPE           LEVEL  FLOW (baseline -> now)   STABILITY (baseline -> now)    TRIGGER                      OWNER
--------------------------  -----  -----------------------  -----------------------------  ---------------------------  -------------
Maintenance / dep. bumps    L3     landed/wk 12 -> 40       14-day reverts 1.0% -> 0.9%    reverts > human, 2 windows   platform lead
Coding / test cleanup       L2     success rate n/a -> 71%  escaped defects 2 -> 2 (90 d)  any oracle edit merged       team lead
Review / AI first pass      L2     wait P75 9 h -> 7 h      "Not useful" rate 6%           "Not useful" > 10%, 2 wks    review owner
Operations / cache restart  L2     MTTM 34 min -> 22 min    agent-worsened incidents 0     any; or risk score elevated  SRE on call

Every row: baseline window recorded BEFORE the agent started;
trigger written BEFORE the climb.

The value is in the structure, not the numbers. Each row can move on its own, so stepping one task type down leaves the rest of the programme alone. Each row names a person, so a breached trigger does not wait for a meeting to decide whose call it is. The first column also makes the scorecard the same document as the self-assessment in Assess Your Starting Point, which keeps the level you claim and the level you measure on one page.

Rollback triggers

The record here is thin. No company has published criteria for rolling back an AI coding tool or reducing an agent's autonomy, and the searches behind this book found none (see what the record does not contain). The usable precedents come from outside coding agents, and there are three of them.

Google's Tricorder: a numeric off-switch. Google's static-analysis platform counts developers' "Please fix" and "Not useful" clicks on each analyzer's findings. "If the ratio for an analyzer goes above 10%, the Tricorder team disables the analyzer until the author(s) improve it", and it "has disabled an analyzer (on several occasions)" (Sadowski et al., CACM 2018). Code Review applies it to AI reviewers. Here it is the template for every phase, because it has all four parts a trigger needs: a signal collected as a by-product of work, a ratio tracked continuously, a threshold fixed in advance, and an action that is automatic, scoped and reversible.

Google SRE: a downgrade wired into the agent. In Google's design for operations agents, "If an agent requests an L3 (High Automation) execution, but the agent detects an elevated risk score or an anomalous production state, it will automatically downgrade the request to L2 (Partial Automation), intercepting the execution and routing an approval request to a human SRE." There is also a fleet-wide "Red Button" to "pause all in-flight agentic actions, block new actions, or globally revoke L3 permissions" (Google SRE, undated, accessed October 2026, T3). Operations & Incidents sets out the full guardrail set. For this chapter the point is the shape: the trigger is a condition, the action is one level down, and nobody has to convene a meeting.

NIST: the duty to switch off. The voluntary NIST AI Risk Management Framework expects that "Mechanisms are in place and applied, and responsibilities are assigned and understood, to supersede, disengage, or deactivate AI systems that demonstrate performance or outcomes inconsistent with intended use" (NIST AI 100-1, MANAGE 2.4, January 2023). It asks for mechanisms and named owners, not thresholds. Regulatory and Licensing Status tracks where such duties stand.

From these, the book's proposal for a trigger has six parts, and all six are written before the climb:

• Signal: one metric from the stability column, collected automatically.
• Threshold: fixed in advance and set against your own baseline, not against a vendor's figure.
• Window: long enough that one bad week does not fire it, short enough that a bad quarter does.
• Action: scoped to one phase and one task type, usually one level down.
• Owner: the named person who executes it without further approval.
• Re-entry condition: what has to be true to climb back, such as a fixed root cause and a fresh window of clean data.

The sheet below is the book's proposal. The thresholds are starting points to calibrate against your baseline; no organisation has published outcome-validated versions.

Two triggers on that sheet do not move a level. Queue overflow throttles volume, because the climb may be sound while review capacity is not. Reviewer noise switches off a component, not a phase. Matching the action to the failure is what keeps rollback proportionate. A team that can only switch everything off will hesitate to switch anything off.

Self-report and adoption appear nowhere on the sheet. A drop in satisfaction is worth investigating, but it is not a trigger, for the same reason a rise is not a success. The wiki covers the mechanics in kill switches, SLOs and error budgets, quality regression detection and production feedback signals.

Stepping down is normal operations

The rollbacks on record were not planned in advance, and they did not look routine. After the Kiro incident, Amazon, which disputes the FT's account of its cause and duration, said "Additional safeguards include mandatory peer review for production access" (Amazon, 20 February 2026). The maturity model's worked example scores that as a return from de facto L4 to L2, and Case Studies prints both accounts. It was a downgrade, imposed after the fact, with no published trigger.

Amazon's retail business gives a second, disputed example. According to the FT, as relayed by Fortune (March 2026), an internal briefing on a "trend of incidents" with "high blast radius" listed "Gen-AI assisted changes" among the contributing factors, and the planned guardrails reportedly included senior sign-off on AI-assisted changes by junior and mid-level engineers. Amazon's account differs: it said only one incident discussed was AI-related, none involved AI-written code, and no such sign-off is required.

Neither account settles what happened, and this book does not attribute the incidents to "the AI" or to "the human". What the reported plan illustrates is what a downgrade looks like when nothing was written beforehand: broad, drawn by seniority rather than task type, and reportedly drawn up in response to a run of incidents. The proposal in this chapter aims for the opposite: narrow, pre-agreed, and executed by a named owner.

Four habits make stepping down cheap enough to do when the data say so.

• Pre-wire it. Each level is a configuration setting, such as a routing rule, a permission set or an auto-merge flag, so going down one level is a change to that setting, not a project. Google's downgrade runs inside the agent's own request path.
• Exercise it. The maturity model's L3 definition already requires that pause and rollback "exist and have been exercised". A downgrade path you have never used is one you cannot rely on.
• Scope it. One phase, one task type, one level. A team with a stability regression in test cleanup should not lose the dependency bumps that are working.
• Record it without blame. Log each downgrade with the trigger, the data and the re-entry condition. A downgrade log with entries is evidence that the triggers work. One that stays empty for a year may mean they are not looking.

The wiki's scaling back an agent deployment covers the mechanics of a partial retreat. The agent pullback is a measurement failure argues that most public reversals trace back to success metrics chosen badly at the start, and trust outran the agent incident rate shows how confidence can climb faster than the data that should justify it. Measuring ROI connects the scorecard to the business case. When a row in your scorecard steps down, it is the plan working as designed. Scaling Across Teams takes the same rows across an organisation.