Applying AI across the full software development lifecycle means using it in requirements, backlog grooming, code review, testing, deployment, and maintenance, not only at the point where a developer writes a line of code.

Over the past two years, I’ve watched engineering leaders adopt AI coding tools without seeing the expected improvement in team delivery. The growing body of research explains why: speeding up coding doesn’t fix bottlenecks elsewhere in the SDLC.

Across DORA’s 2025 report, Faros AI’s 2025 and 2026 telemetry, and Stanford-led research covering more than 100,000 developers, one pattern repeats: AI coding assistance lifts individual output substantially, the gains shrink considerably by the time they reach team and organizational delivery, and delivery stability measurably worsens as adoption deepens. The fix isn’t a better coding assistant. It’s treating AI as an input to the whole delivery system.

The Number Everyone Cites, and the One They Skip

If you’ve read anything about AI and developer productivity in the past year, you’ve probably seen the METR study. In July 2025, METR ran a randomized controlled trial with sixteen experienced open-source developers completing 246 real tasks in repositories they already knew well. The finding traveled fast: developers took 19% longer to finish their work when allowed to use AI tools (confidence interval +2% to +39%), even though they estimated afterward that AI had made them 20% faster. They had predicted a 24% speedup going in.

Here’s the part most blog posts leave out — and METR was upfront about all of it. The study was framed as “a snapshot of early-2025 AI capabilities in one relevant setting,” explicitly not a general claim about software development. METR flagged possible sampling bias: developers who believed AI helped them may have been less likely to sign up in the first place.

When METR expanded the experiment in a follow-up reported in February 2026 (57 developers, 143 repositories, more than 800 tasks) the results moved. Returning developers from the original cohort showed an estimated -18% speedup (CI: -38% to +9%); newly recruited developers showed -4% (CI: -15% to +9%). The point estimates are still negative, but the confidence intervals now comfortably include real speedups, and METR characterizes the result as “some evidence for speedup.”

More importantly, METR found the selection problem had gotten worse, not better: developers increasingly declined to participate rather than work without AI, and 30% to 50% of participants said they chose not to submit certain tasks specifically because they didn’t want to do them without AI. That systematically strips out exactly the work where AI helps most. METR’s own conclusion is worth quoting directly: they “believe it is likely that developers are more sped up from AI tools in early 2026 compared to our estimates from early 2025.”

So the honest read is this: the 19% slowdown figure should not be cited as a current fact about AI coding tools, and METR itself says so. What survives is the perception gap, roughly 39 points between measured and perceived performance in the original trial. That gap matters more to how you plan a modernization program than either headline number does, because it means self-reported AI wins are not a reliable basis for a business case.

Why Coding-Only AI Plateaus: It’s Basic Arithmetic

Here’s a framing I don’t see enough engineering leaders use: writing code is a minority of the work. Sonar’s developer survey puts time spent actually writing or improving code at about 32% of the workweek, with the remainder going to maintenance (19%), testing (12%), security (4%), and roughly a quarter of the week in meetings and operational work. Other time-use studies land in a similar band.

Run that through Amdahl’s Law. If coding is about 30% of delivery time, making the coding step twice as fast improves total throughput by roughly 18%. Even an infinitely fast coding step — free, instantaneous code — caps the improvement at about 43%. Treat those figures as illustrative rather than precise, since share-of-developer-time and share-of-elapsed-delivery-time aren’t the same measure and lifecycle phases overlap in practice. But the shape of the constraint is structural, not a tooling problem. No model improvement changes the denominator.

The 2025 DORA State of AI-assisted Software Development report, based on nearly 5,000 technology professionals surveyed by Google Cloud’s research team, approaches the same question from a different angle. AI adoption is now close to universal: 90% of respondents use it at work, more than 80% believe it has increased their productivity — and 30% report little or no trust in the code it generates.

Two DORA findings deserve more attention than they get. First, the throughput relationship reversed. In 2024, DORA found AI adoption negatively correlated with software delivery throughput. In 2025, that relationship turned positive. Second, the stability relationship did not reverse — AI adoption continues to show a negative relationship with software delivery stability. DORA’s framing is that AI acts as an amplifier, not a fix: teams with strong testing, small batch sizes, and clean version control saw AI amplify those strengths; teams without them saw AI amplify the weaknesses instead.

That reversal is an argument for full-lifecycle thinking, not against it. DORA attributes the improvement to teams learning where, when, and how AI is most useful — an organizational capability, not a model upgrade.

Faros AI’s telemetry work adds the most concrete illustration. Their 2025 analysis covered more than 10,000 developers across 1,255 teams. Individual output climbed sharply under AI adoption — 21% more tasks completed, 98% more pull requests merged — while the study found “no significant correlation between AI adoption and improvements at the company level.” The mechanism was visible in the data: average PR size rose 154% and PR review time rose 91%. The flood of AI-generated code still had to pass through the same human review bottleneck as before.

Their 2026 dataset, expanded to roughly 22,000 developers across 4,000 teams, tells a more nuanced story that’s worth stating plainly rather than flattening: delivery gains in 2026 are real. Task throughput rose 34%, epics completed per developer rose 66%, PR merge rate rose 16%. But the costs scaled faster than the gains. Bugs per developer rose 54% (against 9% the prior year), production incidents per PR roughly tripled, median review time increased about fivefold, and 31% more pull requests merged with no human review at all.

The most rigorous team-level estimate I’ve seen comes from Stanford-led research by Yegor Denisov-Blanch and colleagues, analyzing more than 100,000 developers across hundreds of organizations using models trained to evaluate code complexity and implementation effort rather than raw commit counts. Their median team-level gain: about 10%. The variance is the real finding — roughly 30-35% on greenfield, low-complexity work, but only 5-10% on complex brownfield codebases, with some teams measuring net-negative productivity. One organization in their dataset posted a 14% increase in pull requests alongside a 2.6x increase in rework and a 9% decline in code quality.

One caveat on all of it: apart from METR’s controlled trial, this is correlational survey and telemetry data. It establishes that these patterns travel together at scale, not that AI adoption causes each effect in a given organization. Use it to frame the questions you ask about your own pipeline, not as a substitute for measuring it.

What “Full SDLC” Actually Means in Practice

None of this is an argument against AI in engineering. It’s an argument against stopping at the coding step. Applying AI across the full lifecycle means:

• Requirements and backlog. Using AI to translate business requirements into structured, testable backlog items, catching ambiguity before it becomes a mid-sprint blocker.
• Code review. Using AI to triage and pre-screen pull requests so human reviewers spend their attention on architectural and logic risk rather than formatting and boilerplate. Review capacity is the bottleneck the Faros data points to most directly — a 5x increase in median review time and a 31% rise in unreviewed merges are the same problem seen from two sides.
• Testing. Generating and maintaining test coverage alongside the code itself, rather than treating tests as a follow-on task that lags behind AI-accelerated development. This is also DORA’s “fortify your safety nets” capability in practical terms.
• Deployment and CI/CD. Extending automation into release pipelines so a faster coding stage doesn’t simply create a queue in front of a slower deployment stage.
• Maintenance. Using AI-assisted code analysis to understand and refactor legacy systems, which is where most enterprise technical debt actually lives. The classic estimate — Robert Glass’s Facts and Fallacies of Software Engineering — puts maintenance at 40% to 80% of total software cost, averaging around 60%. That research predates the AI era, and current data suggests the problem is getting worse, not better: GitClear’s analysis of 623 million code changes from 2023 to 2026 found refactoring activity collapsing to 3.8% of changed lines (from 21% in 2022) while block duplication rose 81%. Maintenance is precisely the stage coding assistants touch least, and the stage AI-accelerated output loads most heavily.

The common thread is that each of these is a systems intervention, not a tool swap. That distinction is also DORA’s explicit recommendation: their AI Capabilities Model identifies seven foundational capabilities — among them working in small batches, strong version control practices, quality internal platforms, connecting AI to internal context, and a user-centric focus — that determine whether AI adoption amplifies performance or amplifies dysfunction. Buying a coding assistant without addressing those foundations optimizes roughly a third of the work that was never the actual bottleneck.

The Question Worth Asking Before Your Next AI Investment

If your organization has already adopted a coding assistant and the results haven’t shown up in delivery speed, cycle time, or throughput at the team or organizational level, the tool isn’t necessarily the problem. The question worth asking is where in the lifecycle the AI investment stopped, and whether review capacity, test coverage, deployment automation, and legacy code maintenance were part of the plan or an afterthought.

That’s the conversation we have with engineering and IT leaders before recommending any specific tool or rollout plan. It starts with an honest assessment of where your current bottlenecks actually sit, because the research above makes one thing clear: intuition and self-reported productivity are not reliable guides on their own.

Frequently Asked Questions

Does applying AI across the SDLC mean replacing our current coding assistant?

No. Coding assistants remain a legitimate and valuable part of the lifecycle. The point is that coding occupies roughly a third of developer time, so a coding assistant alone has a mathematical ceiling on what it can contribute. Pairing it with AI-assisted review, testing, and maintenance is what determines whether the gains show up in organizational throughput.

Why did our team feel faster with AI but our delivery metrics didn’t move?

Where studies have measured both perception and performance, self-reported gains have consistently exceeded measured ones. METR’s 2025 trial found a roughly 39-point gap between the two. DORA’s 2025 survey found more than 80% of respondents believed AI increased their productivity, and Faros AI’s telemetry shows individual output metrics rising far faster than organizational delivery metrics. Measured delivery outcomes are a more reliable signal than individual sentiment.

Is AI making software delivery less stable?

DORA’s 2025 research found that AI adoption continues to show a negative relationship with software delivery stability, even as its relationship with throughput turned positive. Faros AI’s 2026 telemetry found production incidents per pull request roughly tripling and bugs per developer rising 54%. These are correlations rather than proven causation, and DORA’s interpretation is that AI amplifies whatever engineering discipline — or lack of it — already exists in the pipeline, rather than causing instability directly.

Has the research settled whether AI coding tools make developers faster?

Not precisely, and anyone claiming otherwise is overselling. METR’s widely cited 19% slowdown was a narrow early-2025 snapshot that METR has since partially walked back, citing selection effects and stating that developers are likely more sped up now. Stanford’s work puts the median team-level gain near 10%, with wide variance by codebase complexity. The reliable conclusion isn’t a single number — it’s that the gains are real, smaller than they feel, and highly dependent on where in the lifecycle you apply them.

Where should we start if we want to apply AI across the full lifecycle rather than just coding?

Start with an assessment of where your actual bottleneck sits today: requirements clarity, review capacity, test coverage, deployment speed, or legacy maintenance burden. The right starting point is different for every organization, and it’s rarely the coding step itself.