AI Isn't Replacing SREs — It's Deskilling Them, and Nobody's Measuring It§
Two prophecies dominate the current conversation about site reliability engineering. The first holds that SRE is the future of all software engineering: as AI writes more of the code, the humans who remain will be the ones keeping systems alive. The second holds that AI will devour every tech job, SREs included. According to Elizabeth, writing in the SigNoz newsletter, neither framing is useful to an SRE trying to figure out what their Tuesday will look like in 2027.
The newsletter's alternative question is sharper and considerably less comfortable: when AI handles 95% of your incident response, do you get worse at handling the 5% that actually matters? The 95/5 split is a framing device, not a measured statistic, but the underlying concern is concrete — that the failure mode of AI-assisted operations is not replacement but degradation.
The Ironies of Automation, revisited§
The structural argument in the piece leans on a 1983 paper by cognitive psychologist Lisanne Bainbridge, Ironies of Automation, which the author describes as eerily prescient. The newsletter frames this paper as the foundational framework for the entire debate, and it positions the discussion as part of a broader history of automation — one the author notes is worth reading for anyone interested in history and culture as well as engineering.
The core insight the piece draws from that lineage is that automation does not simply remove human work; it relocates it. What gets automated away is typically the frequent, well-understood, routine case — the one that builds pattern recognition through repetition. What remains for the human is the residue: the rare, ambiguous, genuinely novel situation where the automation has no answer. The operator is therefore asked to perform at their highest level precisely when they have the least recent practice, and typically under the most time pressure.
That is the mechanism by which deskilling operates. It is not a story about capability being deleted; it is a story about capability atrophying silently while the dashboards stay green.
What deskilling looks like in an AI-assisted on-call rotation§
The practical version of this is easy to trace even without hard data. When an AI assistant or automated remediation path absorbs the majority of pages, the human's role shifts from diagnosing to supervising — reviewing a proposed root cause, approving a rollback, confirming a hypothesis. That is a real productivity gain. It is also a different cognitive skill from the one required when the system is behaving in a way no runbook or model has seen before.
The newsletter's framing implies a second-order risk that is worth naming explicitly: the feedback loop. If the human approves AI-generated remediations most of the time, approval becomes a low-information ritual, and the human's model of the system drifts out of date without any single moment of failure to flag it. The verification signal is weakest exactly where confidence is highest.
This matters more in observability-heavy stacks, the newsletter's home territory, because telemetry is the substrate both for human diagnosis and for any model reasoning over incidents. Coverage of observability, OpenTelemetry, and open-source tooling is the publication's stated beat, and the deskilling question sits directly on top of it: the same instrumentation that trains an assistant also shapes what a human can still perceive unaided.
Implications for teams, not just individuals§
If the deskilling thesis holds, the mitigations are organizational rather than tooling-level. Several follow directly from the framing:
- Preserve the reps deliberately. If routine incidents are automated away, the practice they provided has to be replaced by something intentional — drills, game days, or structured manual investigation of resolved incidents after the fact.
- Treat approval as a skill, not a click. Reviewing an AI-proposed remediation is only meaningful if the reviewer can independently reason about why it might be wrong. That capability needs to be maintained, not assumed.
- Watch for the absence of the signal. Classic reliability practice measures failure. Deskilling produces no failure until it produces a large one, which means the standard instrumentation will not surface it.
What remains unsettled§
The newsletter is explicit that this is a discussion, not a verdict, and several things are genuinely unknown. There is no established measurement for SRE deskilling — no metric, benchmark, or accepted proxy. Whether AI assistance actually degrades novel-incident performance, or whether it instead frees enough cognitive bandwidth to improve it, is an open empirical question that nobody in the piece claims to have answered.
There is also the question the author poses most directly: whether anyone will notice before the next novel outage hits. That is a claim about organizational perception, not about AI capability, and it is the part of the argument most resistant to evidence in either direction.
The useful takeaway for practitioners is narrower than either prophecy. The question is not whether AI replaces SREs. It is whether the skills that make an SRE valuable during the rare, unprecedented incident are being quietly maintained — and whether your team would know if they weren't.
*Source: AI isn't replacing SREs, it's deskilling them, SigNoz newsletter.*