Making a Revert Cheaper Than a Careful Read

Making a Revert Cheaper Than a Careful Read is the precondition the two previous chapters depend on. Chapter 6 told you to route some changes around human review, and that advice is only honest if being wrong costs minutes rather than a day, which is a property you build rather than one you have.

Key takeaways

• DORA's 2025 report found, with a high degree of certainty, that AI adoption's positive benefits depend on how often teams use their version control rollback features, and that with more frequent rollbacks AI's positive influence on team performance is amplified.
• DORA describes mature version control as a psychological safety net, and notes that rollback reliance does not itself reduce instability. It changes what instability costs you.
• Instability does not become harmless at speed. DORA tested whether AI adoption weakens the harms of instability and found no evidence of such a moderating effect.
• Faros AI, which sells engineering-productivity analytics, reports incidents per pull request up 242.7% and monthly incidents up 57.9% as of March 2026. That is the arrival rate your reversal path has to serve.
• Measure revert cost as a time, executable by whoever is on call, without the author and without a code change. Above thirty minutes, it is not a control and your triage policy is borrowing against it.

Read this immediately after Chapters 6 and 7, because it is their safety precondition rather than a later refinement, and before Chapter 9, which names the person who pulls the lever. The product-facing counterpart is designing a product around a component that can be wrong, which covers undo for an end user, where this chapter covers delivery-side revert and blast radius for merged change.

The alert fires at 02:40. Error rate on checkout is up, and the deploy that preceded it contained nine merged changes, two of which took the auto-merge path.

The on-call engineer starts reading. Forty minutes later they understand which change did it, and they begin writing a fix, because reverting would conflict with two changes that landed afterwards.

The incident lasts two hours and eleven minutes. Roughly ninety minutes of that was not diagnosis or repair. It was the absence of a cheap way to undo.

Triage is only honest if reversal is cheap

The argument of Chapters 6 and 7 has a hole in it that a careful reader will find, so it is better to name it than to let them find it.

Routing low-risk change past a human is a bet that the risk predicate is right. Predicates are sometimes wrong. If the cost of being wrong is a two-hour incident, the expected cost of triage may exceed the review capacity it saved.

So reversal is not a contingency plan sitting behind the operating model. It is the term in the arithmetic that makes triage positive. Cheap revert buys the right to not read something. That is the trade.

That reframing has a practical consequence for sequencing. If your revert path is slow today, tighten review first and build the revert path second, rather than triaging on credit.

Revert cost, defined as a number of minutes

Revert cost is the elapsed time from deciding to undo a change to production being restored to its prior behaviour, executed by whoever is on call, without the change's author, without a code review, and without writing new code.

Every clause in that definition excludes a common excuse. Without the author, because the author is asleep and, increasingly, was an agent. Without a review, because a revert that needs an approval inherits the queue you were trying to route around. Without new code, because writing a forward fix is diagnosis plus authorship plus a pipeline run.

Measure it rather than estimate it. Pick a low-risk change, revert it deliberately on a Wednesday afternoon, and time the whole thing with a stopwatch.

Most teams are surprised twice. The mechanical revert is faster than they thought. Everything around it, meaning approval, pipeline, cache warming and confirmation, is slower.

What DORA found about rollback

This chapter has an unusually direct primary. DORA's State of AI-assisted Software Development 2025, published 24 September 2025 and fielded from 13 June to 21 July 2025 with 4,867 respondents and 78 interviews, includes strong version control practices as one of its seven named AI capabilities.

DORA reports, with a high degree of certainty, that AI adoption's positive benefits depend on respondents' frequency of use of their version control systems' rollback features to undo or revert changes, and that in the presence of more frequent rollbacks AI's positive influence on team performance is amplified. It reports the same shape for commit frequency, where frequent commits amplify AI's positive influence on individual effectiveness.

DORA's explanation is worth reproducing because it is careful. It describes mature version control as functioning as a psychological safety net, letting teams experiment and innovate with confidence knowing they can revert to a stable state. It then states plainly that rollback reliance does not directly reduce instability, and suspects the positive effect relates to being able to rapidly undo changes when working with larger batches of code.

Read that as an effect on cost, not on frequency. Reverting does not make you break things less often. It makes each break cost less, which is exactly what a triage policy needs.

Instability does not become harmless at speed

There is a comforting argument in circulation that higher instability is a fair trade for throughput, because you can fix forward quickly. DORA tested it.

DORA's report states that AI adoption continues to show a negative relationship with software delivery stability, and that when they checked whether AI adoption weakens the harms of instability on outcomes historically hurt by it, they found no evidence of such a moderating effect. Instability still has significant detrimental effects on outcomes including product performance and burnout.

So the trade does not net out. You do not get to run hotter because you deploy more often. The instability is not free. It is deferred.

The external numbers agree on direction. Faros AI, which sells engineering-productivity analytics, reports incidents per pull request up 242.7%, monthly incidents up 57.9%, bugs per developer up 54% and reopened tickets up 12.6%, from between-quarter comparisons across 22,000 developers as of March 2026. CircleCI's report of 18 February 2026 puts main-branch success at 70.8% and median recovery to green at 72 minutes, up 13% year over year.

Revert has to be a first-class path, not a heroic one

