The DORA AI Capabilities Model

An engineering VP six months into a company-wide AI rollout pulls two reports for the same quarter. The adoption dashboard is a success story: nearly every team uses an AI coding assistant daily, and a pulse survey says developers feel meaningfully faster. The delivery dashboard — built on the same DORA metrics the org has tracked for years — tells a flatter story. Deployment frequency is unchanged. Lead time for changes is unchanged. Change failure rate has ticked up half a point. The VP’s first instinct is to distrust one of the two reports. Usually that instinct picks the wrong one to doubt.

This Library has cited DORA’s 2025 finding that AI acts as an amplifier — of an organization’s existing strengths and its existing dysfunctions — several times already, most fully in Volume VIII’s capstone and in Volume IX’s opening chapter. Both uses treated the line as a conclusion worth quoting. Neither unpacked what actually sits underneath it: a real, named model of seven organizational capabilities, and a specific, evidenced account of why individual-level AI gains routinely fail to become organization-level delivery gains. That is this chapter’s job — not to re-cite the headline, but to open it up.

It is also worth naming the trap the VP’s two reports set for each other. Volume I of this Library established that engineers systematically misjudge their own AI-assisted speed — measurably slower in a controlled trial while believing themselves faster by a wide margin. The same caution applies here at the org level: a pulse survey saying developers feel faster is a real data point, but it is a perception measurement, not a delivery measurement, and the two have already been shown to diverge. DORA’s 2025 research does not resolve that divergence by picking a side. It resolves it by asking a different, more useful question: under what conditions does the felt speed actually reach the delivery numbers, and under what conditions does it stall before it gets there?

What the 2025 report actually measured

DORA’s State of AI-assisted Software Development 2025 report is the ninth in a research program running since 2013, and the first built specifically around AI adoption. The methodology is the same mixed-methods approach the program has used for a decade: a global survey of nearly five thousand technology professionals, paired with over one hundred hours of qualitative interviews, run in mid-2025. The scale matters for confidence — this is not a vendor case study or a single company’s internal telemetry, it is the closest thing the industry has to a longitudinal, cross-company instrument for software delivery performance, now pointed at AI specifically.

The report’s central claim is that AI does not have a uniform effect on software delivery performance. It has a conditional one: strong effect where organizational fundamentals are already sound, weak or negative effect where they are not. The report frames this explicitly as an amplifier — AI does not fix a struggling team any more than it breaks a strong one; it magnifies whichever one already exists. That framing is why a rollout can produce genuinely higher individual output and a flat or worsening delivery dashboard in the same quarter, without either number being wrong.

Individual speed, organizational stall

The mechanism behind that stall is not mysterious once it is named, and DORA’s own research names it directly. A separate ten-thousand-developer dataset — already discussed in this Library’s Volume VIII capstone, Building Better Systems (Chapter 10) — found teams using AI completing 21% more tasks and merging pull requests at nearly double the prior rate, while organization-level delivery metrics stayed flat and code review time grew 91%. DORA’s 2025 research gives that pattern a mechanism rather than just a correlation: velocity gained by the person authoring a change tends to show up as added cognitive load for the person reviewing it, not as proportional velocity for the team. Code that used to arrive at a reviewer’s queue in modest, well-understood increments now arrives faster, larger, and more often — and the reviewer’s attention did not get any faster to compensate.

This is a constraint problem, not a productivity problem. Generation sped up; verification did not. In a pipeline with a fixed downstream capacity, speeding up the fastest stage does not speed up the pipeline — it just grows the queue in front of the stage that was already the bottleneck. The report’s own recommendation follows directly from that diagnosis: treat AI adoption as a whole-value-stream problem and watch the downstream signals — review turnaround time, deployment rework rate, recovery time from failed deployments — rather than only the generation-side signals that make the adoption dashboard look good. An organization that only instruments the fast stage of its own pipeline will keep being surprised that going faster there did not make anything else faster.

A gain that cannot clear its own bottleneck does not vanish. It queues.

The DORA AI Capabilities Model

The amplifier framing raises an obvious follow-up question: amplifies relative to what, exactly? DORA’s answer is the AI Capabilities Model, a companion result from the same 2025 research: seven specific, measurable organizational capabilities that the data shows predict whether AI adoption converts into individual effectiveness, code quality, and organizational delivery performance — as opposed to converting into faster, larger queues in front of an unchanged bottleneck. Only one of the seven is really about AI tooling in the narrow sense; the rest are engineering fundamentals that predate agentic coding by years and simply matter more, not differently, once an AI is amplifying whatever is already true about how the team works.

The seven capabilities

What the list is really saying

Read the list again with the amplifier framing in mind and the pattern is unmistakable: six of the seven capabilities have nothing intrinsically to do with AI. Version control discipline, small batches, a user-centric focus, and a usable internal platform are exactly the practices this research program has been recommending since its earliest reports on general software delivery performance. AI did not invent any of them as a requirement. It raised the cost of skipping them, because a team without disciplined version control absorbed a slow, survivable trickle of manual change before, and now absorbs a much faster, much larger flow of AI-generated change with the same undisciplined process. The capability that is genuinely new — a clear AI stance — is closer to a policy prerequisite than a technical one. Everything downstream of it is an old fundamental under new pressure.

One capability in the table earns a harder reading than the rest: user-centric focus. For the other six, the report describes an amplifier in the ordinary sense — present, it multiplies a positive; absent, the multiplier is smaller, but AI adoption is not reported as actively net-negative. User-centric focus is the exception. DORA’s research reports that without it, AI adoption can measurably hurt team performance, not merely fail to help it. A team pointed at the wrong problem does not stand still while it adopts AI — it moves faster toward the wrong problem, and every other capability on the list, done well, only makes that faster movement more efficient. That single asymmetry is a useful test of whether an organization has actually internalized the amplifier framing or is only repeating it: a team that treats all seven capabilities as equally optional has not.

What the gap looks like in session data

Where this sits relative to the four keys, SPACE, and DX Core 4

This volume opened with the field’s existing measurement frameworks — DORA’s own deployment-frequency-and-lead-time metrics (long known as the four keys, now a five-metric model), the SPACE framework’s five dimensions of developer productivity, and DX’s newer Core 4 model spanning speed, effectiveness, quality, and business impact. The AI Capabilities Model is not a fifth entrant competing with those for a team’s dashboard. It answers a different question. The four keys, SPACE, and DX Core 4 all measure outcomes — what actually happened to delivery, satisfaction, speed, or impact. The AI Capabilities Model measures the preconditions that determine whether adopting AI moves those outcome metrics at all. A team can be fluent in all three outcome frameworks and still be unable to explain why its AI rollout has not touched a single one of its numbers, because none of those frameworks was built to ask about version control discipline or internal data quality in the first place.

That is also why this chapter stops short of building a measurement program around the seven capabilities. Turning "did AI adoption actually move our delivery numbers" into a running practice — deciding what to instrument, at what grain, and how to avoid the same activity-metric trap this volume’s first chapter warned about — is this volume’s Chapter 6, Measuring AI, and it deserves its own treatment rather than a rushed conclusion here. What this chapter establishes is the precondition for that later one to matter: before measuring whether AI adoption is working, an organization has to know whether it has the seven capabilities in place to convert adoption into anything measurable at all.