Most enterprises are asking the wrong question about AI in engineering: “How fast can we write, test, and merge code?” That framing has produced impressive results. In Bain’s recent survey of nearly 300 tech and engineering leaders, AI’s biggest measurable gains to date are in speed and throughput, and executives expect an almost 150% improvement in the next one or two years.

But faster-released software still must be deployed, monitored, diagnosed, and repaired. And the operational half of the organization—the CIO’s operations team and the CTO’s site reliability engineering (SRE) and platform teams—was built for a world where humans wrote code at human speed.

The survey exposes the gap. Executives expect the most dramatic improvements from AI in release speed and engineering cost efficiency; the anticipated gain in operational resilience is the smallest of every metric we measured (see Figure 1).

Figure 1

We call this the reliability paradox: AI compresses the cost of building software but can inflate the cost of running it, unless operations get redesigned in parallel. When 10 times more change is directed at an operating model built for manual response, you get a faster enterprise that stumbles more often. Solve for velocity alone, and you move the organizational bottleneck from the engineer’s keyboard to the pager.

However, the emerging leaders are discovering that velocity and resilience aren’t in tension; they’re two outputs of the same redesigned system.

Operations: The forgotten half of the AI development life cycle

The traditional divide between product and software development is collapsing. AI lets teams define, build, test, and refine in one flow rather than sequential hand-offs. (See the Bain Brief “The Rise of the AI Development Life Cycle.”)

That logic doesn’t stop at deployment. Runtime behavior—what breaks, what degrades, what users experience—is the clearest signal of software quality. Historically, that signal has traveled slowly: a PDF postmortem, a ticket, a retrofit three sprints later. Now, it must move as fast as the code that generated it.

This is why AI operations, or AIOps—applying AI to real-time telemetry to detect, diagnose, and resolve software incidents—isn’t a separate initiative for a separate team with a separate budget. What we’ve called “close the loop” in development is, in operations, the difference between learning from every incident and fighting the same fire twice.

Companies have made the paradox visible in where they’re putting their attention. Asked to rank the levers most likely to improve engineering productivity, leaders placed observability and incident automation—AIOps—near the bottom, cited by roughly one in five (see Figure 2). Almost two-thirds of executives ranked applying AI to development—coding, testing, and reviewing—as the most important lever.

Figure 2

Where should the AIOps journey start? Autonomy depends on context, and most enterprises haven’t built it. An agent can act only on what it can see, so four things come first: unified observability across metrics, logs, and traces; a service knowledge graph covering topology, ownership, dependencies, change history, security posture, and past incidents; a machine-readable incident taxonomy and runbooks; and enough environment standardization that fixes in one system stay safe across the rest.

Netflix offers a template. The company adopted a new incident management platform, and its engineers wired teams, services, business domains, and even hardware devices directly into the platform, so alerts automatically route to the right responders and incident fields pre-fill from telemetry. Shared language and standard metadata make that automation possible; without them, agents have nothing reliable to act on.

For CIOs: The run organization is the new frontier

In a typical IT portfolio, the run organization—“keep-the-lights-on” spending on infrastructure, service desk, incident management, and security operations—dwarfs the budget for new development. Because it’s unglamorous, the run organization is also where AI has been least disruptive to date. That’s about to change.

Organizations applying AIOps report shorter mean time to resolution, fewer major incidents from earlier detection and better alert-trend analysis, and lower infrastructure costs from automated rightsizing and tool consolidation. The same capability extends to security operations, cost optimization, compliance automation, and infrastructure life cycle, each its own line in the run budget. But these early gains undersell the prize: a run organization that no longer scales with complexity—more systems, more alerts, more people to triage them—because the system increasingly diagnoses and heals itself.

Netflix’s data platform team integrated its rule-based error classifier with machine learning to predict whether a failed big data job will succeed on retry, identify the correct configuration to apply, and remediate the issue automatically. Netflix reports that the new system resolves about 56% of memory configuration errors online with no human intervention while cutting associated costs by roughly 50%. That’s an example of the run organization absorbing a whole class of routine failures without paging an engineer.

The ultimate goal is zero-touch operations, where agents observe, decide, act, and learn across the full incident life cycle before paging a human. Roughly half of organizations in our survey expect many crucial engineering tasks to be AI led within two years (see Figure 3).

Figure 3

Few enterprises are close to this today. Only about 2% call their engineering organization “autonomous-first”; most are piloting or integrating early workflows (see Figure 4). The CIO’s job isn’t to buy a platform that promises the top of the curve; it’s to build the organizational capability to climb it.

