AI has become part of everyday software development workflows, giving engineering leaders the ability to increase their teams’ output without adding to their headcount.
The efficiency gains that AI tools can create in the early stages of delivery are fairly definitive. But what’s less clear is whether downstream processes will be able to keep up. That tension became particularly evident in Harness’ recent State of DevOps Modernization 2026 report.
Driving without a seatbelt
Analysing the data, Harness saw a clear pattern emerging where more frequent use of AI coding tools does correlate with faster deployment. But it also leads to increased strain across downstream delivery processes.
The report found that 45% of “very frequent” users of AI coding tools deploy daily or even more frequently, compared with 32% of “frequent” users and 15% of “occasional” users. On the surface, that looks like a clear sign of reduced friction and accelerated delivery.
But speed of delivery by itself does not provide a complete measure of engineering team productivity and success.
Among the engineers who use them “very frequently”, 69% say the code created by AI tools leads to deployment problems at least half of the time. That same group of respondents say that 22% of their deployments result in a rollback, hotfix, or customer-impacting incident, compared with 15% of occasional users.
Mean time to recovery is also increased. Production incidents related to code deployments take an average of 7.6 hours to resolve for “very frequent” users of AI tools, compared to six hours for “frequent” users.
This is the velocity paradox now taking shape across engineering teams. AI is making it easier for developers to produce more code. But if CI/CD pipelines, guardrails, and recovery processes fail to evolve at the same pace, increased velocity just leads to more opportunities for production failures.
We’re driving without a seatbelt on, and that’s as sensible as it sounds.
The bottleneck has shifted downstream
Since their organisation introduced AI coding tools, around half of “very frequent” users have seen more vulnerabilities, security incidents, non-compliance issues, performance problems, and issues with code quality and efficiency. That’s not a great testament of success.
The problem isn’t that the use of AI is creating these issues – it’s that it’s exposing existing weaknesses at greater scale.
AI tools have broken the dam and unleashed a torrent of code into delivery pipelines, but downstream controls are being overwhelmed. They simply can’t contain it and deliver it safely into production.
It’s no surprise that 86% of engineering leaders and practitioners say that security and compliance checks need to be more automated to meet delivery timelines. Among “very frequent” users of AI coding tools, that rises to 92%.
There’s a clear call for more help in moving code safely through downstream delivery.
Uneven distribution across the pipeline
A large part of the problem is the uneven distribution of AI throughout the software delivery pipeline.
Code creation is by far the most common use case, with 84% of respondents using AI at least daily to write code. That adoption drops off sharply across downstream processes such as QA testing, performance and cost optimisation, and refactoring.
And that brings us to the crux of the problem. Software delivery has never been constrained by code creation alone. The downstream processes that enable engineering teams to get code into production have an equal, if not greater impact on their productivity.
As AI enables engineering teams to push more code to production, downstream bottlenecks are becoming more visible and more costly. Nearly half (47%) of “very frequent” users of AI coding tools in our report say manual downstream work has become more problematic as a result of that usage – compared to just 29% of “frequent” users.
The tax on developer wellbeing
The productivity gains of AI coding tools are undermined even further by the added friction being created in testing, compliance, release management, and incident recovery processes. This is piling pressure onto developers and eroding the benefits engineering leaders sought to realize from AI.
More than two-thirds (69%) of respondents say that slow or unreliable CI/CD pipelines waste time and contribute to developer burnout, while 70% say their pipelines are plagued by flaky tests and deployment failures. Among “very frequent” users of AI coding tools, those figures rise to 76% and 79% respectively.
The human cost is equally sobering. Three-quarters of developers say the pressure to ship quickly has contributed to their feeling of burnout. More than two-thirds (71%) are forced to work during evenings or at weekends at least once per week because of release-related tasks or production incidents.
But here’s the kicker: among “very frequent” users of AI coding tools, 96% say they have to work evenings and weekends multiple times a month or more, compared to just 66% of those that use them “occasionlly”. That shows a clear trend of AI tools increasing workloads, rather than reducing them.
Planning for a future defined by AI
For engineering leaders, the question is not whether teams should use AI coding tools. They absolutely should. The genie is out of the bottle, and there’s no way of going back to the old ways of working.
Instead, they should be asking themselves whether the delivery pipeline, guardrails, and operating model they’ve built are evolving quickly enough to support the faster pace of AI-powered development.
In the second part of this blog, I’ll offer some practical steps that engineering leaders can take to modernize their DevOps delivery pipelines so they can benefit from the speed of AI coding without sacrificing stability, resilience, and developer wellbeing.