What the 2025 DORA Report Actually Says About AI and Platform Engineering

Every year, a wave of blog posts summarizes the DORA State of DevOps report with the same enthusiasm and roughly the same depth: "AI is transforming software delivery! High performers deploy more frequently! Culture matters!" None of this is wrong. Almost none of it is useful.

I want to do something different. Because if you read the actual report, there are specific findings that should change how you make decisions this year, and most of the summaries bury them.

The AI Finding Nobody Is Talking About

The headline finding about AI in the 2025 report is predictable: teams using AI coding assistants report productivity gains. This surprises no one. But there's a more interesting result that got less attention.

Teams that reported the highest AI-related productivity gains were overwhelmingly the same teams that had already invested in developer experience before adopting AI tools. Specifically, teams with fast feedback loops, clear documentation, and reliable local development environments saw dramatically larger gains from AI assistance than teams where those foundations were missing.

This makes intuitive sense. AI coding tools work better when the codebase is well-structured, tests provide clear signals, and the developer can iterate quickly. But the implication is important: if your team is in a high-friction environment, adding AI tools is not a shortcut. You're adding a layer of complexity on top of an already difficult environment, and the gains will be marginal.

The order of operations matters. Fix the foundation, then add the AI.

What the AI Measurement Gap Reveals

Beyond productivity gains, the 2025 DORA data surfaced a finding that is strategically significant for engineering leadership: most organizations cannot measure their AI adoption effectively.

They know which teams have licenses for AI coding tools. They do not know which teams are using them consistently, how deeply those tools have been integrated into daily workflows, or whether the adoption is producing measurable outcomes. The result is that organizations are making AI investment decisions based on license counts and anecdotal engineer feedback rather than on deployment data.

The organizations that report the clearest signal on AI value are those that measured their delivery metrics before adopting AI tools and continued measuring after. When you have a baseline deployment frequency, lead time, and change failure rate, and you can compare them to post-adoption numbers while controlling for other changes, the signal is much clearer. Organizations that launched AI tools without establishing a measurement baseline are largely unable to attribute improvements to the tools specifically.

This is practically important because the investment in AI coding tools is not small. Enterprise agreements for AI development tooling are significant budget items. The ability to evaluate return on that investment requires the same measurement discipline that good software delivery practices require generally.

Platform Engineering: The Data Behind the Trend

Internal developer platforms have been a talking point for a few years now. The 2025 data adds some specificity that's worth understanding.

Teams with mature internal platforms reported significantly lower cognitive load scores, meaning engineers spend less mental energy on infrastructure concerns and more on the actual problem they're solving. The correlation with deployment frequency and reliability was strong.

But the report also found that poorly implemented platforms actively harm developer experience. Teams where the platform was mandatory but unreliable, poorly documented, or slow to respond to developer needs reported worse scores on several developer satisfaction metrics than teams with no platform at all.

The failure mode for internal platforms is not building one. It's building one and treating it as an infrastructure project rather than a product. A platform that engineers don't trust is worse than no platform. They work around it, creating inconsistency and resentment.

If you're evaluating whether to invest in a platform team, the right question isn't "should we build a platform?" It's "do we have the engineering and organizational capacity to treat a platform as a product, with users, feedback loops, and a roadmap, indefinitely?"

The Specific Platform Maturity Findings

The 2025 DORA data is more granular on platform maturity than previous years, and the granularity is instructive.

Organizations in the early stages of platform adoption, those that have built initial tooling and are working to drive adoption, show less improvement in delivery metrics than organizations with no platform. This is the adoption valley, the period where the platform exists but engineers have not yet integrated it deeply enough into their workflows for it to produce productivity gains.

The organizations that exit the adoption valley most quickly are those with two specific characteristics. First, a "golden path" that is better than the alternative on at least one important dimension from day one of launch. The golden path does not need to be comprehensive. It needs to be demonstrably faster or more reliable for at least the most common use case. Second, a feedback loop from engineers to the platform team that operates on a cycle measured in days, not months.

