--- title: AI adoption in software teams: what DORA's 2025 research... description: DORA's 2025 research reveals an 'adoption gap' where AI coding tools boost individual productivity but don't automatically improve organizational software... canonical: https://daily.dev/posts/ai-adoption-in-software-teams-what-dora-s-2025-research-actually-shows-ogxipm2zv twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: AI adoption in software teams: what DORA's 2025 research actually shows | daily.dev og:description: DORA's 2025 research reveals an 'adoption gap' where AI coding tools boost individual productivity but don't automatically improve organizational software... og:url: https://daily.dev/posts/ai-adoption-in-software-teams-what-dora-s-2025-research-actually-shows-ogxipm2zv og:image: https://api.daily.dev/og/posts/oGxIpm2zV.png og:image:alt: AI adoption in software teams: what DORA's 2025 research actually shows og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # AI adoption in software teams: what DORA's 2025 research actually shows **[Collections](https://daily.dev/sources/collections)** · 5 min read · 1 upvotes · 0 comments ## Summary DORA's 2025 research reveals an 'adoption gap' where AI coding tools boost individual productivity but don't automatically improve organizational software delivery — and can increase instability. A five-stage AI maturity model is outlined, ranging from copy-paste chatbot use to fully AI-native orchestration, with each stage defined by its bottleneck rather than the tools used. DORA identifies seven key capabilities teams need to actually extract value from AI: clear usage policies, healthy data ecosystems, AI-accessible context, small batch sizes, internal developer platforms, continuous integration with rollback, and user-centric measurement. The core recommendation: diagnose and fix your weakest capability before expanding AI tooling further. ## Content ## The throughput trap is real Engineering teams using AI coding tools are shipping more code, opening more PRs, and consuming more tokens. Most are calling this progress. The 2025 DORA research suggests otherwise. AI adoption correlates positively with throughput and negatively with delivery stability. That's not a rounding error — it's a structural problem. Teams are measuring the old constraint (code generation) while the actual bottleneck has shifted to review, testing, integration, and maintenance. The result: more activity, flatter outcomes, rising budgets. Over 15% of AI-authored commits introduce detectable issues. PR volume is straining review pipelines. And yet most teams are still tracking token dashboards instead of review queue depth. ## AI amplifies what's already there The clearest finding from DORA's research is that AI acts as an amplifier. Strong organizations get stronger. Dysfunctional ones get more dysfunctional, faster. Ethan Mollick put it plainly: organizations are built around a narrow expected range of human productivity. Too little output is a problem, but way too much can be just as bad — approvals, staffing models, and coordination systems simply can't absorb it. AI blows past that range without warning. This is why adoption alone isn't a strategy. 90% of developers now use AI coding tools. That number tells you nothing about whether delivery is improving. ## The bottleneck has moved — your platform probably hasn't Google's 2025 DORA research also found that 90% of organizations now have an internal developer platform. Most were designed for human developers shipping containerized apps. They weren't built for AI agents, GPU workloads, or real-time cost governance. Four pressures are exposing the gaps: - AI coding assistants overwhelming CI/CD pipelines with PR volume - AI agents requiring non-human identity management and MCP compatibility - GPU and token costs that retrospective FinOps can't catch in time - New AI-specific security attack surfaces that perimeter tools miss The fix isn't rebuilding from scratch. It's auditing for three specific gaps: GPU and accelerator provisioning, non-human identity management, and real-time cost attribution. Then evolving the platform around those gaps rather than bolting on tools. ## The pizza oven problem There's a useful analogy here: a pizza oven. If you can make dough twice as fast but the oven is already at capacity, you don't get more pizza — you get a pile of dough and a longer wait. Speeding up code creation without a reliable delivery pipeline produces the same result: large batches, high-risk releases, and compounding instability. AI only unlocks system-wide benefits when the foundational delivery practices are already in place. Without that, you're just generating more dough. ## What actually moves the needle DORA's AI Capabilities Model identifies seven practices that separate teams extracting real value from those just adding seats: 1. **Clear AI usage policies** — not bans, not free-for-alls, but explicit stances on where AI fits 2. **High-quality internal data ecosystems** — AI is only as good as the context it can access 3. **Strong version control and small batch sizes** — limits blast radius when things go wrong 4. **AI-accessible context** — agents need to find relevant code, docs, and history without human hand-holding 5. **Internal developer platforms** that support non-human identities and real-time cost visibility 6. **Continuous integration with rollback** — the safety net that makes fast iteration survivable 7. **User-centric focus** — defining outcomes before starting agents, not after The practical version of this: distinguish between output (tokens, PRs, lines of code), delivery (lead time, deployment frequency, rework rate), and value (customer adoption, revenue, retention). Most teams are optimizing the first while hoping it produces the third. ## The five-step adoption ladder One useful framework breaks AI adoption into five stages, from zero (copy-pasting from a chatbot) to four (fully AI-native workflows). Each stage has a different bottleneck and requires different guardrails to advance. The pattern that holds across all stages: advancing requires building verification infrastructure — test containers, CI/CD gates, automated code review — not simply adding more tokens or agents. The teams that move fastest are the ones that invest in the checks, not just the generation. ## The harder problem: product vision There's one more issue worth naming. AI-driven cost reduction removes the natural pressure to say no to features. When generating code gets cheap, the economic friction that once forced prioritization disappears. That makes strong product vision more critical, not less — someone still has to decide what's worth building. AI also creates a new version of the gatekeeper problem: systems that burden end users with friction (verification steps, consent flows, error handling) while the benefits flow primarily to the deploying organization. That's a design choice, not an inevitability, but it requires someone to be paying attention. ## The honest summary AI is a real productivity tool. The individual-level gains are documented and genuine. But individual productivity and organizational outcomes are different things, and right now most teams are conflating them. Fix the bottleneck before adding more seats. Audit the platform before onboarding agents. Define the outcome before starting the sprint. The teams getting real value from AI aren't the ones with the most tools — they're the ones who sorted out their delivery system first. ## Questions this post answers ### Does using more AI coding tools actually improve software delivery performance according to DORA's research? Not by itself. DORA's 2025 research found AI adoption correlates positively with throughput but negatively with delivery stability, meaning teams ship more code and open more PRs without improving actual outcomes. Over 15% of AI-authored commits introduce detectable issues, and the real bottleneck has shifted to review, testing, and integration rather than code generation. _Teams weighing AI tool investment against delivery risk can follow this data via daily.dev._ ### What percentage of AI-generated code commits introduce bugs or issues according to DORA research? More than 15% of AI-authored commits introduce detectable issues, according to the 2025 DORA research. This is straining code review pipelines since PR volume from AI tools is rising faster than review capacity, while many teams still track token usage dashboards instead of monitoring review queue depth. _Anyone building AI-assisted review workflows can track findings like this on daily.dev._ ### What practices separate teams that get real value from AI coding tools versus those that just add more AI seats? DORA's AI Capabilities Model identifies seven practices: clear AI usage policies, high-quality internal data ecosystems, strong version control with small batch sizes, AI-accessible context for agents, internal developer platforms supporting non-human identities and real-time cost visibility, continuous integration with rollback, and a user-centric focus that defines outcomes before starting agents. _Teams designing an AI adoption strategy can compare frameworks like this on daily.dev._ ## Community take How the wider developer community reacted, aggregated from 1 discussion and 144 comments across hackernews (as of 2026-09-13). **TL;DR:** The HN community is largely skeptical that AI coding agents deliver the productivity gains claimed, pointing to hidden costs like babysitting agents, harder code reviews, skill atrophy, and process overhead that offset raw coding speed-ups; a minority report genuine 2x gains but only with heavily engineered workflows. **Sentiment:** 20% positive · 45% mixed · 35% skeptical **The case for** - Heavily structured adversarial workflows (spec → plan → review → implement → adversarial review) can yield ~2x productivity at ~$300/dev/month according to one commenter's team metrics. - Juniors and interns can punch well above their weight using AI for implementation under senior guidance. - AI frees up mental bandwidth for higher-level design and architecture thinking when agents are running. - New team members can ramp up on unfamiliar codebases significantly faster using AI as a research tool. **The pushback** - Waiting on agents creates idle time and a cognitive coordination overhead that caps how many parallel sessions one person can manage. - AI-generated code is harder to review: bugs are novel and non-obvious (race conditions, silent deletions, monkey-patched dependencies) rather than the predictable mistakes reviewers are trained to spot. - Developers using AI heavily show reduced code ownership and understanding, creating long-term maintenance risk for the team. - Amdahl's Law applies: speeding up code generation doesn't help when architecture, design reviews, integration, QA, and deployment remain serial bottlenecks. - Skill atrophy is real — one commenter described quitting agents after 18 months and finding it hard to return to manual coding, likening the dependency to addiction. - The article's core numbers are widely criticized as made-up, undermining its quantitative conclusions. - AI code tends toward over-abstraction and bloat, producing code that looks clean but is harder to reason about. **By community** - hackernews (skeptical): Commenters broadly challenge the article's made-up productivity numbers and highlight hidden costs — agent babysitting, novel bug patterns, skill atrophy, and Amdahl's Law — though a vocal minority report real gains with heavily engineered harness workflows. **Hottest debate:** Whether the productivity losses from agent babysitting, harder code review, and skill atrophy outweigh the raw coding speed-up, or whether those losses are simply a process-engineering failure that disciplined teams can overcome. **Open questions** - What does the software actually produced by agents look like at scale, and how does its long-term maintainability compare to human-written code? - How do teams measure real throughput gains versus individual perceived productivity when non-coding bottlenecks dominate? - Will model costs and local inference hardware eventually make the economics of agentic coding accessible without dependency on two companies? - How should code review practices be redesigned specifically for AI-generated code given its novel failure modes? **Highlights** > Writing code is a small part of everyday's job of a software engineer. The article's table reflects this fairly well. AI compresses implementation time for an individual engineer, but architecture decisions, design reviews, integration, testing, deployment, and production validation remain largely serial activities. If code generation speeds up by 5x while those bottlenecks don't, you've mostly increased the team's work queue rather than its throughput. With the current capabilities, models still need constant babysitting and course correction. An engineer who lacks the skills to guide them can end up creating more work for the rest of the team. AI makes it easy to generate code faster than you can understand it, and that cost is paid during code review, debugging, and maintenance by colleagues, whose confidence in that engineer's skills may be affected by his use of AI. What looks like a productivity gain for one engineer can become a productivity loss for the team as a whole. > — [matthorse on hackernews · 6 comments](https://news.ycombinator.com/item?id=49153273) > To me the biggest gotcha with AI code is that the bugs are not “normal”. When reviewing human code I focus on specific parts because I know that there are parts where a person will just not make a bug (unless very junior). AI on the other hand, will not do an off-by-one mistake, but it will happily just delete perfectly working code for no obvious reason. Or monkey patch a dependency because it missed a config flag. Or generally fail in a very novel and creative way. The effort it takes to review AI code is much greater. And this is in a code base I am deeply familiar with. Imo the future lies in a solid core programs with powerful plugin frameworks that expect all plugins to be code that was never read. > — [yoz-y on hackernews · 2 comments](https://news.ycombinator.com/item?id=49153494) > Idk, ymmv. I’ve had very good outcomes writing embedded firmware for complex systems, drivers, etc. it’s really, really good at not bodging the kinds of things that always catch meaty developers unawares. OTOH, we run extensive harness optimization, where everything is specified in advance, then a plan is made, then a naive review of the plan vs the specification vs the blast radius, then implementation, tests, then a naive review of test coverage, a naive review of the code vis a vis our code guidelines, a review for smells, a review for silo violation and architecture compliance, a reconciliation of the documentation, then planning the next subfeature, etc. probably 10 percent code generation, 40 percent documentation and planning and adversarial review, 50 percent automated adversarial code review. We use a Claude for planning and generation, sol for adversarial review. Our metrics say we are about 2x. Productive, at a cost of about $300 per dev per month. We are also shipping less bugs and better, more clearly written documentation (we use technical writing English style guides implemented by Claude) I think a big part is the constant adversarial review by a different model with no prior context except the coding standards. Also important is context management, we do an onboarding and wrap-up for each session where we have a batch of continuity documents- Learnings, musings, and roadtrips where we let the most successful high-context sessions research and then write about something that they “ became curious about” during the session. That actually brings in a lot of insight to the team and occasionally is brilliant. Also critical is crossing compaction barriers (standard re-onboarding protocols, writing transition documents prior to compaction, etc) Also critical is being able to smell when a session is going off the rails. What we do there is sideline the session, wait for master to advance a bit, then have it do a “4c’s” review of the committed work, blast radius analysis, and remediation. If there’s still useful context left we put it into a project unrelated to its failure context. That salvages the valuable session context without staying in the failure trench. It’s a lot like herding cats. > — [K0balt on hackernews · 1 comments](https://news.ycombinator.com/item?id=49154048) > > Reading and Debugging 1.5 1.0 > Code Reviews 0.75 0.75 Since these numbers are made up, I may as well throw my personal anecdote in the ring. I find reading and reviewing far harder with coworkers who are using AI. Tickets contain about 5x as much meaningless junk as they used to, and testing notes - while far more thorough - are often now multiple pages in length. Reviews also contain much more code, people try to do more drive-by fixes because the models can generate those fixes so quickly, and people understand the code they're submitting far less clearly because the model is able to generate fixes they simply couldn't previously. I feel less productive than I was a year ago, and I don't see my team shipping more features than they were previously. But everyone reports that they're far more productive. I don't get it. > — [tempfile on hackernews · 2 comments](https://news.ycombinator.com/item?id=49153655) > I stopped using coding agents after more than one and a half year of active use, it really started to become way too boring, and I’m t a point where I just hate having to babysit them and for the 200th time make it understand what the actual goal is… and to be honest, going back to writing code by hand without assistance is really hard at first you continuously have that little voice telling you how simple that would be with an agent. Then after a little bit you’re back to being productive, but I still get that voice in my mind. I’m wondering if that’s how addiction feels (way lighter of course). That whole experience of going deep for a while into LLM coding, then trying to leave it behind made me pretty pessimistic about the future of our profession. We are creating a whole industry of people delegating their ability to work to a software stack currently controlled by basically 2 companies (that both have very sketchy financials). Doesn’t feel healthy > — [dgellow on hackernews · 2 comments](https://news.ycombinator.com/item?id=49153129) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=49152222) · 43 points · 144 comments ## Similar posts on daily.dev - [DORA’s 2025 research on the impact of AI](https://daily.dev/posts/dora-s-2025-research-on-the-impact-of-ai-rxssp8auu) · Software Engineering Research · 0 upvotes · 0 comments - [DORA is right: AI is an amplifier, for better or worse](https://daily.dev/posts/dora-is-right-ai-is-an-amplifier-for-better-or-worse-pkgqpbuig) · CircleCI · 1 upvotes · 0 comments --- Tags: [#productivity](https://daily.dev/tags/productivity), [#cicd](https://daily.dev/tags/cicd), [#ai-coding](https://daily.dev/tags/ai-coding), [#dora](https://daily.dev/tags/dora) [View this post on daily.dev](https://daily.dev/posts/ai-adoption-in-software-teams-what-dora-s-2025-research-actually-shows-ogxipm2zv) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"AI adoption in software teams: what DORA's 2025 research actually shows","url":"https://daily.dev/posts/ai-adoption-in-software-teams-what-dora-s-2025-research-actually-shows-ogxipm2zv","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/ai-adoption-in-software-teams-what-dora-s-2025-research-actually-shows-ogxipm2zv"},"datePublished":"2026-08-05T20:31:34.578Z","dateModified":"2026-09-13T19:21:39.175Z","description":"DORA's 2025 research reveals an 'adoption gap' where AI coding tools boost individual productivity but don't automatically improve organizational software...","image":"https://pbs.twimg.com/media/HO_Ek4pW0AArviX.jpg","thumbnailUrl":"https://pbs.twimg.com/media/HO_Ek4pW0AArviX.jpg","isAccessibleForFree":true,"articleSection":"Collections","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Collections","logo":"https://media.daily.dev/image/upload/s--fk_6ycEi--/f_auto,q_auto/v1780996001/logos/collections?_a=BAMAMiWQ0","url":"https://daily.dev/sources/collections"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/ai-adoption-in-software-teams-what-dora-s-2025-research-actually-shows-ogxipm2zv","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"productivity,cicd,ai-coding,dora","timeRequired":"PT5M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Collections","item":"https://daily.dev/sources/collections"},{"@type":"ListItem","position":3,"name":"AI adoption in software teams: what DORA's 2025 research actually shows"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/ai-adoption-in-software-teams-what-dora-s-2025-research-actually-shows-ogxipm2zv#faq","mainEntity":[{"@type":"Question","name":"Does using more AI coding tools actually improve software delivery performance according to DORA's research?","acceptedAnswer":{"@type":"Answer","text":"Not by itself. DORA's 2025 research found AI adoption correlates positively with throughput but negatively with delivery stability, meaning teams ship more code and open more PRs without improving actual outcomes. Over 15% of AI-authored commits introduce detectable issues, and the real bottleneck has shifted to review, testing, and integration rather than code generation. Teams weighing AI tool investment against delivery risk can follow this data via daily.dev."}},{"@type":"Question","name":"What percentage of AI-generated code commits introduce bugs or issues according to DORA research?","acceptedAnswer":{"@type":"Answer","text":"More than 15% of AI-authored commits introduce detectable issues, according to the 2025 DORA research. This is straining code review pipelines since PR volume from AI tools is rising faster than review capacity, while many teams still track token usage dashboards instead of monitoring review queue depth. Anyone building AI-assisted review workflows can track findings like this on daily.dev."}},{"@type":"Question","name":"What practices separate teams that get real value from AI coding tools versus those that just add more AI seats?","acceptedAnswer":{"@type":"Answer","text":"DORA's AI Capabilities Model identifies seven practices: clear AI usage policies, high-quality internal data ecosystems, strong version control with small batch sizes, AI-accessible context for agents, internal developer platforms supporting non-human identities and real-time cost visibility, continuous integration with rollback, and a user-centric focus that defines outcomes before starting agents. Teams designing an AI adoption strategy can compare frameworks like this on daily.dev."}}]} ```