DORA metrics in software engineering: A guide for the AI era

AI can help software teams create code faster, but it does not automatically accelerate code review, testing, security checks, release approvals, or incident recovery. That gap is why DORA metrics in software engineering remain essential in the AI era: they show whether higher code output is translating into healthy, reliable delivery rather than simply more changes entering the pipeline.

AI is already a substantial part of developers’ output: Sonar survey respondents said it generated or significantly assisted 42% of the code they committed or contributed. DORA (DevOps Research and Assessment) metrics were defined for a different era, one where humans wrote nearly all production code manually. The central question now is not whether AI has rendered the framework obsolete. It is whether teams can still interpret the numbers in the same way.

The answer is yes, with an important qualification: DORA metrics still measure delivery outcomes, but AI has changed the delivery conditions behind those outcomes. The current framework applies directly to AI-assisted software development. However, a rise in deployment frequency, for example, may now reflect improved engineering flow, increased AI-generated change volume, or both.

This guide explains the five DORA metrics, their current research-backed AI impact, the measurement blind spots AI can create, and the implementation practices that help software engineering teams distinguish sustainable gains from AI-accelerated instability.

Key takeaways

• The five DORA metrics (deployment frequency, change lead time, failed deployment recovery time, change fail rate, and deployment rework rate) still apply. AI hasn't made the framework obsolete, but it has changed the context in which the metrics need to be interpreted.
• The 2025 DORA report found 90% of professionals now use AI at work, up 14 points year over year. AI adoption is now associated with higher software delivery throughput, but also higher delivery instability.
• Raw DORA numbers can be misleading without AI-specific context, including AI attribution, review-queue health, and complexity-adjusted lead time.

What are DORA metrics in software engineering?

DORA stands for DevOps Research and Assessment, a research program associated with Google Cloud and the research behind Accelerate by Nicole Forsgren, Jez Humble, and Gene Kim. Over more than a decade of research across thousands of technology professionals and organizations, the program identified a small set of delivery measures associated with software delivery performance.

DevOps Research and Assessment program originally popularized four core software delivery metrics. The current framework includes five metrics after the addition of deployment rework rate, which helps teams measure unplanned corrective work more directly.

The five DORA metrics are grouped into two delivery factors: throughput and instability.

The central research finding remains important: throughput and stability do not have to be trade-offs. High-performing teams can deploy frequently while maintaining reliable production systems.

AI does not change that goal. It changes how carefully teams must interpret the route to that goal.

DORA metrics AI impact: What the 2025 report reveals 

The 2025 State of AI-assisted Software Development report, based on a survey of nearly 5,000 technology professionals globally, shows how AI is actually changing delivery.

AI adoption is now the default. 90% of professionals report using AI in their work, up 14 percentage points year over year. The median respondent spends two hours a day working with AI, and 65% describe themselves as heavily reliant on it.

AI increases both throughput and instability. AI adoption is now linked to higher software delivery throughput, a reversal from the previous year. It still increases delivery instability. The open challenge is making sure the additional software works as intended before it reaches users.

Trust hasn't caught up with usage. More than 80% say AI has enhanced their productivity and 59% report a positive influence on code quality. Only about 24% report a high degree of trust in its outputs. DORA researchers call this the trust paradox.

AI is a mirror and a multiplier. The report's central framing is that AI amplifies the engineering practices already in place rather than fixing their underlying weaknesses.

In a cohesive team with clean architecture, AI compounds those advantages. In a fragmented team with tangled pipelines, it accelerates the chaos just as efficiently.

The chart plots the estimated effect of AI adoption on 10 outcomes, each with its 89% credible interval. The throughput effect is weak and uncertain. The instability effect is clearly positive, and since rising instability is undesirable, that is the signal to watch. Individual effectiveness and organizational performance post the largest gains, which means AI is helping people report progress while delivery gets less stable.

Where classic DORA metrics start to mislead in AI-assisted teams

