Quick Answer: DORA reports no fixed cut in release cycle time: its 2024 report tied a 25% rise in AI adoption to 1.5% lower delivery throughput. Its 2025 report found AI in software development now tracks higher throughput, yet still raises instability without strong automated testing, mature version control and fast feedback loops. Faster coding doesn't reach releases on its own.
Most teams feel faster soon after adopting AI coding tools. Whether releases reach production sooner is a separate question, and Google's DORA research program answers it with a trade-off, not a single percentage.
The pattern is consistent across studies: AI speeds up writing code, the bottleneck moves to review, testing and deployment, and teams without solid delivery basics give part of the gain back as failed changes and rework.
How much can AI reduce release cycle time?
There is no dependable single number. Controlled studies of one coding task report large speedups, an early-2025 field study reported a slowdown, and DORA's survey data shows small delivery effects that depend on practice.
What the primary sources measured:
- GitHub, 2022 controlled experiment: 95 professional developers wrote an HTTP server in JavaScript. GitHub's Copilot research found the Copilot group finished 55% faster (1h 11m against 2h 41m).
- METR, early-2025 randomized trial: 16 experienced open-source developers worked 246 real issues in their own repositories and took 19% longer with AI tools, though they expected a 24% speedup and afterwards believed they were 20% faster. METR said in February 2026 that it believes these early-2025 results no longer reflect current AI tools, and that developers are likely sped up more today.
- DORA, 2024 report: a 25% increase in AI adoption was associated with an estimated 1.5% decrease in delivery throughput and a 7.2% reduction in delivery stability.
- DORA, 2025 report: AI adoption now has a positive relationship with delivery throughput, but still a negative relationship with delivery stability.
A single task can get much faster while the release cycle barely moves. DORA measures change lead time from commit to production, so faster typing only shortens it when review, tests and deployment keep pace. That gap is the central finding on AI in software development so far.
What do DORA metrics show about AI-assisted delivery?
DORA's 2025 report, drawn from nearly 5,000 technology professionals, found that AI adoption is now positively associated with software delivery throughput, reversing the 2024 result, while still raising instability. Its summary is that AI amplifies whatever delivery system it lands in.
The 2025 DORA report announcement adds three figures on how teams relate to the tools:
- 90% of respondents use AI at work.
- More than 80% believe AI has increased their productivity.
- 30% report little or no trust in the code AI generates.
The 2024 numbers explain where the time goes. In the 2024 DORA report announcement, a 25% rise in AI adoption tracked a 7.5% gain in documentation quality, a 3.4% gain in code quality and 3.1% faster code review. Those are upstream wins. Throughput and stability still fell; DORA's reading is that delivery doesn't improve without basics like small batch sizes and robust testing.
DORA's 2025 explanation names the missing controls: strong automated testing, mature version control practices and fast feedback loops. Teams with loosely coupled architecture saw gains; tightly coupled teams saw little. For anyone planning an AI SDLC rollout, the implication is that the delivery pipeline decides the outcome, not the model.
Which SDLC stages gain the most from AI?
Coding and documentation gain first, because AI output lands there directly. Review, testing and release gain only when they are automated enough to absorb more change volume. Ops gains least in cycle time, but it is where instability shows up.
| SDLC stage | Typical AI use | Delivery metric it moves | What to watch |
|---|---|---|---|
| Planning | Drafting specs, splitting work into small tickets | Batch size, and so change lead time | Large AI-drafted scopes that inflate batches |
| Coding | Code completion, boilerplate, test scaffolds | Time to first commit | Larger diffs per change |
| Review | Summaries, first-pass checks before a human | Review wait inside change lead time | Reviewers rubber-stamping unfamiliar code |
| Testing | Generating unit and integration tests | Change fail rate | Tests that assert what the code does, not what it should do |
| Release | Release notes, pipeline config, rollout checks | Deployment frequency | Bigger releases hiding more risk |
| Ops | Incident summaries, log triage, runbooks | Failed deployment recovery time, rework rate | Recovery skills fading as AI drafts fixes |
That's why AI assisted software development often feels faster than it measures: the first rows speed up at once, the middle rows need investment first.
What do AI-augmented engineering teams do differently?
Teams that turn AI speed into shorter release cycles treat AI as a change-volume multiplier and harden the stages downstream of the editor first. They keep batches small, automate checks at the author's desk, and connect AI to their own codebase and documentation.
DORA's guidance recommends these practices:
- Small batches, enforced. AI makes large changes cheap to write. Keeping pull requests small is what lets review and deployment keep up.
- Automation at the author. Linting, tests and AI checks run before a pull request opens, so the reviewer sees cleaner changes.
- Context over tool count. AI tools connected to the team's codebase and docs reduce integration friction, and fewer tools means less decision toil.
- Senior review of AI decisions. Junior engineers pair with seniors who review AI-generated architectural decisions.
The engineers stay the same; AI augmented software development adds guardrails around them, not headcount.
How do you adopt AI in the SDLC without hurting stability?
Adopt it in an order consistent with DORA's findings: fix test automation and batch size first, then widen AI use in coding, then track change fail rate and rework rate alongside throughput. Stability metrics are the early warning that throughput gains are borrowed.
- Audit the pipeline before the tools. If a normal change waits a day for review or a flaky test suite, AI code will wait there too.
- Start with one team and one service. A contained rollout gives a clean comparison against teams that haven't changed.
- Set review rules for AI-written code. Size limits, required tests and a named human owner for every merged change.
- Measure throughput and instability together. A rise in deployment frequency with a rising change fail rate is not a win.
- Expand only when both hold. Widen AI for software engineering to more teams once the pilot team's stability metrics are flat or better.
How do you set a baseline before measuring AI's effect on delivery?
Record DORA's five delivery metrics before AI use changes, over enough deployments to show normal variation. Without that baseline, any later improvement is anecdote.
The DORA metrics guide splits the five into two groups:
- Throughput: change lead time, deployment frequency and failed deployment recovery time.
- Instability: change fail rate and deployment rework rate.
Pull them from version control and deployment logs, not surveys, since METR's early-2025 trial showed that developers' sense of speed can point the wrong way. Keep a comparison group, log other process changes, and read results per service, because an AI SDLC effect averaged across codebases hides the teams it hurts.
What mistakes should you avoid when adding AI to the software development lifecycle?
The costly mistakes all measure the wrong thing or skip the downstream work.
- Counting lines or pull requests. More code is not more delivery. Track lead time and change fail rate instead.
- Trusting self-reported speed. Surveys capture how fast work feels, which can differ from how fast it is.
- Rolling out to everyone at once. You lose any comparison group and can't separate AI's effect from everything else that changed.
- Leaving review as it was. Faster authoring with the same review process moves the queue, not the finish line.
- Merging tool cost into the speed question. Spend is a separate calculation; the ROI of AI coding tools needs its own model.
How Origins AI runs AI-augmented engineering teams
Origins AI (originshq.com) is a US-based AI-augmented engineering company that embeds engineers with product teams and builds custom AI workflows and agents. Its homepage reports 2x faster releases, which it attributes to an AI-augmented SDLC; treat that as a company claim, not an independent benchmark.
The faster product launch page describes the method as AI-augmented development, parallel workflows and continuous delivery pipelines, with AI agents handling code generation, automated testing and continuous quality checks. Its AI code generation page lists APIs, CRUD endpoints and tests as the work it generates.
Engagements run as dedicated teams, project-based work, time-and-materials or build-operate-transfer, per the company's AI development services page. Origins AI does not publish a rate card. If you're evaluating a partner on release speed, ask for their before-and-after DORA metrics on a comparable service, not only a headline multiple.
Talk to an engineer
Want your release cycle measured before and after AI adoption? Book a call with an engineer to review your delivery metrics.
Written by Apoorva Kumar, Co-Founder & CEO, Origins AI.