Google's DORA team surveyed nearly 5,000 technology professionals in June and July 2025 and found that 90% of them now use AI at work. That number gets quoted everywhere as a win. The finding sitting right next to it in the same report gets quoted far less: teams with higher AI adoption also report higher software delivery instability, meaning more change failures and more rework, at the same time as higher throughput. AI didn't make the tradeoff between speed and stability go away. It made both sides of it bigger.
AI is not fixing your engineering problems, it's amplifying them
DORA's own framing for this is "amplifier," and it's a more useful word than "productivity tool" for anyone deciding how far to push AI coding assistants through their team this year. An amplifier doesn't add a new capability, it turns up whatever is already there. A team with clean version control, small pull requests and a real code-review habit gets faster without breaking more, because those habits were already absorbing the extra volume. A team without them gets faster and breaks more, because nothing in their process was built to catch what a much larger volume of generated code now needs caught. Same tool, opposite outcome, and the difference isn't the tool.
What 90% adoption actually bought engineering teams in 2025
DORA's State of AI-assisted Software Development report, published September 23, 2025, is the fourth in a research series that's run since 2014, and this edition is the first built specifically around AI's effect on delivery. Alongside the 90% adoption figure, DORA reports that roughly 85% of respondents say AI increased their own productivity, split into 13% who said the increase was extreme, 31% moderate and 41% slight (a breakdown RedMonk analyst Rachel Stephens pulled out of the underlying data in her December 18, 2025 review of the report). Self-reported productivity is the easy number to like. The instability finding is the one that should change what a VP of Engineering actually does with a rollout: DORA's own regression model found that higher individual-level AI adoption predicts higher throughput and higher delivery instability in the same team, not one or the other.
The 30% trust number shows up as a code-review bottleneck
DORA's report states it plainly: "about 30% of our survey respondents trust the output a little or not at all." That's not a footnote about developer sentiment, it's a description of where the extra work goes. Code a reviewer doesn't trust gets read more slowly than code they wrote themselves, and AI tools now produce a lot more of it to read. A senior engineer who used to review three human-written pull requests a day is reviewing more pull requests, each one written by something that a third of the industry, by DORA's own count, still doesn't fully trust. That reviewer isn't shipping faster because AI wrote the code. They're shipping however fast the review queue lets them, and the queue got longer before anyone budgeted for it.
The abandonment number nobody quotes: under 10%
The report's most specific finding involves the newest layer, agentic coding tools that write and commit code with less human involvement per step. In a November 10, 2025 interview about the report, DORA's lead author Nathen Harvey described people who tried a coding agent in their first week of use and were still using it to write code ten weeks later: fewer than 10%. Most teams' honest agentic-adoption story right now is a short trial that quietly stopped, not a rollout. That matters for planning, because a roadmap built on "our engineers will increasingly work through agents" is describing where the industry might land, not where most teams actually are ten weeks after they start.
The seven capabilities that decide which way the amplifier points
Google Cloud's companion piece on the DORA AI Capabilities Model, published December 10, 2025, names seven practices that determine whether AI amplifies a team's strengths or its dysfunctions: a clear and communicated AI policy, a healthy internal data ecosystem, AI-accessible internal documentation and codebases, strong version control discipline, working in small batches, a user-centric focus, and a quality internal platform. Two of those are squarely engineering-management decisions rather than tooling purchases. Small batches means enforcing pull-request size limits so a reviewer is never handed a 2,000-line AI-generated diff and asked to trust it on faith. Version control discipline means frequent commits and a rollback path that actually works, because that's the safety net an amplifier needs under it before it amplifies anything.
A worked example, and what it means for your team
Picture a 60-person Series B company that rolled out an AI coding assistant to its whole engineering org in a single sprint, with no change to how pull requests got sized or reviewed. Throughput looked great for about three weeks: more commits, more merged PRs, a roadmap slide that looked ahead of schedule. Then the on-call rotation started catching incidents nobody on the team could explain in under twenty minutes, because the diffs behind them were larger, less familiar to their own authors, and reviewed at the same pace as before the rollout. Nothing about the AI tool was defective. The team amplified a review process that was already thin, and thin plus faster is thinner, not stronger.
If your incident count crept up after an AI rollout, the fix usually isn't rolling AI back, it's building the version-control and review discipline that should have shipped alongside it: enforced small-batch pull requests, a review SLA that scales with volume instead of staying fixed, and a written AI policy so engineers aren't each deciding on their own how much to trust an agent. That's exactly the kind of gap staff augmentation closes well: one or two senior engineers who've done this before, brought in to harden the practices your existing team doesn't have spare time to build while also shipping the roadmap. It's a weaker fit when the missing piece is the policy decision itself, the "clear, communicated AI stance" DORA names first among its seven capabilities, because that's a call only your own leadership can make; a contractor can help you write it down, not make it for you.
The pattern here isn't new to AI tooling specifically. It's the same gap covered in why AI agents keep failing once they hit production and the same discipline behind building an evaluation harness before you trust a model's output at scale. It's also the other side of the coin from Anthropic's own data on where coding work is shifting from chat to unattended API traffic: that piece shows automation share rising, this one shows what happens to a team's stability when it rises faster than their process can absorb it. If your engineering team is past the pilot stage with AI coding tools and the incident count is the part keeping you up, our Silicon Valley team scopes that conversation before it turns into a bigger hiring decision than it needs to be. Talk to us about where a senior engineer or two, brought in through build-your-team, fits around the practices your rollout is missing.
Sources
- DORA / Google Cloud: Announcing the 2025 DORA Report (published September 23, 2025)
- DORA: State of AI-assisted Software Development 2025
- Google Cloud: From adoption to impact: putting the DORA AI Capabilities Model to work (published December 10, 2025)
- RedMonk: DORA 2025: Measuring Software Delivery After AI (published December 18, 2025)
- Jellyfish: AI as Amplifier: a closer look at the 2025 DORA report with lead author Nathen Harvey (published November 10, 2025)