None of this means the five metrics are wrong. It means that reading them without AI-specific context can produce a comfortable but inaccurate picture. A few patterns show up repeatedly. 

From N-iX experience across enterprise engagements, the first signal is rarely the headline metric. It usually shows up in review-queue depth weeks before the change failure rate moves.

Deployment frequency can rise while quality erodes. More deployments do not necessarily mean healthier delivery if instability rises alongside them. Cortex's 2026 Benchmark Report [1] found pull requests per author up 20%, incidents per pull request up 23.5%, and change failure rate up 30%.

Faster coding doesn't guarantee shorter lead time. AI can generate code faster than reviewers can evaluate it, shifting the bottleneck from code creation to validation. A growing review queue can offset gains made earlier in the development cycle.

A flat change failure rate can still mean more absolute failures. If deployment volume doubles while the rate holds at 5%, the organization absorbs twice as many failed deployments.

Deployment rework rate moves before change failure rate does. Change failure rate counts deployments that broke something badly enough to require a response. Deployment rework rate counts every deployment that generated unplanned follow-on work, including fixes that never rose to an incident. When code volume grows faster than review capacity, the additional defects surface as rework long before they surface as failures—which is why a team can hold a flat change failure rate for two quarters while its rework rate climbs underneath it.

The metrics can't tell AI-generated changes from human-authored ones. Without segmentation, a team cannot tell whether a shift comes from AI-assisted work, human-authored work, or a mix. That makes root-causing regressions far harder.

New and companion metrics for AI-era measurement

None of the issues above mean the framework should be replaced. They mean these metrics measure outcomes, while the conditions producing those outcomes sit in data the model never looks at. Four companion signals close that gap. All four come from systems an organization already runs: git, CI, and the code review tool. None of them require new instrumentation.

• Review-queue depth and pending review age. How long do changes wait for human review, and how much work is queued for validation. A rising queue alongside rising deployment frequency is the earliest signal available, and it moves weeks before change failure rate does. This is the number that tells you the bottleneck has left code creation and arrived at validation.
• Propagation cost. The share of the codebase that changes within 90 days whenever a given module changes—a direct measure of how far one change travels. The method comes from Adam Tornhill's [2] behavioral code analysis. In one N-iX engagement on an industrial technology codebase, two services built by the same team in the same repository measured 40.9% and 9.3%. At 40.9%, every change carries coordination overhead across most of the system, and AI-accelerated generation multiplies it.
• Review concentration. The share of all pull request reviews owned by a single engineer over a quarter. Commit data identifies who wrote a module; review data identifies who understood the tradeoffs behind it. In the same engagement, a 99.1% approval rate sat alongside 58.8% single-reviewer pull requests—a review process that read as healthy while transferring architectural reasoning to exactly one person per merge. Above roughly 40% review ownership by one engineer, that person holds architectural memory the team cannot reconstruct from documentation (estimated from field analysis) [3].
• The Westrum culture gap. Ron Westrum's six-item instrument, administered separately to engineers and to their leadership [4]. The finding is the gap between the two scores, not either score alone. DORA's research across 23,000 organizations shows roughly a 30% delivery performance differential between generative and bureaucratic cultures [5]. Where leadership scores generative and engineers do not, warnings that AI-accelerated delivery generates are filed, not routed.

Read separately, each of these is a partial diagnosis. Read together, they are four measurements of one system: culture determines what gets escalated, structure determines who holds the knowledge, knowledge concentration determines where the system breaks, and the combination determines which ordinary workforce event becomes a delivery crisis.

These signals diagnose whether the delivery system can safely absorb AI-generated volume. The next question is whether it can recover when critical expertise is unavailable. DORA metrics in software engineering answer a delivery question: is the team shipping fast, and does what it ships hold up in production? They say nothing about whether the team could keep shipping if a key person left tomorrow. That is what bus factor measures, and where it adds another useful signal.

