Measure AI-assisted delivery beyond the coding step
DORA 2025 links AI adoption to throughput and stability differently. Define delivery outcomes and test local explanations before treating associations as gains.
By 
Paul. Careers and industry
A team can move more changes into production while making that production harder to operate. An AI rollout therefore needs separate decisions about delivery throughput and stability. Treating them as one productivity score hides the trade the business actually faces. DORA's September 2025 findings provide a reason to investigate the whole delivery system, with local evidence before promises about results.
In this November 2026 retrospective, the 23 September DORA announcement reports a positive relationship between AI adoption and delivery throughput, alongside a negative relationship with delivery stability. It explicitly distinguishes the throughput finding from the previous year's result. A search result quoting an earlier DORA report can therefore answer a different historical question while appearing relevant to the same adoption decision.
The respondent and the service are different units
The announcement describes nearly 5,000 technology professionals responding to a survey and more than 100 hours of qualitative data. That is a count of respondents and qualitative material, not 5,000 randomly assigned organizations or production experiments. Their reports concern several levels of work. An individual's feeling of effectiveness and an application's delivery behaviour do not become interchangeable because both appear in the same report.
The inaugural AI Capabilities Model, also announced on 23 September, describes interviews, question development and survey analysis. Its seven capabilities concern the environment around adoption. Small batches and strong version control, for example, offer useful diagnostic directions. The model is not a recipe guaranteeing that adding a practice will reproduce an estimated association in a particular team.
This distinction changes how a leader reads the report. If developers report faster drafting but deployment waiting remains unchanged, the coding step may have improved without changing elapsed delivery. If deployments become more frequent while failures increase, additional throughput may be purchasing an operating burden. Neither case can be resolved by asking whether people like the assistant.
A strong alternative explanation is organizational maturity. Teams with better internal platforms, clearer ownership and more resources may adopt AI differently and deliver differently for reasons that predate adoption. A survey relationship can reflect those correlated conditions. Statistical modelling can address measured factors without establishing that every important difference was measured or correctly represented.
Selection also matters. People who respond to an AI-focused industry survey may differ from those who do not. Self-reported adoption and outcomes may share recall errors or a respondent's general optimism about the organization. Teams can also change their tools in response to existing delivery problems. That reverse direction is another reason a relationship alone cannot identify what would happen if your team changed one input.
These limitations do not make the findings useless. They make them a source of hypotheses whose assumptions deserve inspection. The practical question becomes which constraint is plausibly binding in the local delivery path. A review queue, tightly coupled release or slow recovery process can deserve attention even if a coding assistant makes its own stage faster. The report does not supply a local effect size for removing any one constraint.
METR measures a different intervention
METR's actual article of 10 July 2025 describes random assignment of AI permission for tasks performed by experienced open-source developers in familiar repositories. It reports 16 developers, 246 tasks and a 19% increase in completion time under the AI-allowed condition. That task experiment is distinct from associations between adoption and delivery-system outcomes.
The results need not contradict one another. They concern different populations, interventions and outcome boundaries. Randomization helps identify a causal effect within METR's study setting; it does not make that setting representative of every delivery organization. DORA's broader reach does not turn its observational associations into the same kind of causal comparison. The METR page now links to a February 2026 update, which is later evidence rather than part of the July result.
For a business decision, the useful response is to name the boundary being evaluated. A task-completion comparison asks about effort to finish defined work. A delivery comparison asks when accepted changes reach users and what happens afterward. Do not subtract a task percentage from a delivery association or combine them into a universal forecast of AI return.
Define the local decision before the rollout
A proposed rollout could start with one service and an agreed class of changes. Record the current path from ready work through review to production. Define throughput and stability separately, including what counts as a failed change and which recovery interval matters. Keep the definitions steady long enough to compare periods, and record concurrent changes in staffing or release policy.
Small batches help make a proposed intervention interpretable because fewer changes compete to explain a result. They do not remove selection automatically. A team that sends only easy work through assistance has changed the comparison. Keep rejected suggestions and review effort visible where the question concerns total effort, and inspect whether work merely moved to reviewers or operators. No such rollout or local uplift was measured for this article.
The strongest objection is that a small team may lack enough releases for a confident statistical comparison. That is a real limit. Use cautious descriptive evidence and a reversible decision instead of manufacturing precision from a thin sample. For custom software development, agree on the service outcome the business wants and the stability cost it will accept. Keep adoption where observed delivery supports that decision, with unresolved explanations recorded rather than presented as a causal guarantee.