This is part 1 of 5 in a series adapted from our white paper, The Autonomous Operations Factory: the operating model that completes the AI software factory. Download the full white paper for the complete argument, figures and sources.
AI has solved half of the software problem. Enterprises invested heavily in AI for writing, reviewing and testing code, and it worked. Large-scale studies at Google and Microsoft found double-digit gains in change throughput per engineer.
The half that runs the software has not changed. The four key stages of operations (build, operate, observe and remediate) absorb everything the inner loop produces, at roughly the rate they always did. As coding velocity increases, work accumulates in operations, and risk accumulates with it.
This post covers why that imbalance is structural, why only one lever can fix it, and what actually makes operations cycle time slow.
The bottleneck has moved from development to operations
Change volume is up, deploy frequency is up, and the blast radius of any single change is larger than it was three years ago. Operations absorbed all of it with no comparable change of its own.
The gain on the development side is measured, not asserted. Google engineers who adopted an AI feature in their IDE submitted 17.5% more change lists per user-month, against an 18,000-engineer comparison group [1]. Microsoft engineers adopting command-line coding agents merged 24% more pull requests per engineer per day [2]. Both measure more change arriving faster at the boundary of the outer loop.
The imbalance is now doing damage rather than just creating drag. DORA's 2025 research found AI adoption associated with reduced delivery stability [3]. StackGen's State of Reliability 2026 analysis found AI now accounts for roughly 10% of disclosed company incidents, a six-fold rise in three years. It also documented nine cases in the past year of an AI agent taking destructive action against a live production system on its own [4].
Operations is a queue, and only one lever moves it
Changes arrive at the operations loop at some rate. The loop clears them at some rate. When arrivals outpace clearance, work accumulates: deployments waiting on a window, incidents open, tickets queued. That is the backlog, and it grows for as long as the imbalance persists.
The signature is already visible in delivery telemetry. Across 28.7 million CI workflows, CircleCI found feature-branch activity up a median 15% year on year, while main-branch throughput fell a median 7% [5]. Faros AI, across roughly 22,000 developers, found median time to first review up 156.6% [6]. Both measure a jam at code review, upstream of operations and moving toward it.
Three levers could change that balance: slow the arrivals, add people, or clear the work faster. Only the third is open to most organizations.
- Slow the rate of software change. In practice this means slowing development down.
- Add capacity. Headcount is not scaling with change volume in any organization we talk to. Even where the money exists, hiring does not track a step change in output.
- Reduce cycle time. The only lever left. If the operations loop clears work as fast as it arrives, the backlog stops growing however high the arrival rate goes.
The outer loop today, and with an operations factory. The same arrival rate, a different rate of clearance.
That makes the case for an operations factory a structural argument. The question is not which tools you use or how strong your operations team is. It is whether your outer loop can clear work at the rate your inner loop now produces it.
Fragmentation is what makes cycle time slow
In most organizations the four stages map to four teams and four toolchains: build to infrastructure, operate to DevOps, observe to observability, remediate to SRE. Each is excellent within its domain. The problem is that none is aware of what the others know. Two ordinary examples:
- An observability agent diagnoses an incident without knowing which infrastructure change is pending approval.
- A cloud agent optimizes a resource without knowing the application's release commitments.
Each is locally correct and globally wrong, and neither is a tool defect. The failure happens in the gap between them, and that gap is where the cycle time goes. The tooling knows what the logs say. It does not know what Terraform changed.
The cross-domain case is where the cost concentrates, and it has been measured. Across 225 services in one large cloud estate over twelve months, for more than 52% of outages the service where the problem surfaced was not the service where the root cause sat [7]. Across twenty large online services, reassigning an incident to a second team multiplied triage time by up to 10.2 times, and by 15.2 times at the highest severity [8]. Operations runs as a line, and every handoff is a stop.
What this means for operations teams
Improving operations cycle time is now critical, and that means tackling fragmentation. The four stages run as four disconnected functions, and the elapsed time lives in the handoffs between them.
The obvious response is to add an AI agent to each stage. That is a useful first move, but it does not shorten the loop. Part 2 explains why. For a shorter take on the same shift, see Sanjeev Sharma's post, Your Software Factory Needs an Operations Factory.
Download the Autonomous Operations Factory white paper
This post is part 1 of 5 drawn from our white paper. The full paper brings the series together in one place, with the figures, the market map and every source. Download the white paper.
The series
- Part 1: AI Coding Gains Have Moved the Bottleneck to Operations (you are here)
- Part 2: Why More AI Agents Won't Shorten Your Operations Loop
- Part 3: The Four Components Every Operations Factory Needs
- Part 4: How AI Agents Coordinate Across the Operations Lifecycle
- Part 5: How to Start Building Autonomous Operations, Stage by Stage
Sources
- Google, Achieving Productivity Gains with AI-based IDE Features, 27 January 2026.
- Microsoft, Adoption and Impact of Command-Line AI Coding Agents, 1 July 2026.
- DORA, State of AI-assisted Software Development, 2025, fielded June–July 2025.
- StackGen, State of Reliability 2026. 109,000+ unplanned incidents across 392 companies.
- CircleCI, 2026 State of Software Delivery Report, 18 February 2026. 28.7 million CI workflows.
- Faros AI, The AI Engineering Report 2026, 12 April 2026. Telemetry across ~22,000 developers.
- Wang et al., Fast Outage Analysis of Large-scale Production Clouds with Service Correlation Mining, ICSE 2021.
- Chen et al., An Empirical Investigation of Incident Triage for Online Service Systems, ICSE-SEIP 2019.