Bus factor in software engineering: Why it belongs alongside DORA metrics

What is the bus factor definition in software engineering?

The minimum number of team members whose sudden absence would stall a project or system is known as the bus factor.

A low number signals that critical knowledge or operational capability is concentrated in too few people. Teams usually surface this risk by asking who can independently deploy, troubleshoot, or operate each system.

Most teams estimate this risk by asking who would be missed, which yields only a guess. However, the actual number is measurable using data the organization already has.

Commit history shows who wrote each module. Code review history shows who understood the tradeoffs behind it. Architectural memory accumulates review by review, not in documentation. Pull a quarter of review data and calculate each engineer's share of total reviews. Where one engineer owns more than roughly 40%, the team's recent architectural reasoning sits with one person and cannot be reconstructed from the codebase alone (estimated from field analysis).

Combining the two produces a figure that can be tracked quarterly and used in planning:

Departure exposure = (the higher of contribution or review concentration) × propagation cost [3]

A high-concentration engineer on a low-propagation-cost module is a manageable loss. The same engineer on a 40.9% propagation cost module is an architectural event with a date attached.

Addressing bus factor risk: locating your team on the 0-10 scale

Bus factor is typically read as a 0 to 10 scale rather than a single pass/fail line:

Addressing bus factor risk usually means distributing both knowledge and operational ownership through cross-training, runbooks, and shared responsibility.

Why does AI raise the stakes? 

AI can increase knowledge concentration and bus factor risk. An AI-assisted developer can make changes across a larger part of the codebase while accumulating architectural context that does not necessarily reach tickets, documentation, or reviewers. Delivery metrics may remain strong even as understanding of the system becomes concentrated in fewer people.

Knowledge management is the mechanism behind the fix 

Addressing bus factor risk is largely a knowledge management problem. Documentation, code review, and shared ownership all move knowledge from individuals to teams, and all of them are slow. When a departure has a date on it, the faster intervention is architectural.

Placing a defined interface (an abstraction layer) between a high-propagation-cost module and its consumers converts a knowledge reconstruction problem into a standard onboarding problem. The interface carries the architectural contract that previously lived in one engineer's head. Estimated from field analysis, onboarding a replacement engineer into a high-propagation-cost module without that interface runs to roughly 100 developer-days; with it, roughly 30 [3]. The difference has a deadline, and the deadline is the departure date.

This is why the bus factor belongs next to DORA metrics rather than in an HR review. Failed deployment recovery time depends on whether diagnostic knowledge exists beyond the original author. One represents the outcome. The other acts as the driving condition.

AI raises the stakes by letting developers touch more of the codebase. This generates implicit context that often misses documentation, tickets, or reviews. To mitigate this risk, the goal is to turn that individual context into shared team knowledge, including architectural decisions, conventions, and operational procedures.

The DORA AI Capabilities Model (2025)

Alongside the 2025 report, DORA introduced the AI Capabilities Model, which outlines seven organizational capabilities that determine whether AI amplifies an organization's strengths or its weaknesses.

The model matters for both interpretation and planning. Two organizations can post the same DORA numbers while sitting in completely different positions. Strong governance, quality practices, and AI-ready workflows can support sustainable gains, while weaknesses in those areas can limit them. The model provides context for understanding what sits behind the delivery metrics.

The model provides context for understanding what sits behind the delivery metrics, but that context only helps if teams avoid a few common measurement mistakes.

Common mistakes when applying DORA metrics in AI-driven teams

• Rolling out AI without a baseline. Without a "before" number, you cannot separate what AI changed from normal variation. In N-iX engagements, the baseline is set before any broad rollout.
• Measuring individual developers instead of the delivery system. DORA metrics describe how a team and its systems perform. Using them to rank engineers produces bad incentives and worse data.
• Relying on self-reported AI usage without delivery telemetry. In METR’s randomized trial of 16 experienced open-source contributors across 246 completed issues (136 AI-allowed and 110 AI-disallowed), developers expected AI to speed them up and still perceived a 20% gain afterward, while measured completion time was 19% longer [6].
• Treating the measurement framework as static. AI tooling, model capabilities, and team practices evolve quickly, so the signals used alongside DORA should be reviewed as adoption matures.

