Why Is AI Adoption Hurting Software Delivery Performance Despite Productivity Gains?

AI adoption is raising individual productivity but eroding software delivery stability because organizations are generating larger code batches without tightening the feedback loops that catch defects. The 2024 DORA report found that a 25% increase in AI adoption is associated with a 7.5% increase in documentation quality, a 3.4% increase in code quality, and a 3.1% increase in code review speed, while delivery stability falls by an estimated 7.2% and delivery throughput falls by an estimated 1.5% source. The issue is not that the models are too weak. It is that the operating model has not changed to absorb the extra output. Teams ship bigger changes, review them faster, and discover failures later in the cycle. A software factory reverses this by enforcing small batches, standing evaluations at handoff seams, and senior human oversight on every production change.

Why does AI make software delivery less stable?

The 2024 DORA research shows a paradox that engineering leaders need to understand. On one hand, AI is helping developers feel more productive, spend more time in flow, and feel more satisfied with their jobs. More than 75% of respondents said they rely on AI for at least one daily professional responsibility, and over one-third reported moderate to extreme productivity gains source. The most common uses are writing code, summarizing information, explaining unfamiliar code, and documenting code, all tasks that sit early in the software lifecycle.

On the other hand, those same gains do not flow downstream. The report estimates that every 25% increase in AI adoption reduces delivery stability by 7.2% and delivery throughput by 1.5% source. Delivery stability is measured by change failure rate and rework rate. When these go up, teams spend more time fixing production incidents instead of building new value. The productivity illusion holds until a failed deployment forces the team to stop everything and recover.

Trust is another warning signal. Despite broad adoption, 39% of respondents reported little to no trust in the quality of AI-generated code source. Developers are using the output, but they know it needs scrutiny. The problem is that the scrutiny is happening inside the editor, not inside the delivery pipeline. Speed at the keyboard does not translate to speed through the merge gate.

What is the batch-size trap?

DORA offers a clear hypothesis for the stability drop. Because AI lets developers produce far more code in the same amount of time, changelists are likely growing in size. DORA has consistently shown that larger changes move more slowly and are more prone to creating instability. The 2024 report repeats the warning: improving the development process does not automatically improve software delivery when teams forget the basics of small batch sizes and robust testing source.

The batch-size trap works in three stages. First, a developer uses an AI assistant to generate a feature in hours instead of days. Second, the larger change still passes a code review because AI also speeds up review formatting and documentation. Third, the change reaches production with more surface area and less real-world validation, so failures are discovered by users instead of by tests. Each stage looks like a productivity win until the incident review.

The same pattern appears in platform engineering. DORA found that internal developer platforms increase individual productivity by 8% and team performance by 10%, but they also reduce throughput by 8% and change stability by 14% source. The common thread is adding automation without adding feedback. Any tool that accelerates creation without accelerating verification eventually creates a backlog of rework.

How do high-performing teams avoid the AI delivery trap?

The DORA findings are sobering, but they are not a verdict against AI. A 2025 McKinsey study of nearly 300 publicly traded companies found that the highest-performing AI-driven software organizations saw 16 to 30 percent improvements in team productivity, time to market, and customer experience, plus 31 to 45 percent improvements in software quality source. The gap between top and bottom performers was 15 percentage points. The difference is not the model. It is how the work is organized.

Top performers embed AI across the entire product development lifecycle rather than limiting it to isolated coding tasks. They are six to seven times more likely than peers to scale to four or more use cases, from design and coding through testing, deployment, and adoption tracking source. They also create AI-native roles. Product managers spend more time on design, prototyping, quality assurance, and responsible AI governance, while engineers focus on full-stack fluency, structured specs, and architectural trade-offs source.

The McKinsey research names three enablers that separate the leaders from the rest. First, upskilling: 57% of top performers use hands-on workshops and one-on-one coaching, compared with 20% of bottom performers. Second, impact measurement: top performers track outcomes such as quality improvements and speed gains, while bottom performers focus on adoption metrics alone. Third, change management: nearly eight in ten top performers link AI-related goals to performance reviews, compared with just 10% of bottom performers for developers source.

What is a software factory and why does it matter?

A software factory is an operating model that treats delivery as a repeatable system instead of a heroic craft exercise. It combines autonomous AI agents, standardized pipelines, and senior human oversight so that every change moves through the same small-batch, evaluated, observable path. This is the model xSquad uses to ship production code in 48 hours with senior human review at every seam.

