The AI amplifier. What DORA 2025 is actually telling you about your platform.

Most engineering leaders read the DORA 2025 report and walk away with the headline: 90 percent of developers use AI tools, 59 percent report better code quality. They file that under "AI is working" and move on.

That reading misses the part that matters.

DORA 2025 frames AI as an amplifier. It does not make engineering better. It magnifies what your delivery system already does. If that system is healthy, AI accelerates quality. If it is weak, AI accelerates failure. The headline number averages across both populations, which is precisely why it is misleading. The average hides the distribution that decides your outcome.

The finding that should anchor your AI strategy is not from 2025. It is from DORA 2024. When AI adoption increases 25 percent across an organization, delivery stability drops 7.2 percent and throughput drops 1.5 percent on weak platforms. On mature platforms, the effect inverts. Source: DORA State of DevOps Report 2024. The 2025 report names this dynamic the amplifier and extends the analysis. Source: DORA State of DevOps Report 2025.

The question is not whether AI works. The question is what your platform does to AI's output once it arrives.

Why the amplifier effect happens

AI increases volume. More commits, more pull requests, more deployments. That is not speculation; it is the observed behavior across every organization that has scaled AI tooling to more than a small experiment. When 84 percent of developers are using AI tools and 51 percent use them daily, according to Stack Overflow's 2024 to 2025 surveys, the volume arriving at your delivery pipeline goes up materially.

If your pipeline is reliable, more volume is a good problem. Reviews happen, tests run, deployments land, monitoring catches regressions. The system handles the load.

If your pipeline is fragile, more volume is a force multiplier on fragility. Tests that were slow become a bottleneck. Pipelines that occasionally flaked now fail more often because they run more often. Deployments that required careful timing now compete. Change failure rate climbs not because AI wrote bad code but because the platform was already near its operating limit and AI pushed it past it.

This is the structural explanation for the DORA 2024 numbers. The 7.2 percent stability decrease on weak platforms is not an AI problem. It is a volume problem arriving at an infrastructure that was not built to sustain it.

Three signals that tell you which side you are on

Generic surveys about AI satisfaction will not surface the amplifier effect. They aggregate signal and hide the system dynamic. Three observable signals, tracked together, tell you whether AI is compounding your strengths or your weaknesses.

Signal one: deployment frequency goes up, but change failure rate goes up too

This is the clearest early warning. If your teams are deploying more frequently after AI rollout but your change failure rate is climbing in parallel, AI is accelerating delivery into an unstable pipeline. The volume increase is real. The stability cost is real. The two moving together is the amplifier effect in its most legible form.

The correct response is not to slow AI adoption. It is to fix the pipeline before scaling further. Specifically: test signal quality (not coverage percent, but signal quality, whether tests actually catch regressions), deployment gate reliability, and rollback procedure automation.

Signal two: lead time for changes falls in development, but time to restore stays high

AI consistently compresses the development inner loop. Code that took an afternoon now takes an hour. That metric will improve almost everywhere AI tooling is adopted. The question is what happens to the tail of the delivery cycle.

If mean time to restore production incidents stays at the same level after AI rollout, you have a detection and response problem that AI is not touching. The platform is not surfacing failures clearly enough or fast enough to act on. AI made the front of the funnel faster and exposed how slow the back half always was.

Time to restore is the signal that tells you whether your observability and incident response are keeping pace with AI-driven delivery velocity. If they are not, you are shipping faster into a system that recovers slowly.

Signal three: engineers with AI tools are more productive, but production incidents are increasing

This one is counterintuitive, which is why it gets rationalized away. Individual productivity going up while system stability goes down seems contradictory until you understand what AI is actually doing.

AI offloads the routine, syntax-level work. Engineers feel faster and more capable. What AI does not offload is the cognitive work of understanding the system: how components interact, what the failure modes are, where the edge cases live. On platforms that absorb system complexity through good tooling, documentation, and paved roads, the engineer still has access to that context. On platforms that do not absorb system complexity, the engineer is the only thing standing between AI-generated code and production.

When individual productivity climbs but incidents increase, the platform is failing to absorb the verification burden that AI shifted onto the engineer. The engineer feels effective. The production system disagrees.

The METR 2025 paradox and what it actually means

METR ran a controlled study in early 2025 with experienced open source developers using AI coding assistants on familiar codebases. The result was a 19 percent slowdown compared to baseline. Source: METR 2025.

