AI Is Not Replacing SREs, It Is Deskilling Them

A viral debate on Hacker News argues that AI is not replacing site reliability engineers. It is deskilling them. The post that sparked the discussion scored 512 points with 385 comments on 31 October and made the top of the trending AI digest. The concern is that automation that writes runbooks, suggests fixes and closes incidents is also eroding the debugging judgment that on call needs when automation fails.

The details here come from the Signoz newsletter essay AI is not replacing SREs, its deskilling them, Hacker News discussion on 31 October, the METR trial that found experienced developers were 19 percent slower using AI tools, and the post mortem culture I have seen in teams that run the same tooling.

What does deskilling mean for an SRE?

Deskilling describes the same number of SREs with less practice at the tasks that matter in an incident, not a reduction in headcount.

An SRE who once read a flame graph, checked ss -s, and traced a slow query through EXPLAIN ANALYZE now accepts a summary from a chat panel. The summary is often correct. When it is wrong, the engineer has less recent practice at the manual path to notice.

The METR trial makes the same point with numbers. Experienced developers were 19 percent slower using AI tools despite perceiving a speed increase. The speed is felt at the start. The slowdown appears in verification. I have seen this on call. The SRE who debugged three incidents with an AI generated runbook can describe what the runbook did, but not why the third step was there.

What did the essay actually argue?

The essay does not argue against automation. It argues that automation that hides reasoning encourages dependency on black box tools. One camp says AI will free SREs to focus on architecture. The other says AI will make it harder to hire SREs who can debug without the tool. According to Signoz, the top reported benefits are improved documentation, test coverage and debugging, and refactoring.

How does this show up in real incidents?

The pattern I see in post mortems is quiet. The runbook is correct, the AI summary is plausible, and the incident still extends because the team follows the summary past the divergence.

I reviewed an incident last quarter where an AI generated runbook suggested restarting a stateful service as the third step. The service had a warm cache that took 12 minutes to rebuild. The restart fixed the symptom for 12 minutes and then the latency spike returned worse. The manual runbook had the same step but included a note: do not restart before checking cache hit ratio. That note was the judgment. The generated runbook did not carry it.

What should teams keep manual on purpose?

The answer is not to stop using AI. It is to keep a small set of tasks manual on purpose so the skill does not atrophy.

• Keep the post mortem interview manual. Write the timeline from the data, not from the summary. The discipline of reconstructing the incident from logs, traces and metrics is the practice that builds judgment. I now treat the post mortem as a debugging exercise and require the author to list the hypotheses that were considered and rejected, as described in what makes a postmortem useful.
• Keep one live debugging path that does not use the chat panel. For a latency spike, that path might be strace for web developers, bpftrace one liners, or reading a flame graph without the profiler agent. The goal is to keep the manual path practiced so it is available when the agent is wrong.
• Keep the runbook as a decision log, not as a script. The runbook should state the condition for each step, not just the step. That condition is the judgment that deskilling removes.

I run untrusted agent workloads in isolated microVMs at Krova Cloud where we can afford to let the agent suggest a fix and still require a human to approve the step that restarts state. The isolation that helps us debug kernels also helps us keep a human in the loop where the step is irreversible.

What is the verdict and what remains uncertain?

According to the Hacker News discussion on 31 October, the community is divided between those who see AI as freeing SREs and those who see it as eroding the expertise that SRE hiring depends on. According to METR, the perceived speed increase co exists with a measured 19 percent slowdown for experienced developers.

The verdict is that the deskilling risk is real, but it is not a replacement story. It is a training story. Teams that let AI do all of the debugging will have SREs who can describe what was done, but not why. Teams that keep a manual debugging practice will have SREs who can do both.

The limitations are threefold. First, the 19 percent METR figure is from a trial, not from production on call, so the transfer to incident work is inferred. Second, the 512 point Hacker News thread is a community sentiment signal, not a hiring study, so it should not be read as a labor market forecast. Third, the Signoz essay's positive impacts are from surveys, so they measure perception among developers who chose to use AI, not a random sample.

FAQ

Should we stop using AI for on call?

No. Use it to reduce toil, but keep the post mortem and one live debugging path manual. That is the pair that protects judgment.

Does this mean juniors should not use AI?

Juniors benefit most from pairing on the rejected hypotheses, not from reading the generated answer. The tool is fine as a tutor, but the learning comes from the hypotheses that were considered and rejected.

What is the first change to make this week?

Pick one incident type and require the post mortem to list the three hypotheses that were considered and rejected, plus the condition for each runbook step. That artifact is the judgment that deskilling removes.

Published on debugly.dev by Rohit Bhadani | Founder of Krova Cloud

Published on debugly.dev by Rohit Bhadani | Founder of Krova Cloud