Organizations that have both characteristics reach platform maturity in roughly 12 to 18 months. Organizations that have neither tend to plateau in the adoption valley and eventually abandon the platform investment.

The Culture Finding That Gets Misapplied

Every DORA report since the beginning has found a strong correlation between generative organizational culture (high trust, low blame, open information flow) and software delivery performance. This year is no different.

The finding that gets consistently misapplied is using this as an argument to invest in culture workshops before fixing the structural problems that produce a low-trust environment in the first place.

Culture is downstream of structure. If your on-call process has no runbooks and engineers regularly get paged for things outside their knowledge domain, the resulting burnout and resentment is not a culture problem you can workshop away. It's a structural problem with a structural fix. Fix the runbooks, fix the alert thresholds, fix the ownership model. The culture will follow.

Conversely, a team with good tooling, clear ownership, reliable processes, and genuine autonomy tends to develop a healthy culture as a byproduct. You rarely need to go fix the culture if you've fixed the conditions that make good culture difficult.

The 2025 report makes this structural causation more explicit than previous years. The data shows that organizational culture changes lag tooling and process improvements by roughly 6 to 12 months. The implication is that culture improvement programs launched without corresponding structural improvements produce no measurable change. Culture improvement programs that follow structural improvements produce sustained change that outlasts the initial structural intervention.

What High Performers Are Actually Doing

The gap between high and low performers on the core DORA metrics continues to widen. High performers deploy on demand, have change failure rates under 5%, and restore service in under an hour. Low performers deploy one to four times per month, have failure rates that can reach 45%, and take days to recover.

The practices that distinguish high performers in the 2025 data are not surprising, but they're specific enough to be actionable.

Trunk-based development with feature flags is near-universal among elite performers. Long-lived branches are a strong predictor of low deployment frequency. If your team is working on branches that live for more than three days, this is worth examining.

Comprehensive observability, not just logging, but distributed tracing and real user monitoring, correlates strongly with fast recovery times. Teams that can see what's broken before customers report it recover faster by a factor of several multiples.

Automated testing coverage above roughly 80% for critical paths is common among high performers, but coverage alone is not the metric. High performers specifically invest in test reliability. A test suite that is flaky destroys trust and slows delivery as much as low coverage does.

The 2025 data adds a new finding to this list: high performers have better AI adoption metrics. They are not just using AI tools more frequently. They are using them more effectively, integrating them more deeply into their workflows, and measuring the impact more rigorously. The correlation with strong delivery foundations is the key finding: the practices that make software delivery excellent also make AI tool adoption productive.

Using This in Practice

The practical application of DORA data is not to benchmark yourself against industry percentiles and feel good or bad about the result. It's to identify which metric is most constrained in your system and focus improvement there.

If your deployment frequency is low, the constraint is likely in your release process or test reliability. If your change failure rate is high, the constraint is in test coverage or deployment confidence. If your mean time to restore is high, the constraint is in observability and runbook quality.

Pick one. Measure it weekly. Make it visible to leadership. Improve it. Then pick the next one.

The organizations that improve most consistently are not the ones that launch the biggest transformation initiatives. They're the ones that make this kind of focused, measurable improvement part of how they work every quarter. The 2025 DORA data shows the same pattern that the 2023 and 2024 data showed: elite performance is not achieved through a single transformation event. It is the accumulation of deliberate, sustained improvement over multiple years.

The AI Measurement Framework That's Missing from Most Organizations

The most actionable implication of the 2025 DORA AI findings is the need for a measurement framework specific to AI adoption. Most organizations measure AI investment by license count or by engineer survey responses asking whether people feel more productive. Neither measurement is adequate for making investment decisions.

A more useful measurement framework tracks three dimensions. The first is adoption depth: not just whether developers have access to AI tools, but how integrated those tools are into daily workflows. A developer who uses an AI assistant for 30 minutes per day has a different adoption profile than one who has integrated it into code review, documentation, and architecture work. The difference is visible in productivity outcomes and should be visible in measurement.