This finding gets cited as evidence that AI does not work, especially for senior engineers. That reading inverts the lesson.

The METR study captured what happens when senior engineers use AI tools in a context where they have to evaluate every suggestion against a complex, unfamiliar system with no platform support. The cognitive overhead of validating AI output against an entire mental model of the codebase, without tooling that surfaces system context automatically, exceeded the productivity gain from AI-assisted code generation.

That is not an argument against AI. It is an argument for platforms that absorb system complexity. When a senior engineer uses an AI tool on a platform with clear service boundaries, accurate documentation, reliable feedback loops, and opinionated defaults, the validation overhead shrinks because the platform does part of the verification. The METR slowdown is the cost of absent platform engineering, measured precisely.

The engineers who benefit most from AI tools are the ones whose platforms do the most work for them. The ones who slow down are the ones whose platforms leave system complexity entirely to the engineer.

The Larridin 2026 finding and its two readings

Larridin's 2026 research found that AI helps low performing teams four times more than high performing teams in raw output metrics.

The optimistic reading: AI is a great equalizer. Teams that were behind can close the gap. Access to AI tools may reduce the performance spread across an organization.

The cautious reading: low performing teams are gaining volume, not quality. DORA 2025 documents that low performing teams on weak platforms see stability decreases when AI adoption increases. If a low performing team uses AI to ship four times more code into a fragile pipeline, the output volume looks good and the incident volume follows.

The Larridin finding and the DORA amplifier framing point at the same question from different angles. What does the platform do with the output AI generates? That question decides whether a 4x productivity gain becomes a 4x quality gain or a 4x failure rate.

What platforms that capture the upside actually look like

Three properties separate platforms that benefit from AI from platforms that are hurt by it.

The first is Signal Integrity. Metrics that are accurate and acted on. This means deployment frequency, change failure rate, lead time, and mean time to restore measured without gaming. It also means AI-specific signals: throughput quality coupling (are you shipping more good code or more broken code), cognitive offload (how much system complexity is the platform absorbing versus exporting to the developer), and AI agent observability (what fraction of production change is agent-driven and what is its failure rate). Platforms without Signal Integrity cannot tell which side of the amplifier curve they are on.

The second is Delivery Reliability. Pipelines that sustain volume increases without degrading. This requires automated gates, reliable test signal, deployment automation with rollback, and change failure rate held below 15 percent under increased load. When AI-driven volume arrives, a reliable pipeline scales. A fragile pipeline fails more.

The third is Cognitive Absorption. The platform's capacity to absorb system complexity on behalf of the developer rather than exporting it. Paved roads that encode architectural decisions. Opinionated defaults that eliminate decision fatigue. Service boundaries that are clear enough that a developer with AI assistance can work within them without needing to model the entire system. When cognitive absorption is high, AI suggestions land in a context the platform has already structured. When it is low, the engineer becomes the verification layer for everything AI produces.

These three properties are three of the five pillars of the Foundations Framework. They are the pillars that determine whether AI adoption lands on the right side of the DORA amplifier curve.

What this means for your 2026 AI strategy

If you are scaling AI tooling before measuring your baseline DORA metrics, you are flying without instruments. You will not know whether AI is helping until the evidence is already in production incidents and engineer turnover.

The sequence that produces reliable outcomes is straightforward. Baseline first: deployment frequency, lead time, change failure rate, mean time to restore. Identify which pillar is weakest: Signal Integrity, Delivery Reliability, or Cognitive Absorption. Fix the weakest point before scaling AI further. Then measure again.

This is not a slow path. It is the path that avoids the 7.2 percent stability regression that DORA 2024 documented on weak platforms. Six weeks of diagnostic work before scaling AI is a better investment than six months of incident response after scaling blind.

Knowing where your platform stands before AI adoption accelerates is exactly what the Foundations Assessment is designed to answer.

References

• DORA. (2024). State of DevOps Report. https://dora.dev/research/2024/dora-report/
• DORA. (2025). State of DevOps Report. https://dora.dev/dora-report-2025/
• METR. (2025). Measuring the impact of early 2025 AI on experienced open source developer productivity. https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
• Larridin. (2026). AI productivity research. AI helps low performing teams 4x more than high performing teams.
• Stack Overflow. (2024-2025). Developer survey. 84% of developers use AI tools. 51% use them daily.