A revert that exists in principle and is used twice a year is a belief. Four properties separate a real path from a documented one.

It is exercised routinely, so the mechanism is known to work and nobody is learning it during an incident. It is exempt from the review queue, because an approval requirement puts the reversal behind the bottleneck the reversal exists to compensate for. It runs a reduced pipeline, on the argument that the state being restored was green a few hours ago. And it is operable from a phone by whoever is on call, with no local checkout.

The exemption is the one that causes an argument, so state the compensating control alongside it. A revert without an approval still requires an incident record naming who reverted what and why, which is a stronger audit trail than an approval click ever was.

The routine exercise is the property most often skipped. I would revert something deliberately once a month, in daylight, and record the elapsed time as a tracked metric. An untested revert path is a story you tell yourself.

Blast radius is designed, not hoped for

Reversal speed is one half of containment. The other half is how much is exposed while you are deciding, and that is a design property you choose before the change ships.

Four mechanisms do most of the work. A feature flag, so the new path can be disabled without a deployment, which is the fastest reversal that exists. A staged rollout, so a fraction of traffic meets the change first and the population at risk is bounded. Additive-only schema changes, so the migration never needs undoing and the code can move independently. And a separately deployable unit, so reverting one thing does not revert five.

Notice that all four are the same discipline Chapter 7 asked for. A change that is small, single-purpose and independently deployable is also a change that is cheap to reverse, which is why those two chapters sit next to each other.

The one mechanism people reach for and should not is the database migration that drops or rewrites. Once data is gone, reversal is restoration, which is an order of magnitude slower and carries its own risk.

Two paths from a bad merge

The table below is the comparison that decides your triage budget, and the columns are the ones worth measuring in your own system rather than accepting from mine.

The rows are in ascending order of cost and descending order of how often teams are able to use them. Most organisations live on row three and think of row one as an aspiration. That ordering is backwards, and correcting it is the cheapest reliability investment available.

A worked example, composited and labelled

The details here are composited from ordinary production shapes rather than one system, and the shape is exact.

A team decides to adopt the triage policy from Chapter 6, and before turning it on they time their revert path. It takes 68 minutes, and the breakdown is instructive.

Four minutes to identify the offending merge. Two minutes to raise the revert. Twenty-two minutes waiting for an approval, because branch protection required one and it was 03:00. Thirty-one minutes for the full pipeline, which runs the complete integration suite on the default branch. Nine minutes for caches and confirmation.

Three changes take it to 21 minutes. Reverts are exempted from human approval and instead require an incident record, which is a policy decision somebody signs. The pipeline gains a revert path that runs only the smoke suite, on the argument that the state being restored was already green. And the deploy pipeline gains a warm target so cache priming is not on the critical path.

Only then does the triage policy go live. The order matters, and it is the whole point of this chapter appearing here rather than at the end.

The objection: reverting looks like churn and undermines confidence

Two versions of this objection turn up, one from engineers and one from executives, and they need different answers.

The engineering version is that reverting somebody's work is a social cost and encourages carelessness. My answer is that a revert is a neutral operational act when the policy says so in advance, and the alternative is worse for the same person: their change stays broken in production while they are paged to fix it under time pressure. Make the revert the default response to any production symptom during the first hour, written down, so nobody has to propose it.

The executive version is that a high revert rate looks like a quality problem. Sometimes it is, and Chapter 11 covers how to tell, because DORA's instability factor is exactly change fail rate and rework rate. The distinction to hold is that a revert followed by a considered fix is a functioning control, whereas an incident that ran for two hours because reverting was unavailable is a missing one.

There is a real cost I would not talk anybody out of. Building this takes platform work, specifically flag infrastructure, migration discipline and a fast pipeline path, and none of it ships a feature. The honest framing for that conversation is that it is the price of the review capacity you are about to stop spending, and Chapter 12 puts both on the same page.

Chapter summary

Reversal is the precondition for triage rather than a contingency behind it, because routing change past a human is a bet on a predicate and the bet only pays if being wrong costs minutes. Revert cost should be defined and measured as elapsed time from decision to restored behaviour, executed by whoever is on call, without the author, without an approval and without new code, and it should be measured with a stopwatch on a deliberate Wednesday revert rather than estimated. DORA's report of 24 September 2025, from 4,867 respondents, found with a high degree of certainty that AI adoption's positive benefits depend on how frequently teams use version control rollback features, that more frequent rollbacks amplify AI's positive influence on team performance, and that frequent commits amplify its influence on individual effectiveness, while describing mature version control as a psychological safety net and stating that rollback reliance does not itself reduce instability. That is an effect on the cost of a break rather than its frequency, which is precisely what triage needs. Instability does not become harmless at speed: DORA checked whether AI adoption weakens the harms of instability and found no evidence of such a moderating effect, and Faros AI reports incidents per pull request up 242.7% and monthly incidents up 57.9%, with CircleCI reporting main-branch success at 70.8% and median recovery to green at 72 minutes. Blast radius is designed through flags, staged rollout, additive-only schema changes and independently deployable units, which are the same properties Chapter 7 asked for. Order the work so the revert path is fast before the triage policy goes live.

Somebody has to decide to pull the lever, and be answerable afterwards. When the change was generated rather than typed, that person is not obvious. Chapter 9 is Ownership When Nobody Typed the Code.