2026-10-12
October 12, 2026
The 2025 DORA report found AI adoption moves delivery speed and delivery instability in the same direction. A dashboard that celebrates the first and files the second under "quality" is lying by omission.
DORA's 2025 State of AI-assisted Software Development report contains a sentence every program lead should be able to recite: higher AI adoption is associated with an increase in both software delivery throughput and software delivery instability. Read it twice. It does not say AI is good, and it does not say AI is bad. It says the two numbers move together, which means any report that shows only one of them has already made an editorial decision for you.
Most delivery dashboards are built the other way around. Deployment frequency and lead time sit at the top because they are easy to pull and easy to celebrate. Change failure rate, rework and recovery time sit lower down, where they get read by the people who were already worried. When AI-assisted coding pushes the top row up, the quarterly review writes itself, and the bottom row becomes a footnote that someone explains away as "teething problems."
Nathen Harvey, the DORA lead, frames AI as an amplifier: in well-organized organizations with strong practices it amplifies flow, and in fragmented organizations with brittle processes it exposes the pain points and bottlenecks. That is a measurement claim as much as a cultural one. If AI amplifies whatever system it lands in, your metrics have to tell you which system you are. A single speed number cannot.
Here is the failure mode in its simplest form. A team adopts AI coding tools. Pull requests get opened faster, deploys go up, lead time falls. Leadership sees a green row and asks for more of it. Six weeks later, unplanned deployments creep up, the on-call load changes shape, and nobody can say whether the two events are connected, because the dashboard never put them on the same page.
The DORA finding is the research-grade version of this story. Throughput and instability rose together. Harvey's own summary of the instability result is that it indicates "critical issues are leading to unplanned deployments." Instability is not a quality abstraction. It is people being paged.
The fix is not a new framework. It is a very old discipline: paired indicators, which Andy Grove described in High Output Management. Every indicator that measures output gets a partner that measures the damage you could do while chasing that output. Speed is paired with stability. Volume is paired with rework. Adoption is paired with trust. You never present one without the other, and you never set a target on one without writing down what the partner is allowed to do.
This is also your best structural defense against Goodhart's law. A target on a single output metric invites the team to improve the number at the expense of everything unmeasured. A target on a pair turns the gaming strategy into a trade-off the team has to make visibly. Laura Tacho, CTO at DX and creator of the Core 4 framework, makes a related point about getting started: begin with controllable input metrics that teams can actually influence, because leaning too hard on output metrics distorts the data. Inputs and outputs are another natural pairing. A team can own review turnaround time. It cannot directly own a business outcome.
Three judgment calls follow from this.
First, decide which pair is your constraint. Not every pair deserves airtime. If your release process is fragile, the pair that matters is deploy frequency against change failure rate. If your reviewers are drowning, it is pull request volume against review latency. Pick the pair where the partner is most likely to bite, and put that pair at the top of the page.
Second, treat trust as a measurement. The same DORA report notes that 30% of developers report little to no trust in AI-generated code. That is not a morale footnote. Distrust is a cost: it shows up as time spent checking, rewriting and second-guessing. The qualitative analysis in DORA's research suggests time saved writing code is often spent auditing it. If your speed metric counts the writing and ignores the auditing, you are measuring the cheap half of the job. Harvey's advice, "trust but verify," is a budget line before it is a slogan.
Third, say out loud what would change your mind. A metric without a pre-declared interpretation is a Rorschach test. Before the quarter starts, write down: if throughput rises and instability rises, we will do X; if throughput rises and instability holds, we will do Y. This is the same instinct as last week's dashboard-as-hypothesis idea, applied to the specific case where the data will probably be ambiguous.
The McKinsey episode from 2023 is a useful reminder of what happens when you skip all of this. Critics including Kent Beck and Gergely Orosz argued that the framework measured output rather than outcomes and risked feeding individual scores into reviews and layoff decisions. The lesson was not that measurement is dangerous. It was that a metric aimed at individuals, without its counterweight, becomes a surveillance tool whether or not anyone intended it.
For a TPM, this is squarely your territory. You usually own the reporting cadence, which means you own the defaults. Changing what sits next to what on page one is a small edit with outsized influence on what your leadership believes about the program.
Try this week. Open your current delivery or program dashboard and, for every output metric on it, write its partner in the margin: the metric that would go bad first if the team pushed that output too hard. If a partner isn't on the dashboard, add it to the same page this week. If you cannot name a partner, you have found a metric you should not be targeting yet.
What it is. A measurement discipline from Andy Grove's management classic: for every indicator that measures the effect of your work, add a second indicator that measures the side effect of pursuing the first, so that optimizing one in isolation shows up as damage in the other.
When to use it. When you are about to set a target on any speed, volume or adoption metric, and especially when a new tool or process is about to push that metric up quickly.
How to run it:
When NOT to use it. When the metric is purely diagnostic and nobody is being asked to move it; pairing adds noise to numbers that are only there for context.
Example: deployment frequency paired with change failure rate and time to restore; AI-assisted pull request volume paired with review latency and rework rate.
DORA: Balancing AI tensions — The primary source for the throughput-and-instability finding and the 30% low-trust figure; read it before anyone quotes a secondhand summary to your leadership.
AI as Amplifier: the 2025 DORA Report with lead author Nathen Harvey (Jellyfish) — Harvey on why AI exposes brittle processes and why the organizational system, not the tool, drives the return.
Setting targets for developer productivity metrics (Engineering Enablement, DX) — Abi Noda and Laura Tacho on starting with controllable input metrics, limiting how many you track, and countering gamification.
"Like with all software changes, we should trust but verify."
— Nathen Harvey, DORA, as quoted by Jellyfish
Don't miss what's next. Subscribe to Critical Path: