The reason is not that models are better at operations than at programming. They are not. IBM’s ITBench found that state-of-the-art agents resolved 13.8% of SRE scenarios, 25.2% of CISO scenarios, and none of the FinOps ones. Coding agents, by contrast, already write a large share of the diffs that land in production.
Incident response will change first because of the shape of the work, the shape of the feedback, and what we are already measuring in delivery. Coding got faster. The control system around the change did not.
Coding sped up. Verification did not.
The 2025 DORA report is the cleanest data we have. AI adoption among software professionals is at 90%. Throughput is now positively correlated with AI use — a reversal from 2024. Stability is still negatively correlated. Teams are shipping more changes. Those changes still fail in production at a higher rate.
Google’s SRE book has said for years that roughly 70% of outages are due to changes in a live system: binaries, config, flags, capacity. Increase the change rate and you increase the incident rate even if per-change quality is unchanged. That is queueing. It is not a moral argument about AI-generated code.
The constraint in coding moved from generation to review. A human cannot read at generation speed. Single-reviewer oversight on AI-authored diffs is already common. Incident response is where the unread diff, the skipped integration test, and the missing canary all arrive at once, usually in a system the on-call engineer did not author. So the operational load is going up because coding got faster, not because coding got solved.
Incident response is a constrained search
A coding agent is asked to produce something that does not exist yet. The spec is incomplete. The tests, if they exist, are a partial oracle. Success is delayed until review, CI, staging, and production. SWE-bench looks nothing like this: frozen repo, specific bug, clear pass/fail. Production is not a frozen repo.
An incident has a different structure. The system already exists. The failure is already happening. The artifacts already exist: alerts, dashboards, deploy markers, traces, runbooks, last week’s postmortem. The success criterion is immediate and local: did the SLI recover?
That is retrieval, correlation, and hypothesis ranking. It is the work tool-using models currently do well, provided you do not ask them to take unbounded production actions. The phases also separate cleanly, which coding does not:
- Detection — is this a real error-budget burn, or a noisy alert on a non-user-facing series?
- Triage — severity, user impact, blast radius, commander, communication channel.
- Investigation — what changed, which dependency, which resource, which trace.
- Mitigation — rollback, feature flag, traffic shift. Restore the SLI. Root cause can wait.
- Communication — timeline, customer update, status page, executive summary.
- Learning — postmortem, action items, runbook update, alert rewrite.
Each phase has a different permission set. Summarizing a Loki query is read-only. Rolling back a Deployment is not. Coding does not have an equivalent of “mitigate first, root-cause later.” The unit of work is the change itself. That is why IR is a better first surface for agents: you can put a hard split between diagnose and mutate, and you can score the diagnose step against ground truth.
Why 13.8% is not a contradiction
ITBench is hard on purpose. Agents receive Kubernetes incident snapshots — alerts, events, traces, metrics, logs, topology — and must identify the minimal set of root-cause entities. A NetworkPolicy that blocks the frontend is a typical case. The agent has to look at the alert window, follow traces, inspect manifests, and name something like otel-demo/NetworkPolicy/frontend-block-all-ports. Frontier models still miss most of these. The agents that do work are not stuffing logs into context; they use tools such as NL2Metrics, NL2Logs, NL2Traces, and NL2Kubectl because the raw volume would overflow any window.
That tells you autonomous RCA is not a solved problem. It does not tell you that assistance is useless. The time in a real incident is not spent on the novel diagnosis. It is spent on the first twenty minutes of gathering: which alert fired, what deployed in the last hour, is the error budget already exhausted, which traces are slow, has this happened before. I have watched experienced SREs lose ten minutes finding the right Grafana folder. That work has structure. It should be a tool call.
If 70% of outages are changes, the first query is not a PromQL safari. It is: what shipped, what config changed, what scaled, in the SLO burn window. Deploy markers, Git SHA on the ReplicaSet, feature-flag diffs, and Kubernetes Events are higher-signal than another dashboard. An agent that does not start there is doing the investigation backwards.
The architecture that is actually safe
The useful design is not “an agent that pages itself.” It is a governed loop:
- A read-only tool layer over Prometheus, Loki, Tempo, Kubernetes, and the deploy API, with query cost limits and scoped credentials.
- Change correlation first, then symptoms, then traces. Citations back to specific queries and trace IDs. No citation, no action.
- A hard split between diagnose and mutate. Mitigation tools — rollback, disable a flag, cordon a node — require a human confirmation except for a small, reversible, previously evaluated class.
- Blast-radius labels on every mutation. Restarting a stateless Deployment is not the same as failover of the primary database. Confidence routing belongs in the platform, not in the prompt.
- An eval harness. Freeze last quarter’s incidents and score time to first correct hypothesis, citation precision, and whether it proposed a mutation that would have made things worse. If you cannot fail an agent the way you fail a deploy, it does not belong in the incident channel.
Coding agents will keep getting better. The bottleneck will remain everything after git push: policy, progressive delivery, observability, and the production contract. Incident response absorbs the shock first because that is where unread change meets user traffic. Investing in AI for IR is not a distraction from AI for coding. It is the control system that makes faster coding survivable.
The teams that treat AI coding as a throughput win and leave on-call unchanged will measure that win as instability. DORA already is.