The metrics DORA does not capture in the ADLC
The four keys were designed for a world where writing code was the constraint. Here is what stopped being measured when that stopped being true, and which absences are worth filling.
There is a moment in most metrics conversations where somebody says “but what would you measure instead”, and the honest answer is usually a long pause. It is easy to explain why an existing metric has lost meaning. It is much harder to name a replacement that is not either unmeasurable, trivially gameable, or a rebranding of something we already have.
I want to try anyway, but with a discipline: for each gap, I will say what it would actually take to measure, and I will be explicit where the answer is “you cannot, not really.” A list of desirable-but-unmeasurable quantities is a wish list, not a metrics proposal, and the software industry has quite enough of those.
Start with why the gaps exist at all.
The shape of the blind spot
The four keys were chosen from a world in which producing correct code was the constraint on delivery. Everything they measure sits downstream of code existing: how often it ships, how long it waits, how often it breaks, how fast you recover. That was the right place to look because upstream of code existing there was only one thing, a developer thinking, and that was assumed to be irreducible.
Agentic development did not make thinking irreducible less true. It made everything downstream of it cheap. So the constraint moved upstream, into the region the four keys were specifically designed not to look at: deciding what to build, specifying it precisely enough to be built correctly, and judging whether what came back is right.
That is the blind spot, and it has a definite shape. Anything that happens before a pull request opens is invisible. Anything that is a property of the relationship between a change and the intent behind it is invisible. Anything about accumulated state, as opposed to flow of events, is invisible.
The four keys sit entirely downstream of code existing: how often it ships, how long it takes, how often it breaks, how fast you recover. That was the right place to look when producing correct code was the constraint.
Agentic development made everything downstream of thinking cheap, so the constraint moved upstream into exactly the region the four keys were designed not to look at.
Let me take the specific gaps in turn.
Gap one: work that gets done twice
Nothing in the four keys distinguishes a change that moved you forward from a change that undid or repaired a previous change. Both are merges. Both count toward deployment frequency. Both are in the denominator of change failure rate, where the second one actually improves the ratio.
Under the old model this mattered less, because rework was expensive enough to be noticed by whoever was doing it. Under the ADLC, an agent that builds the wrong thing, gets corrected and builds it again produces three merges where one was needed and everybody’s dashboard improves.
This is the most important absence on the list and I give it a whole piece later in the series, so I will just plant the flag here: rework rate, in some form, is the fifth key. It is measurable, imperfectly, from patterns in the change record. It is the only candidate on this list that has a shot at being as durable as the original four.
Gap two: whether the thing built matches what was asked for
This is the gap with the largest consequences and the worst measurability.
Under the old model, the correspondence between the ticket and the code was maintained by the developer’s judgement. They read the ticket, understood the intent behind the words, and built that. If the ticket was vague, they filled the gap with context and taste, and the gap-filling was so routine that we forgot it was happening.
An agent fills the gap with the literal text. Vague criteria now produce confidently wrong software, quickly, and the wrongness is not detectable from any flow-plane metric. The pull request merged. The tests passed. The change failure rate did not move, because nothing broke. The feature is simply not the feature that was wanted, and you will find out at acceptance, or later.
Measuring this properly means comparing a diff against a set of acceptance criteria and forming a judgement, which until recently was not something software could do. It is now approximately possible, and it is exactly the kind of judgement a language model can offer an opinion on. But it is an opinion, with a confidence attached, and any metric built on it inherits that uncertainty. The honest form of this measurement is not a percentage on a dashboard, it is a per-change assessment presented to a human alongside the reasoning, with a threshold below which somebody has to look.
I will spend a later piece on definition-of-done adherence as a first-class metric. The short version is that it is genuinely new, genuinely useful, and should never be reported as a single organisational number.
Gap three: accumulated state
Every one of the four keys is a flow metric. It counts events in a window. None of them says anything about the state of the system at the end of the window.
That was tolerable when state changed slowly. Under the ADLC, several kinds of accumulated state can grow fast enough to matter within a quarter:
Unreviewed surface area. How much of the code in production has never been read by a human? This is measurable, crudely, by attributing lines to changes and changes to review depth, and the crudeness is the problem: an approved pull request is not evidence anybody read it. But the direction of travel is worth knowing, and for some organisations, particularly regulated ones, the honest answer to “who reviewed this” is becoming a compliance question rather than a quality one.
Undocumented decisions. The reasoning behind agent-authored changes evaporates by default. Counting pull requests with substantive rationale in the description is a rough proxy, and rough proxies for this are still better than the current situation, which is no visibility whatsoever.
Divergence between the record and the repository. The reconciliation gap I described in the previous piece. This is state, not flow, and it compounds.
State metrics are unfashionable because they do not fit the event-stream model that made flow metrics easy to automate. That is a fact about tooling convenience, not about importance.
Gap four: the cost side
The four keys have no cost term. That was defensible when the dominant cost was engineer salaries, which are roughly fixed over a quarter and therefore drop out of any comparison.
Agentic development introduces a variable cost that scales with throughput. Every change now has a token cost, and the total is not trivially small. More interestingly, cost per accepted outcome is a genuinely new diagnostic: a team burning heavily on iteration around unclear requirements will show a rising cost per outcome even while every flow metric improves. That makes it one of the few available signals for a failure mode that otherwise hides completely.
I flag this as a gap rather than exploring it here, because it belongs to a different series. But of everything on this list, it is the one most likely to be demanded by finance before engineering thinks to volunteer it.
Gap five: review capacity
Not review latency, which is measurable and which the flow plane covers adequately. Review capacity: whether the humans nominally accountable for changes actually have the bandwidth to be accountable for them.
The reason this matters is a simple arithmetic squeeze. Throughput multiplied. The number of people qualified to judge whether a change to the payments code is correct did not. At some ratio, approval becomes ceremonial, and the transition is gradual and unannounced. Nobody decides to stop reviewing properly. The queue simply gets long enough that scanning replaces reading, and there is no event anywhere in your systems that marks the moment it happened.
Proxies exist and all of them are weak. Time spent per review is measurable in some tools and is a poor proxy, because experienced reviewers are fast. Comments per pull request is worse, because the best review outcome is often no comments. Changes per reviewer per week is the crudest and possibly the most honest: if it has tripled, something has given way, and you should go and ask people rather than infer it from a chart.
This is the gap where I am most confident the problem is real and least confident anything can measure it. Some things you have to ask humans about, and pretending otherwise produces a number that makes the question feel answered.
What I would actually add
If I were assembling a metrics set for an agent-heavy team, I would keep the four keys with their bases declared, and add four things.
Rework rate. Some measure of changes that redo previous changes. The fifth key candidate.
Definition-of-done adherence. Per-change, with reasoning, thresholded rather than averaged.
Reconciliation gap. The count of work items whose recorded state disagrees with the repository.
Cost per accepted outcome. The variable-cost term the four keys were never designed to carry.
That is a set of eight, which is too many for a slide, and I would rather have eight honest numbers than four convenient ones. The convenience of four is what got us into the position where a rotting board coexists with elite scores.
Where this breaks down
The obvious objection, and it is a good one: everything I have proposed is less robust than what it supplements.
The four keys earned their position by being hard to game. Rework rate can be gamed by not reverting things and patching forward instead. Definition-of-done adherence depends on the quality of a model’s judgement and on acceptance criteria that a team writes and could write loosely on purpose. Reconciliation gap can be closed by dragging cards rather than by being accurate. Cost per accepted outcome is a ratio of a precise number to a soft one. Every single one is more gameable than deployment frequency, and I am proposing them precisely because deployment frequency has stopped being informative.
That trade is real and I do not want to pretend otherwise. The mitigation is that these are diagnostics rather than targets. The moment any of them becomes something a team is measured against, it will be optimised and it will stop working, and it will stop working faster than the four keys did because it is softer to begin with.
Second objection: I have described the constraint as having moved upstream to specification and judgement, which is a claim about where the bottleneck sits, and bottlenecks differ by organisation. A team with a genuinely excellent product function and clear requirements may find the constraint has moved somewhere else entirely, to review, or to deployment risk, or to a legacy system nobody dares touch. Measuring specification quality at a team whose specifications are fine is expensive theatre. Find your actual constraint before adopting anyone’s metric set, including this one.
Third, and most awkward: several of these gaps are hard to measure for a reason. They involve judgement, and judgement resists counting. There is a real risk that the response to “we cannot measure specification quality” is to build a proxy, ship it, and then manage to the proxy, at which point the organisation has quantified something it does not understand and will make decisions with a confidence the number does not support. Sometimes the correct output of a metrics review is “this matters and we will assess it qualitatively.” That sentence is unsatisfying and it is occasionally the right answer.
Fourth, adding four metrics to four increases the surface for misreading, not just the coverage. Every additional number is a number somebody can quote out of context. If you cannot explain to a non-engineer what each of the eight is computed from and what would make it lie, do not put it on the dashboard.
The takeaway
The four keys are blind to everything upstream of a pull request opening, to the relationship between a change and the intent behind it, and to accumulated state. Agentic development moved the constraint into exactly that region.
The gaps worth filling are rework, definition-of-done adherence, reconciliation gap and cost per accepted outcome. Every one of them is softer and more gameable than what it supplements, which is an argument for treating them as diagnostics rather than targets, not an argument for continuing to look only where the light is good.
The next piece takes the first of those seriously and makes the case for rework rate as the missing fifth key, including the several ways it can be made to lie.