DORA 2025: AI Amplifies Whatever Your Team Already Is

The 2025 DORA State of AI-assisted Software Development report - from Google's DevOps Research and Assessment programme - concludes that AI's primary role is as an amplifier: in DORA's words it magnifies an organization's existing strengths and weaknesses. Google's announcement puts it more bluntly: AI doesn't fix a team; it amplifies what's already there.

Note: this article draws on DORA's published summaries and Google's announcement, not the full report text. Where we add our own reading it is labelled as ours. Verify any figure against the full report before citing it.

What the amplifier finding actually means

DORA reports that, unlike the year before, AI adoption now shows a positive relationship with software delivery throughput and product performance, and a continuing negative relationship with delivery stability. It attributes the stability problem to AI increasing change volume: without controls such as strong automated testing, mature version control practices and fast feedback loops, that volume leads to instability. In our reading, that is what an amplifier looks like in practice: output arrives faster, and a team without a reliable baseline has more to check, not less.

This is not surprising once you think about it carefully. AI tools generate plausible code quickly. Whether that speed converts into delivered value depends entirely on whether your team can evaluate, test, and integrate what comes out. A team with no automated tests, no code review standard, and no deployment pipeline will find that AI-generated pull requests pile up or get merged without verification - the exact pattern described in our read of the Veracode 2026 report and in the security risk evidence across vibe-coded apps.

What DORA 2025 measured and how to read the self-reporting limitation

DORA's 2025 research drew on nearly 5,000 technology professionals and more than 100 hours of qualitative data, and looked at AI adoption across the software lifecycle, with outcomes framed around software delivery throughput and stability.

The findings come from a survey, so they describe what respondents report and associations between practices and outcomes. Causation is hard to establish from that kind of data: do good practices make AI work better, or do teams with AI tools also tend to invest more in overall quality? Both are plausible, so treat the findings as directional.

For a founder or tech lead reading the headline numbers, this matters. A headline like 'teams using AI coding assistants ship X% faster' does not mean 'buy the AI tool and delivery will speed up.' It may mean 'teams that invest in developer tooling invest in everything else too.' Read DORA findings as directional signals, not as a product buying guide.

The three areas where AI showed the clearest signal

Code generation and review speed

The adoption numbers are high: DORA reports that 90% of respondents use AI at work, more than 80% believe it has increased their productivity, and about 30% have little or no trust in AI-generated code. That mix, heavy use alongside real distrust, is why review habits matter more than the tool.

Security lag: faster code, same (or slower) verification (Zovintra reading, not a named DORA finding)

DORA's stability finding does not single out security, but we read it as pointing at the same gap: code gets generated faster while review and testing capacity stays flat, so more unverified code reaches production. That is our interpretation, not a DORA result. AI-generated code and security risk is an area we track closely for clients.

Reliability and on-call burden (Zovintra reading, not a named DORA finding)

DORA did not give us a basis for claims about AI in incident response, so this section is opinion. If the amplifier idea holds, AI summaries of incident data will be only as good as the observability underneath them: well-labelled metrics, structured logs and sensible alert thresholds. Noisy alerting will give an AI summariser noisy input.

Why small teams feel this asymmetrically

A 200-person engineering org can add AI tools as an incremental layer on top of existing processes. A five-person team that is simultaneously building the product, onboarding customers, and managing infrastructure cannot. For small teams, every process decision is load-bearing. Adding AI-assisted code generation without a corresponding change in review standards will degrade quality faster than the speed gain is worth.

DORA's own advice is that the biggest returns come from the organization's underlying system rather than the tools, and it describes a model of seven capabilities that magnify AI's benefits. Our practical version for a small team is to define a clear scope for AI assistance (particular tasks, particular types of PRs) and keep human judgment on architecture and security-sensitive code. That aligns with how we approach AI-assisted development in our own process.

The process foundation AI cannot replace

If there is one practical takeaway from the DORA 2025 amplifier finding, it is a checklist of the things you need in place before AI tools will reliably help rather than hurt:

Automated tests with enough coverage to detect regressions in AI-generated changes (not 100%, but meaningful - unit tests for core logic, integration tests for critical paths)
A defined code review standard that tells reviewers what to look for in AI output, not just style and correctness
Deployment automation so that faster coding converts into faster shipping, not a longer staging backlog
Security scanning in CI so that the review burden for security does not fall entirely on human eyes
Clear ownership: someone is accountable for production behaviour, not just merge approval

These are not new engineering practices. The AI-era version is the same list with higher urgency, because the cost of not having them scales with how much code you generate. Twice the code output with no change in review capacity means twice the surface area for problems to hide.

What to do with this if you are leading a small team

Start by auditing your current state against the foundation checklist above. If you have gaps - no automated tests, manual deployment, no security scanning - address those before expanding AI tool usage. The order matters. Fixing the foundation first means the AI acceleration compounds on something solid. Skipping the foundation means acceleration toward technical debt.

If you are already using AI tools and noticing slower review cycles, rising bug rates, or more production incidents, the amplifier finding suggests the problem may not be the AI tools themselves but the process infrastructure they revealed as missing. That is a diagnosis, and it is fixable. Read our piece on what evidence actually says about AI coding speed for a companion view on interpreting AI productivity claims.

If you want an independent view of where your process foundation stands, request a technical review and we will look at what your team has in place before recommending whether adding more AI tooling is the right next step.

Common questions

Does AI make software teams faster or just amplify their problems?

DORA's 2025 research says AI magnifies an organisation's existing strengths and weaknesses. It reports a positive link with delivery throughput and product performance, but a continuing negative link with delivery stability, because more change volume overwhelms teams lacking strong testing and fast feedback.

What should a small team have in place before adopting AI coding tools?

Automated tests that detect regressions, a code review standard for AI output, deployment automation, security scanning in CI, and clear ownership of production behaviour. Fix gaps in these foundations before expanding AI tool usage.

When should I get an independent view of my team's process?

If you are using AI tools and seeing slower reviews, rising bug rates or more incidents, request a technical review. Zovintra will look at what your team has in place before recommending whether more AI tooling is the right next step.