AI Agents Are Shipping More Code and Breaking More Deployments

There is a gap opening up in software teams that adopted AI coding tools over the past two years, and it is not where most people expected it. The gap is not between developers who use AI and those who do not. It is between how fast code gets written and how fast it safely reaches production.

This is not a niche complaint from skeptics. Google's DORA research found that while AI adoption correlates with higher delivery throughput, it simultaneously drags on delivery stability. More output, less predictability. For engineering leaders who thought they were buying speed across the entire delivery cycle, that finding deserves serious attention.

The Throughput Illusion

The headline numbers are real. AI coding assistants — GitHub Copilot, Cursor, Claude Code, and their peers — do make developers faster at the tasks that involve generating code. Teams report routine acceleration on boilerplate, CRUD operations, unit test scaffolding, and documentation. The productivity gain at the individual keystroke level is not fabricated.

The problem is what happens downstream.

When you accelerate code generation without proportionally accelerating code review, security analysis, integration testing, and deployment validation, you do not get a faster pipeline. You get a faster intake pipe feeding into the same-width bottleneck. The volume of code arriving at review increases; the time and cognitive capacity available for review stays constant. The result is either slower releases as reviewers struggle to keep pace, or faster releases with less scrutiny — which is how instability creeps into production.

One DORA finding puts a precise shape on this: roughly 90% of technology professionals now use AI at work, and that adoption is associated with higher delivery throughput and simultaneously lower delivery stability. Teams ship more often and break things more often. That is a tradeoff that is worth naming explicitly rather than burying in aggregate productivity metrics.

Where the Velocity Disappears

The friction points are predictable once you understand where AI tools actually help and where they do not.

Code generation vs. code understanding. AI is good at producing code that looks correct for common patterns. It is considerably less reliable at understanding the specific invariants, edge cases, and architectural decisions that matter in a given codebase. A developer using an AI agent to implement a new feature may get a working implementation quickly — but the implementation might violate assumptions baked into adjacent modules that the AI never read or did not fully weigh.

Test generation vs. test quality. AI can generate tests faster than a developer can write them manually. What it generates tends to be structurally valid but semantically shallow: tests that exercise the happy path and confirm that the code does what it says, rather than tests that probe the boundaries that matter for reliability and security. More test files, lower confidence.

Familiar patterns vs. novel problems. There is a study worth citing here because it runs counter to the prevailing narrative. Researchers asked developers to complete a programming task they knew well, some with AI assistance and some without. The developers using AI were 19% slower — not faster — even though they reported feeling faster. On complex work where the stakes are real, the time saved on typing gets spent checking, correcting, and untangling what the AI produced. The subjective sense of acceleration masks an objective slowdown. That mismatch does not show up in satisfaction surveys.

The Security Surface Expands

Volume is a security problem in ways that often go unnoticed until something breaks in production.

Generated code follows patterns from training data. That is by design — it is how the models learned to write plausible code. The consequence is that common vulnerability patterns also survive in generated output: SQL injection risks in ORMs used incorrectly, insecure defaults in authentication flows, overly permissive error handling that leaks stack traces. The code is not obviously broken. It compiles, passes tests, and behaves correctly under normal load. The weak spots only surface under specific conditions or under adversarial probing.

More code being written faster means more potential weak spots entering the codebase faster. Security review capacity does not scale automatically with AI adoption. Teams that have not explicitly invested in expanding their security review and static analysis processes alongside their AI tooling are almost certainly shipping vulnerabilities at a higher rate than before — while believing they are moving faster.

The irony is that AI can also help with security analysis. Tools like Semgrep, Snyk, and GitHub's code scanning integrate into CI/CD pipelines and catch a class of issues before they reach production. But those tools require deliberate setup, tuning, and interpretation. They do not come pre-integrated into the AI coding workflow that most teams are using today.

Why Planning and Release Processes Don't Benefit

AI coding agents operate within a narrow slice of the software delivery lifecycle. They help with the writing phase. The phases that precede and follow writing — understanding requirements, architectural design, integration, deployment, monitoring, incident response — are mostly outside their scope.

This matters because those surrounding phases are where a lot of the real delivery time lives, especially on complex products. A developer might spend 20% of their time writing code and 80% on everything else: meetings, review cycles, debugging production issues, understanding existing code, coordinating deployments. AI shaving time off the 20% does not meaningfully change the total.

AI doesn't repair workflow bottlenecks. It adds volume to the front of the pipe.

Teams that measured productivity gains only at the code-writing stage and then announced AI-driven delivery acceleration have found this out the hard way. The velocity felt real in sprints. Then those products hit production. That is where the gaps showed up — in live systems with users, revenue, and compliance risk attached to every failure.

The pattern is consistent enough to be predictable: AI accelerates the start. It complicates what comes after.

The Review Bottleneck Is Now the Critical Constraint

If you accept that AI increases code volume without a corresponding increase in review capacity, then the critical constraint in AI-augmented teams is not writing code — it is reviewing it well.

Senior engineers are the review bottleneck. They have always been the review bottleneck. AI has made the problem more acute by widening the gap between the volume of code submitted for review and the senior time available to evaluate it seriously.