This mirrors the phased logic N-iX applies in its APEX GenAI acceleration program: assess before piloting, pilot before expanding, and keep measuring throughout.

The bottom line

DORA metrics are not obsolete in the AI era. They still measure software delivery performance, but AI changes the context in which those numbers need to be interpreted.

The companion signals above are not theoretical. They come from N-iX field analysis of production codebases. In the engagement referenced here, 67,000 commits, 6,700 CI builds, and 725 pull requests from an industrial technology company read as evidence of structural state rather than as operational history [3].

Higher deployment frequency or shorter lead time means little if review queues are growing, instability is increasing, or you can't link the gains to AI-assisted work. The answer is not to replace DORA but to pair it with the context the framework does not capture on its own: AI contribution, review-queue health, segmented delivery metrics, and knowledge distribution.

What this looks like in practice: N-iX ran a baseline and phased rollout with a 140-engineer transportation client. Over twelve weeks, features per sprint rose 27%, AI tool adoption moved from 13% to 91%, post-release bugs fell from 15 to 4, and test coverage rose from 55% to 81%. Those are DORA-shaped numbers, measured on the client's own codebase.

There is a reason this matters. N-iX's Pragmatic AI software engineering report found that AI can accelerate the build stage by 2 to 10x. The rest of the delivery pipeline moves at the speed it always did. That gap is why throughput and stability come apart and why the verification tax shows up in review queues. A faster build stage does not make an organization faster. The supporting layer above exists to measure that gap. Teams that have already built AI-augmented development into their workflows are best positioned to close it.

FAQ

What are DORA metrics in software engineering? 

The five DORA metrics are deployment frequency, change lead time, failed deployment recovery time, change fail rate, and deployment rework rate. Together, they measure software delivery throughput and instability.

Are DORA metrics still relevant with AI coding assistants? 

Yes. The metrics themselves do not need to change because of AI. What has changed is how to read them. Throughput and stability used to move together, and AI pulls them apart, so the two now need to be read separately rather than as one score.

What is the bus factor in software engineering? 

The minimum number of team members whose sudden absence would stall a project or system. It measures how concentrated critical knowledge is. A value of one means a single person holds knowledge nobody else can replace. It is also called truck factor or lottery factor.

How do you address bus factor risk? 

Every standard remedy is a knowledge management practice: documentation, code review, pair programming, mentorship, and rotating responsibilities. Start with critical paths, not everything at once. Then test the result by having someone unfamiliar with the system deploy or debug it using only the documentation.

How do team dependencies impact DORA metrics in software engineering?

Concentrated knowledge directly drives stability results when evaluating DORA metrics in software engineering. For instance, recovery time after a failed deployment depends on whether diagnostic context exists beyond the original author. Tracking individual dependencies helps teams explain the human factors behind their technical performance when applying DORA metrics in software engineering.

Sources:

1. Cortex. (2025). Engineering in the Age of AI: 2026 Benchmark Report.
2. Tornhill, A. (2018). Software Design X-Rays: Fix Technical Debt with Behavioral Code Analysis. Pragmatic Bookshelf.
3. Tereshchenko, M. (2026). The hidden cost of knowledge loss and how to prevent paying it. N-iX.
4. Westrum, R. (2004). A typology of organisational cultures. Quality and Safety in Health Care, 13(Suppl. 2), ii22–ii27.
5. Google Cloud / DORA. (2023). Accelerate State of DevOps Report 2023. Google Cloud.
6. Becker, J., Rush, N., Barnes, B., & Rein, D. (2025). Measuring the impact of early-2025 AI on experienced open-source developer productivity. Model Evaluation & Threat Research (METR).