Rootly's Sylvain Kalache published an essay on September 4, 2026 arguing that AI-assisted incident response is quietly de-skilling site reliability engineers — and it hit 204 points and 180 comments on Hacker News within hours. The argument leans on a genuinely important, 40-year-old piece of human-factors research, wrapped around an aviation analogy that the comment section took apart with real precision, and pointed toward a solution that happens to be the product Kalache's own company sells.
All three of those things can be true at once, and untangling them is more useful than either dismissing the essay as a pitch or accepting the aviation comparison uncritically.
TL;DR
| Question | Answer |
|---|---|
| Core claim | AI resolving routine incidents removes the practice engineers need to build intuition, leaving them under-prepared for the rare, hard incidents that remain |
| The research behind it | Lisanne Bainbridge's 1983 paper "The Ironies of Automation" — real, foundational, not AI-era invention |
| The analogy used | Airline pilots train in simulators for rare failures (FAA-mandated every 6 months) |
| Where the analogy breaks | Aviation training is legally mandated for a stable failure taxonomy; software incidents have neither regulation nor stability, and SREs (unlike pilots) usually built the system themselves |
| The proposed fix | Realistic incident simulations — which is also Rootly's own product, built with partner Uptime Labs |
| Best HN counter-proposal | Use AI's own incident-diagnosis trail as training material for practicing hypothesis-formation, no product purchase required |
| Our take | The paradox is real and well-evidenced; the prescription is reasonable but self-interested — read the diagnosis and the pitch as separable |
The research is real, and it predates AI by 40 years
The most solid part of Kalache's essay is the part he didn't invent. Lisanne Bainbridge's 1983 paper, "The Ironies of Automation," is a genuinely foundational text in human-factors research — not a fringe theory retrofitted to fit an AI narrative. Her core finding: automation systematically removes an operator's opportunities to practice routine work, while simultaneously leaving that same operator responsible for the novel, abnormal situations automation can't handle. The paradox is that this means operators need to be more skilled after automation than before it, even as automation reduces their day-to-day chances to build that skill.
That's not a hypothesis about AI specifically — it's a documented pattern from decades of studying automated cockpits, control rooms, and industrial systems, and several Hacker News commenters (intended, among others) correctly pointed out that this framing is doing real, citable work rather than being a rhetorical flourish. Kalache's contribution is applying an established paradox to a new domain (AI-assisted incident response), which is a legitimate and useful thing to do — the paradox itself isn't new, and treating it as an AI-era discovery would undersell 40 years of prior research.
Where the aviation analogy holds, and where it doesn't
Kalache's use case is vivid: modern turbine engines see fewer than one in-flight shutdown per 100,000 flight hours, rare enough that a career pilot might never see one outside a simulator — yet pilots must complete FAA recurrent training or a proficiency check every six months, rehearsing exactly these rare failures. It's a genuinely good illustration of "keep practicing for events you'll almost never encounter."
Where the comment section pushed back is worth taking seriously rather than waving away. User iLoveOncall made the sharpest structural objection: pilots don't build the aircraft they fly, while the engineers resolving a software incident are frequently the same people who built (or maintain) the system in question — a fundamentally different relationship to the failure modes involved. And solatic raised the harder practical point: aviation gets mandated simulator training because it's a licensing requirement, enforced by a regulator, not because airlines volunteered for it. Software engineering has no equivalent license, no equivalent regulator, and — as solatic put it — companies already didn't bother practicing backup restoration, disaster recovery, or runbook rehearsal before AI existed, for the same underlying reason a voluntary incident simulator will struggle to get budget now: no executive is excited about paying for practice that produces no visible feature.
That's a real, structural critique of the proposed solution, not just a rhetorical jab — and it applies whether or not you buy into the AI-specific framing at all.
The part that's also a product pitch
Here's the detail worth stating plainly rather than skating past: Kalache is the AI Labs lead at Rootly, an incident-response platform, and the essay's concrete recommendation — realistic incident simulations, built in partnership with Uptime Labs — is a real product Rootly sells. The essay walks through a specific simulated e-commerce outage exercise where engineers take the incident-commander seat, using observability tools while coordinating with LLM-powered stakeholders in Slack.
That doesn't invalidate the underlying diagnosis. Bainbridge's paradox doesn't become less true because the person citing it also sells a countermeasure. But it does mean the specific prescription — "buy a simulation platform" — deserves exactly the scrutiny any vendor's "the fix happens to be what we sell" argument earns anywhere else, and readers evaluating whether to act on this essay should separate the (well-evidenced) problem from the (self-interested) solution before deciding what to actually do about it.
The strongest alternative came from the comments, not the essay
Commenter king_phil offered the most substantive counter-proposal in the whole thread, and it doesn't require anyone to buy anything: the actual SRE skill under threat isn't mechanical log-grepping or dashboard-browsing — AI is legitimately better and faster at that — it's forming and testing hypotheses about why a system is failing. If that's the real skill, then an AI incident report that shows its full investigation trail (what it checked, what it ruled out, why it settled on a diagnosis) can itself become training material for practicing exactly that hypothesis-formation skill, on real incidents, without a dedicated simulation product at all.
This connects directly to a pattern explainx.ai has tracked across several related debates this year. Our coverage of Lars Faye's "AI Coding Will Prevent Expertise" essay found the same expert-novice paradox in day-to-day coding, not just incident response: AI skips the productive friction that builds taste and judgment. And the cognitive-debt retyping debate — where one proposal was literally "manually retype every LLM-generated line" — sits at the extreme end of trying to force that friction back in artificially. King_phil's suggestion is a middle path: keep the friction that's already being generated as a byproduct (the AI's own reasoning trail) rather than manufacturing new friction or paying for a simulator to recreate it.
A term worth being precise about: comprehension debt vs. cognitive debt
Kalache's essay introduces "comprehension debt" — the growing gap between how a system actually works and how well the humans responsible for it understand it. It's a useful, specific term, and worth distinguishing from the adjacent "cognitive debt" concept explainx.ai covered in the MIT "Your Brain on ChatGPT" study discussion, which is about an individual's own reduced cognitive engagement while producing output, not necessarily an organization's collective loss of system understanding. They're related — both describe atrophy that compounds silently — but "comprehension debt" is closer to institutional/team-level knowledge loss, while "cognitive debt" as MIT's researchers used it describes an individual's reduced neural engagement during the task itself. Worth keeping distinct rather than treating as interchangeable synonyms, since the fixes for each look different: comprehension debt needs deliberate knowledge-transfer practices across a team; cognitive debt needs an individual to change how they personally engage with a task.
What actually seems worth doing, regardless of the vendor angle
Stripping out the specific product pitch, three practical takeaways survive the comment-section scrutiny:
- Treat every AI-resolved incident's diagnosis trail as a mini case study, not just a closed ticket. If the AI found the root cause, read how it got there — what it ruled out, what evidence it weighted, where it could have gone wrong. This is king_phil's insight and it costs nothing beyond attention.
- Deliberately rotate humans back onto routine incident response, even when AI could resolve it faster. This is the same logic behind chaos engineering and game days, which several commenters correctly noted already existed pre-AI and were already underfunded — AI raises the stakes on an old, chronically neglected practice rather than inventing a new problem from scratch.
- Watch for the specific moment "AI resolved it, nobody looked at why" becomes the unquestioned default. That's the point where comprehension debt stops being a slow leak and starts compounding — the same silent-accumulation pattern explainx.ai has covered in AI-driven de-skilling among developers more broadly and in Andrew Ng's case for keeping software engineering fundamentals alongside agentic coding.
Honest limitations
- Bainbridge's own 1983 paper is more cautious about simulation than Kalache's essay implies. Commenter gnfargbl pointed to section 2.3 of the original paper, which lists specific reasons simulation training can be an imperfect substitute for real operational experience — a nuance the essay's confident framing glosses over.
- No data from Rootly's own deployments accompanies the essay. The Uptime Labs simulation exercise is described qualitatively ("the result feels real"), not backed by before/after incident-resolution metrics from teams that have adopted it.
- The essay's central prediction — MTTR falling for routine incidents while resolution time rises for complex ones — is a forecast, not a measured result. It's a reasonable inference from the Bainbridge paradox, but it hasn't been observed and quantified in the essay itself.
- This is one essay and one comment thread, not a systematic study of AI-SRE adoption across the industry. Treat the specific numbers and scenarios as illustrative rather than representative.
Related on explainx.ai
- Lars Faye: AI coding will prevent expertise — what the studies say
- AI-driven de-skilling: why vibe coding is producing developers who cannot debug
- Should you manually retype LLM-generated code? The HN cognitive-debt debate
- Andrew Ng: keep software engineering fundamentals alongside agentic coding
- AI mania is eviscerating decision-making — Ludicity's Hermit Tech essay decoded
- Should developers stop reviewing AI-generated code?
- Why "Applied AI" keeps failing at large companies
Primary sources: Sylvain Kalache — "AI handles incidents, engineers lose touch with their systems," September 4, 2026; Hacker News discussion, 204 points; Lisanne Bainbridge, "The Ironies of Automation" (1983).
This post reflects Sylvain Kalache's essay as published September 4, 2026 and the Hacker News discussion under it as of September 5, 2026. Kalache's affiliation with Rootly and its Uptime Labs partnership is disclosed in the essay itself; this post's analysis of that commercial context is explainx.ai's own editorial addition.