The second is workflow quality before and after AI adoption. The DORA finding that AI amplifies existing practices implies that the workflow quality baseline matters as much as the tool itself. Organizations that measure workflow quality, lead time, build reliability, test coverage, before and after AI adoption can directly attribute outcome differences to the combination of baseline quality and AI tooling. Those that do not measure workflow quality have no way to separate the AI contribution from other changes.

The third is the distribution of productivity gains. An AI tool that produces large productivity gains for a specific subset of engineers and marginal or negative gains for others is not the same as one that produces consistent moderate gains across the team. Understanding the distribution shapes decisions about onboarding support, training investment, and workflow standardization.

Organizations that invest in this measurement framework before rolling out AI tools will be able to make much better decisions about where to invest next. Organizations that treat AI adoption as a binary, we have it or we don't, will continue making AI investment decisions based on speculation rather than evidence.

The Developer Satisfaction Finding in 2025

The DORA 2025 data adds a refined picture of the relationship between developer satisfaction and delivery performance. Previous years established that there was a strong positive correlation. The 2025 data provides more granularity on which dimensions of satisfaction are most predictive.

The satisfaction dimension most strongly correlated with elite delivery performance is not overall job satisfaction or compensation satisfaction. It is satisfaction with the quality of the developer's workflow: specifically, whether developers feel that the environment supports them in doing high-quality work efficiently. Developers who report that their environment is helping them be excellent at their jobs are dramatically more likely to be on elite-performing teams than those who do not.

This finding has a specific implication for how engineering organizations should frame DX investment. The goal is not developer happiness in a general sense. The goal is creating an environment where doing excellent engineering work is the path of least resistance. When engineers describe their environment as supporting quality work, they are describing something specific: fast feedback, reliable tooling, clear standards, and the organizational conditions that allow deep focus. These are engineering investments, not culture programs.

The Reliability Metric as a Leading Indicator

The 2025 DORA report's treatment of reliability as a fifth metric deserves more attention than it typically receives. The original four metrics are all delivery speed and quality metrics. Reliability, defined as meeting service level objectives, is an outcomes metric.

The distinction is practically important. A team can have excellent delivery metrics while consistently failing to meet the reliability expectations of their users. Fast, frequent deployments of unreliable services are not a good outcome. The reliability metric is what connects the delivery capability to the user experience.

For engineering leaders, the reliability metric provides a bridge between the engineering team's work and the business outcomes leadership cares about. "We improved our deployment frequency from 4 to 40 times per month" is a process improvement story. "We improved from 91% to 99.5% availability against our defined SLOs, which translates to approximately 250 fewer hours of user-visible degradation per month" is a business outcomes story.

Making the reliability metric part of the standard DORA reporting framework is one of the highest-leverage changes an engineering organization can make to how it communicates with business leadership. The engineers will still use deployment frequency and lead time to guide their improvement work. But the conversation with the C-suite becomes anchored to outcomes rather than to process metrics that require translation.

The Practical Starting Point for DORA Implementation

For engineering organizations that have read the DORA research and want to improve their metrics but have not yet established a measurement baseline, the practical starting point is simpler than most assume.

Start with deployment frequency because it requires the least definitional work. Count how many times per week or month your organization deploys a change to production. You do not need sophisticated tooling. You need an agreed definition of "deployment" and a consistent person responsible for counting. Do this for four weeks before investing in any improvement. The baseline is the foundation of every subsequent conversation about improvement.

Then add lead time. For the next four weeks, track three or four individual changes from first commit to production. Calculate the time for each. Find the average and the median. You will immediately see which step in the pipeline takes the most time, because it will be obvious from the data. That step is your first improvement priority.

The DORA research provides the framework and the benchmarks. The implementation starts with counting. Organizations that defer measurement because they are waiting for a sophisticated analytics system to instrument first tend to defer indefinitely. The organization that starts counting manually and gets better tooling as the practice matures tends to have real data in 60 days and a meaningful baseline in 90.

---

If you want to understand where your team sits on these metrics and what the highest-leverage improvement would be, a DORA baseline assessment gives you specifics in about two weeks.