Your AI Rollout Has a DevOps Problem

Teams that used to feel rushed trying to fit a release into a two-week sprint are now prototyping full applications in a couple of days. All of these new AI tools have collapsed the effort side of the equation in ways that would have seemed completely implausible two years ago. And by almost any measure of execution speed, things are dramatically better.

But what we're hearing is that the complaints have shifted rather than stopped. Product Managers can't write specs fast enough to keep pace with what's getting built, developers are shipping features they don't fully understand because the output is outrunning their comprehension, and customers can't consume new functionality fast enough to give meaningful feedback. Yes, work is moving through the pipeline. It's just piling up in different places than it used to.

But anyone who's spent enough time building software knows that the bottlenecks were always there. Development used to be slow and expensive enough to absorb the friction upstream and downstream. Basically, things were slow enough that waiting a few days for a compliance review or design sign-off didn't feel like a crisis. The cost of coding created this natural governor in the whole system. What we're seeing though is when you remove that governor without changing anything else, you don't eliminate the constraints. You just apply pressure to new parts of the system in a way you never had to before.

We’ve Seen This Movie Before

The last time we saw something like this happen at scale, we called it DevOps.

Before DevOps, software delivery had a similar structure. Developers built things and then handed them off to operations to deploy and run, and the bottleneck, at least in hindsight, was obvious. It created queues, delays, miscommunication, and a fundamental misalignment of incentives: developers optimized for shipping features, ops optimized for stability, and the wall between them generated most of the organizational friction in the SDLC.

When the DevOps movement came about, it wasn't just about moving faster. People realized that they had to eliminate the handoff by collapsing the wall and giving developers ownership of the full lifecycle and building the infrastructure that made the ownership viable. CI/CD pipelines, infrastructure-as-code, observability tooling, automated testing. All of these things help to build the systems that would make autonomous action safe.

Many times companies stood up DevOps teams but didn’t change the model where other teams still depended on them to deploy their infrastructure. That wasn't DevOps, it was just Ops with a better name. The point was always to make that dependency disappear. And the heuristic was that you had accomplished it when teams could deploy without asking anyone for help or permission.

AI is now applying that same pressure to every other function in the SDLC, not just the relationship between dev and ops but between engineering and product, engineering and design, engineering and compliance, and engineering and QA. We are drastically reducing the bottlenecks around the execution, and every other dependency is now exposed.

Everything is Infrastructure Now

The teams who did DevOps well didn't just tell developers to figure it out. They built the platforms, tooling, and codified the standards that let them move fast without breaking things. They understood that if they made the right path the easy path then people would do things the right way. Of course, the ones that did it poorly just created a lot of broken pipelines and frustrated engineers who didn't know what they were supposed to do because that had never been part of their job before.

The same thing applies now, the surface area is just much larger. The question for every function in your organization is whether you've built the equivalent of that infrastructure:

• Does your design system give teams enough guidance that they can make sound UX decisions without routing every screen through a designer?
• Have you codified your compliance and legal requirements clearly enough that an engineer can build a feature with confidence rather than waiting on a review cycle?
• Does your quality bar exist somewhere explicit enough that someone can evaluate their own work against it, or does “quality” only become visible when a tester finds a problem after the fact?

This is where systems thinking stops being a nice-to-have and becomes a core leadership capability. It's always been useful to understand how work flows through an organization: where the handoffs live, where pressure accumulates, what depends on what. But when execution was slow, you had time to respond. You could see the problem forming and intervene. At the velocity of AI, that lag is gone and tolerances are much tighter. If you haven't mapped the whole system and deliberately built infrastructure to keep it healthy, you'll find out what's wrong when customers do.

The Teams That Will Struggle

DevOps didn't benefit everyone equally. Organizations that were already operationally mature (where infrastructure thinking was embedded into the engineering culture or where there was an appetite to invest in platforms before they were obviously necessary) made the transition well. Organizations that treated it as a tool adoption rather than organizational design mostly didn't.

These teams didn't fail because of ignorance. They mistook access for capability. Giving developers cloud consoles and deployment pipelines without building the underlying standards and guardrails didn't create DevOps organizations. It created chaos at a higher velocity.

The same failure is going to happen to any organization approaching AI rollout as a capability problem rather than an infrastructure problem. The instinct is entirely understandable: the tools allow you to reach that “Eureka moment” faster than anything that we've ever seen, the demos that we see are extremely compelling, and there is immense pressure to show momentum. But momentum without infrastructure is just risk accumulating faster than you can see it.

The teams that will navigate this well are the ones treating this moment as a fundamental redesign of how work flows, not as a tool adoption cycle. We're getting rid of the execution bottleneck that has always existed and we tacitly depended on.

What you build to replace it determines whether the speed you've gained is an advantage or a liability.