The factory pattern is not about replacing engineers. It is about removing the friction that turns AI productivity into delivery instability. Where a typical team uses AI to write more code and then hopes a human review catches everything, a factory splits work into batches that are small enough to reason about, tests each batch against a standing evaluation suite, and escalates uncertain cases to human experts before they reach production. This mirrors the seam-targeting pattern that Stravoris identified in production agent deployments: agents succeed when they are placed at bounded handoff points with explicit confidence thresholds and human escalation paths source.

The contrast with artisan-style development is useful. McKinsey describes two human-AI patterns: the factory pattern for predictable, routine processes, and the artisan pattern for work that requires human judgment and ingenuity source. Most enterprises need both. The mistake is running factory-speed AI inside an artisan workflow, which is exactly what happens when a developer generates a week of code in an afternoon and then waits days for a review.

If delivery predictability is slipping, the root cause is usually that the operating model has not caught up with the tool. Our post on delivery predictability explains how small batches and clear feedback loops turn unstable releases into reliable shipping. A coding factory applies the same logic at scale by embedding evaluation and human checkpoints into the pipeline itself.

Where should leaders reinvest AI productivity gains?

The DORA research includes a counterintuitive finding that explains where the productivity gains go. AI adoption increases individual flow, productivity, and job satisfaction, but it also reduces the percentage of time developers spend on work they consider valuable source. DORA calls this the vacuum hypothesis: AI helps people finish valuable tasks faster, but the freed time is filled with more meetings, coordination, and toil rather than deeper engineering work.

Leaders who want to capture AI value should close this vacuum deliberately. The reinvestment priorities are clear from the research. First, tighten feedback loops. DORA emphasizes that continuous integration, working in small batches, and test automation become even more critical as AI-generated code increases source. Second, measure outcomes, not adoption. The McKinsey high performers track quality and speed gains, while the rest count tool usage source. Third, stay user-centric. The 2023 DORA report found that user-centered teams had 40% higher organizational performance, and the 2024 report confirms that focusing on the user increases productivity and reduces burnout source.

A software factory makes these reinvestments automatic. Time saved by AI is not pocketed as slack. It is redirected into automated testing, smaller releases, and direct user feedback. The result is not just faster coding but faster, more stable delivery. For enterprises stuck in the pilot-to-production gap, this operating-model shift is the missing link. Our post on AI-native operating models describes how agent factories convert speed at the keyboard into speed across the business.

How large is the delivery stability drop?

DORA estimates that a 25% increase in AI adoption is associated with a 7.2% reduction in delivery stability and a 1.5% reduction in delivery throughput source. Stability is measured by change failure rate and rework rate.

Does AI improve code quality?

Yes. The same DORA analysis estimates that a 25% increase in AI adoption is associated with a 3.4% increase in code quality, a 7.5% increase in documentation quality, and a 3.1% increase in code review speed source. The gains are real; they just do not automatically reach production unless the delivery system is redesigned.

What is the batch-size hypothesis?

DORA hypothesizes that AI increases the amount of code a developer can produce, which leads to larger changelists. Larger changes are slower to review, harder to test, and more likely to fail in production source. The fix is not a better model. It is smaller batches and stronger feedback loops.

Are the DORA findings a reason to stop using AI?

No. DORA explicitly recommends that teams continue experimenting and learning, while adopting a measured and transparent strategy source. The organizations that benefit are the ones that redesign workflows, not the ones that layer AI onto unchanged processes.

How does a software factory prevent AI delivery failures?

A software factory enforces small batch sizes, standing evaluations at handoff seams, and senior human oversight before production. It treats AI output as material that must pass the same delivery gates as human-written code, with faster feedback rather than looser gates. This is the operating model that converts AI productivity into reliable software delivery.

AI is not the first tool to make developers faster while making delivery harder. The same cycle appeared with cloud, low-code, and microservices. Each time, the teams that won were the ones that redesigned their operating model to absorb the new speed. The 2024 DORA report confirms that AI follows the same rule. Model capability matters, but batch size, feedback loops, and human oversight at the seams matter more. The enterprises that treat AI as a reason to rebuild their software factory, rather than a reason to skip it, will be the ones that turn productivity gains into production stability.