Figure 4

The implication is that the operating model itself is obsolete. Layering AIOps tooling onto a team structured around manual triage tiers—L1 escalating to L2 to L3—produces a faster version of the wrong process. The prize requires redesigning the work, not just speeding it up.

For CTOs: SRE was designed for a world that no longer exists

SRE was one of the great operating model innovations of the past two decades. It brought software discipline to reliability: error budgets, service-level objectives, engineering rigor applied to uptime. But agentic AI changes SRE’s core premise that skilled human attention is the scarce resource, to be spread as efficiently as possible across a growing system. When an agent can ingest telemetry across every layer, infer a root cause from a dependency graph, and execute a remediation runbook faster and more consistently than a human on call, the scarce resource becomes trustworthy autonomy.

This allows engineers to shift focus from manual incident triage to initiatives where they can deliver more value. Our survey shows engineering leaders are already pricing this in. The reliability engineer who spent nights correlating alerts across six monitoring tools was never doing their most valuable work. As on the development side, they now move from operator to architect of autonomous operations. They’re charged with defining what “healthy” means, encoding the policies that govern when an agent may act autonomously vs. when it must escalate, and building the evaluation harnesses that keep autonomous remediation from causing more harm than it prevents.

The adjustment for value runs past the SRE. The most successful companies will adopt a clean-slate mindset: If no one were on call tonight, what would break, and where is human judgment irreplaceable? That question surfaces roles most organizations don’t staff today: agent orchestration engineers who supervise remediation fleets, reliability product managers who own the reliability envelope, AIOps data engineers who maintain the telemetry and knowledge graph layer, and agent observability owners who watch the agents. Natural language interfaces let nonspecialists investigate systems, freeing a smaller senior team to focus on governance and architecture.

The CTO who gets these things right measures the SRE function not by how fast incidents get resolved but by how few reach a human.

The principles that separate leaders from tourists

The principles of AI-led development apply, with sharper edges, to AI-led operations.

Context is king. An AIOps agent is only as good as the context it can reach. Without a unified telemetry layer and a knowledge graph that models how systems actually relate, agents are alert summarizers, not autonomous operators.

Treat risk as the primary design constraint. Letting an agent restart a service, roll back a release, or rescale infrastructure in production are far higher stakes than letting one draft code behind a human reviewer. In our survey, safety, risk, and governance guardrails ranked as the top enabler for scaling agentic AI, and governance and legacy system constraints were among the leading barriers. Autonomous remediation needs a runtime governance layer: confidence thresholds that gate action, policy-as-code guardrails, full auditability, clear human checkpoints for high-stakes changes, and close tracking of agents’ decisions, tool calls, and costs. For example, Google bakes those autonomous boundaries into its SRE tooling. Agents retrieve an approved runbook through a function call (“fetch_playbook”), rather than freeform commands.

Measure outcomes, not output. Traditional metrics—even the DORA metrics that defined the DevOps era—were built for a world where humans did all the work. Now, mean time to resolution alone can mislead: A system can resolve incidents faster while quietly accumulating fragility. Measurement must separate human from agent action, treat the blended human-plus-AI team as one unit, and elevate reliability, control, and trust to first-class scorecard dimensions (alongside speed). The most successful companies will also track autonomous resolution rate, cost, and business outcomes rather than assume adoption delivers results. The survey’s central tension—greater expected gains in software engineering velocity than resilience—is what happens when organizations measure what’s easy to see and neglect what’s hard to trust.

Design for compounding. The biggest long-term opportunity is compounding advantage: Every incident an agent resolves and documents becomes context that speeds the next fix, so the system improves the more it runs. A human triage team can’t do that; its knowledge leaves with attrition and degrades between incidents. Closing the loop turns operations into a capability that improves with use rather than a cost that grows with volume.

The redesign is the strategy

The temptation for the CIO and CTO will be to treat AIOps as procurement: select a platform, deploy it against the existing operating model, book the efficiency gains. That path delivers the incremental improvements most companies see today but leaves the paradox unresolved: Development still accelerates faster than operations can absorb.

Chaining together the organization’s existing AI tools won’t solve the problem, but neither does the solution require an upheaval or a massive budget. It calls for developing a new set of linked processes and capabilities: redesigning workflows so runtime feedback flows back into planning at machine speed, restructuring teams around agent orchestration rather than manual triage, and rebuilding measurement so trust and control are visible alongside velocity. Once built, those capabilities become the control plane for autonomous work well beyond engineering.