The common response — having AI assist with code review — is not wrong, but it requires precision. AI review tools are useful for surface-level issues: style violations, obvious logic errors, missing null checks. They are not reliable for the category of issues that matter most in production: architectural fitness, interaction with existing system behavior, compliance with implicit team conventions that were never written down. Those require human context that the model does not have.

Teams that let AI review substitute for senior engineer review are trading the right kind of scrutiny for faster merge approvals. The technical debt and production instability that follows is not immediately attributable to the policy that caused it. By the time it surfaces, the connection is hard to make.

A Practical Response for Engineering Leaders

None of this means AI coding tools are net negative. They are not. The productivity gains in specific contexts are real and worth capturing. What engineering leaders need to do is stop treating AI adoption as a pipeline-wide acceleration and start treating it as an acceleration in one stage that requires deliberate investment in adjacent stages to avoid instability.

Here is how to think through that investment:

Audit where your delivery time actually goes

Before deploying AI tools broadly, measure your actual delivery cycle time across stages: requirements to design, design to implementation, implementation to review, review to staging, staging to production. AI will compress the implementation stage. If that is not your bottleneck, the net effect on delivery speed will be minimal. If review or deployment is your bottleneck, AI may make things worse by adding volume.

Invest in test coverage before scaling AI-generated code

AI-generated code without adequate test coverage is harder to maintain and harder to refactor safely. Before expanding AI tool usage, establish a baseline of integration and end-to-end tests that characterize your system's critical behaviors. Then use AI to generate additional coverage — but treat AI-generated tests as a first draft requiring review, not as a substitute for thoughtful test design.

Set explicit review standards for AI-assisted PRs

A pull request with AI-generated code requires different review behavior than one where a developer wrote every line. The reviewer needs to ask not just "does this do what the description says" but "does this fit how our system actually works." Consider requiring architectural sign-off for AI-generated changes that touch core business logic, authentication, or data access layers. Not because AI is bad at those areas — but because the consequences of subtle errors there are highest.

Expand security analysis tooling as AI adoption grows

Integrate static analysis and dependency scanning into CI/CD if it is not already there. Tools like Semgrep, Snyk, or SonarQube are a minimum baseline. Configure them specifically for your stack and tune the rules to reduce noise. Treat AI code generation and security automation as inseparable: you should not adopt one without the other.

Measure delivery stability, not just velocity

Throughput metrics — story points, PRs merged, features shipped per sprint — will show AI adoption in a flattering light. DORA metrics tell a more complete story: deployment frequency, lead time for changes, change failure rate, and mean time to recovery. Track all four before and after AI adoption. If change failure rate is climbing alongside deployment frequency, you have found your tradeoff.

Build AI literacy into your review culture

Developers using AI tools need to understand how those tools fail — not in the abstract, but in the specific patterns relevant to your codebase and domain. That includes understanding that AI suggestions feel more authoritative than they are, that hallucinated APIs and incorrect library calls happen regularly, and that the confidence the model displays in its output is not correlated with its accuracy. This is not covered in most AI tool onboarding. It should be.

What the Next Phase of AI Tooling Needs to Solve

The current generation of AI coding agents was built to maximize developer throughput at the code-writing stage. That was the obvious starting point — it is the most legible, most measurable part of the development workflow, and the one developers are most conscious of.

The next generation of useful AI in software development will need to move upstream and downstream from code generation. Upstream means helping with design decisions, dependency analysis, and impact assessment before a line is written. Downstream means integration with deployment pipelines, monitoring systems, and incident data in ways that close the feedback loop between what was shipped and how it behaved.

There are early tools moving in this direction. AI-assisted architecture review, automated rollback triggers based on model-detected anomalies, and natural language querying of observability data are all in active development. None of them are mature enough to be reliable in high-stakes production environments without significant human oversight. But the direction is right.

The tools that will actually move delivery stability in the right direction are the ones that treat software delivery as a system — not as a series of isolated tasks, each of which can be independently accelerated without consequences for the others.

The Production Environment Doesn't Care About Sprint Velocity

Engineering leaders who are reporting AI-driven productivity improvements to executive stakeholders owe those stakeholders a precise accounting: productivity at which stage, measured how, against what baseline.

If the answer is "developers complete coding tasks faster on local benchmarks," that is a useful data point. It is not a claim about delivery speed or system reliability. Production systems are not local benchmarks. They have users, failure modes, interdependencies, and compliance requirements that no isolated productivity measurement captures.

The Spiceworks reporting on this pattern is part of a broader industry reckoning with the gap between what AI tools promise in demos and what teams experience in production. It is happening at companies that moved fast, adopted broadly, and then found stability problems they did not expect.

Twenty years of software delivery experience teaches one thing consistently: there are no shortcuts in the places that actually matter. AI does not change that. What it does is make the shortcuts more tempting — because the early phases feel faster, and the consequences of what was skipped arrive later, in production, where they are harder to trace and more expensive to fix.

The answer is not to slow down AI adoption. It is to extend the investment in engineering discipline that AI adoption makes more necessary, not less.