Shawn Duggan

Writing

AI only gives you more of what you already have

The teams using AI coding tools most heavily ship faster, and they break more. The answer isn't less AI. It's a delivery system built to absorb it.

By Shawn Duggan

In February 2026, the research firm Coleman Parkes surveyed 700 engineering practitioners and managers at large enterprises in the US, UK, Germany, France and India for Harness’s State of DevOps Modernization 2026 report. The headline finding sounds like good news. Teams that use AI coding tools many times a day are the most likely to deploy daily or faster: 45 percent of them, against 15 percent of teams that use the tools weekly.

Read further and the picture changes.

  • For the heaviest AI users, 22 percent of deployments end in a rollback, a hotfix or a customer-impacting incident. For occasional users, it’s 15 percent.
  • When something breaks, the heaviest users take longer to recover: 7.6 hours on average, against about 6 hours for lighter users.
  • 69 percent of the heaviest users say AI-generated code leads to deployment problems at least half the time.

Harness is careful to say the survey doesn’t prove AI caused these problems. It doesn’t need to. The pattern will be familiar to anyone who has run a delivery organization: push more work through a system, and its weakest part shows you where it is.

The bottleneck moved

AI made writing code cheap. It didn’t make the rest of delivery any cheaper. Review, testing, integration, deployment and recovery were all built around how fast people could write code. Now code arrives faster than those steps can absorb it.

The same research shows how thin those steps already were. Developers spend about 36 percent of their time on repetitive manual work. 73 percent of respondents say hardly any of their teams have standard templates or “golden paths” for delivery. 77 percent say teams often wait on other teams for routine work before they can ship.

Put AI on top of that and you don’t get a faster delivery system. You get the same system under more load. Manual checks become queues. Flaky tests get rerun, then ignored. Reviewers skim. Releases spill into evenings and weekends: 96 percent of the heaviest AI users say release work pulls them in several times a month, against 66 percent of occasional users.

AI only gives you more of what you already have. If delivery is steady and well tested, AI makes it faster. If it’s unpredictable or fragile, AI makes it unpredictable and fragile at a higher speed.

Measuring the wrong thing

Many AI rollouts are judged by what’s easiest to count: licences issued, suggestions accepted, pull requests opened. Those measure input. They tell you code is being produced, not that customers are getting working software sooner.

The measures that matter haven’t changed:

  • Lead time: how long a change takes from start to running in production.
  • Deployment frequency: how often you ship.
  • Change failure rate: how often a change causes a problem.
  • Time to restore: how quickly you recover when one does.

If AI is working, the first two improve and the last two hold steady. If only the first two move, you’ve traded speed for risk, and the bill arrives later.

Fix the foundation first

None of this is an argument for slowing down on AI. It’s an argument for doing the unglamorous work that lets a team absorb it.

  1. A steady flow of work. Small batches, limited work in progress, and commitments that land when you said they would. A large batch of AI-written change is as hard to review and integrate as a large batch written by hand.
  2. Automated testing and deployment. If a person has to check something every time, that check becomes the constraint as volume rises. Every manual gate is a queue waiting to happen.
  3. Clear requirements and ownership. Vague work produces vague code, faster. Someone needs to own each change from idea to production, including what “done” means.
  4. Quality built in. Standards, guardrails and automated review that every change has to pass, whoever or whatever wrote it.
  5. Measures that matter. Lead time, change failure rate and time to restore, tracked before and after the rollout, so you can tell whether AI is helping.

The same foundation is what agents need

The next step most teams want is agents: tools that take a piece of work and carry it through planning, coding and testing with minimal hand-holding. That’s where the larger gains are.

Agents raise the stakes on everything above. They can ask questions and investigate a failed test, but they still depend on the delivery system around them. If the ticket is vague or the tests are unreliable, more of your time goes into correcting the work. And an agent will produce as much change as your pipeline allows; your tests and guardrails decide whether that change is safe. Teams that skip the foundation will find agents amplify their problems faster than anything before them.

Where to start

  • Measure your four delivery numbers today, before changing anything else.
  • Find the step where work waits longest. That’s your real constraint, and it’s rarely writing code.
  • Automate that step before adding more AI upstream of it.
  • Set standards every change must meet, and make them checkable by machines.
  • Then extend AI further, and watch whether lead time falls without the change failure rate rising.

AI is an amplifier. Before you turn it up, decide what you want amplified.

Sources

Where is your team with AI?

A short note about your team and what you're trying to change is enough to start.

Book a free 30-minute callSend an email