An essay by Sylvain Kalache, AI Labs lead at Rootly and a former LinkedIn SRE, spent 4 September on the Hacker News front page and collected 396 points and 338 comments for one uncomfortable claim: the better AI gets at resolving routine incidents, the less practice human responders get at resolving anything. The thread split roughly into people who called it nostalgia and people who have been on call recently.
Both sides skipped the part that matters commercially. The number you use to prove your incident response is working has quietly stopped measuring incident response.
TL;DR
- Mean time to restore is now an average over two populations that have separated: incidents the automation closes in minutes, and incidents a human handles with less practice than a year ago. The aggregate improves while the capability degrades.
- Lisanne Bainbridge published the argument in 1983. Her conclusion, usually left out of the summaries, is that automating a system means operators need more training, not less.
- Tier-one incidents were never just noise. They were the apprenticeship that produced people who could handle tier three, and they are the first thing agentic tooling takes away.
- DORA’s 2026 ROI model prices a rise in change failure rate, from 5% to 6%, into its positive case. More incidents are arriving at a rota with less practice.
- Aviation bought the offset with mandated recurrent simulator checks. Software automated the same way and bought nothing.
A 1983 paper already wrote this post
Lisanne Bainbridge’s “Ironies of Automation” ran to five pages in Automatica (volume 19, issue 6, pages 775 to 779) and has been cited for four decades mostly by people who read the title. The argument has two turns. First, the designer automates whatever can be automated and leaves the operator whatever was too hard, so the human’s remaining job is by definition the difficult residue. Second, the human is then asked to supervise the automation, a task that requires exactly the fluency that supervising instead of doing removes.
Her conclusion is the part that gets dropped: an automated system needs its operators trained more heavily than a manual one, because their entire remaining function is the rare intervention. We have rebuilt her control room in Slack and kept none of the training.
Your mean is an average of two different populations
Work the arithmetic, because it is the whole argument.
Last year your team took 100 incidents in a quarter, every one of them handled by a person, mean time to restore 45 minutes. This year an agent triages, correlates and auto-remediates 70 of them at a mean of 4 minutes. The remaining 30 go to a human, and that human takes 70 minutes. Your reported figure is (70 × 4 + 30 × 70) / 100, which is 23.8 minutes. You have almost halved MTTR. It will be on a slide by Friday.
The human-handled number went from 45 minutes to 70. Nobody is looking at it, because nobody computes it. A single mean over a bimodal distribution is not a summary, it is a disguise, and the direction of the disguise is always flattering.
There is an honest confound here, and it should be stated rather than sold around: the 30 incidents left to humans are selected for difficulty, so some of that 45 to 70 rise is composition rather than decay. You cannot separate the two from production data, because the population changed at the same moment the practice did.
Which is precisely why the fix is a measurement, not an exhortation. A simulated incident holds composition constant. If you run the same scenario against the same rota twice a year, the only variable left is the responder, and you get a number production telemetry structurally cannot give you.
Tier one was the apprenticeship
Ask any senior responder how they learned a system and you will not hear “the architecture diagram”. You will hear about a year of boring pages: the disc that filled, the certificate that expired, the retry storm, the deploy that half-rolled. Individually tedious; collectively the only mechanism most organisations had for turning a competent engineer into someone who could hold a novel outage in their head at 3am.
Agentic incident tooling removes tier one first, because tier one is the easiest thing to automate. The pipeline that produced tier-three responders has never been a line item in anyone’s business case, so it was decommissioned as a cost saving and recorded as a productivity gain.
This bites hardest at the size most of our clients are. A 400-engineer platform team can absorb the loss of a few years of incident exposure. A six-person rota supporting a revenue-critical product cannot, because the person who would have grown into the deep-systems responder is the same person the automation is currently doing the learning for.
The clause in your support agreement that changed hands
If you sell managed hosting, a support retainer or an SLA-backed service, look at what your response and resolution targets are actually being met by now. In a growing number of cases the answer is a vendor’s model, invoked by a workflow nobody on your side has read in six months.
Two things follow. You are contractually promising a capability you are no longer exercising, and the tooling meeting that promise is a dependency you did not procure, cannot version-pin behaviourally and did not negotiate an SLA with, which is the same shape as the resolver nobody at your company chose and the model supplier sitting behind your coding tools. When the vendor changes the model, your contractual obligation does not change with it.
There is a regulatory edge too, and it is not the clock. Under NIS2 the reporting duty attaches when an entity becomes aware of a significant incident, and awareness implies somebody classified it. An incident that self-heals at 02:14 and closes its own ticket produces no timeline, no root cause and no human who formed a view on significance. We have covered the deadlines themselves elsewhere; the point here is that auto-remediation deletes the input they run on.
Aviation paid for the offset
The aviation comparison gets made constantly and almost always stops one step early. Modern turbine engines record fewer than one in-flight shutdown per 100,000 engine flight hours, and automation is a large part of why. It won that argument decisively.
It won it while also producing TransAsia Airways Flight 235, where an uncommanded autofeather on the number two engine was met by the crew shutting down the number one engine, the one still producing power. Forty-three people died. The cockpit voice recorder caught “Wow, pulled back wrong side throttle” eight seconds before impact.
Aviation’s response to that class of failure was not less automation. It was recurrent simulator checks, mandated at fixed intervals, with a licence attached to passing them. The industry accepted that if you take routine practice away from an operator you have to buy it back deliberately, and it wrote the cost into the operating model.
Software adopted the automation and skipped the invoice. There is no recurrent-competency requirement anywhere in normal engineering practice, and on-call readiness is typically a wiki page and a paging-tool test. None of which is an argument for keeping humans on tier one out of sentiment: automating routine incident response is correct and the aggregate reliability gain is real. The claim is narrower and harder to dismiss. The offset has a price, aviation pays it, and almost nobody in software has costed it.
The direction of travel is not encouraging either. DORA’s 2026 report on the ROI of AI-assisted software development models change failure rate rising from 5% to 6% after adoption, and books roughly $344,000 of negative downtime impact against the gains. That is the optimistic scenario, written by people arguing for adoption: more incidents, arriving at a rota that gets less practice than it used to.
Four changes worth making this quarter
- Split the metric. Report MTTR for human-handled incidents separately from the aggregate, alongside the share of incidents closed without human involvement. Auto-resolve share rising while human MTTR rises is the signature of this problem, and it is invisible in a single number.
- Put a repeatable scenario on the calendar. Twice a year, same scenario, same rota, timed, for the reason above: it is the only measurement that tells you about the responders rather than the queue.
- Make the automation file a timeline. Require every auto-resolved incident to produce a written narrative, and require the on-call engineer to read and sign it. A weak substitute for doing the work, and far better than a closed ticket nobody opened. It also restores the classification decision your reporting obligations depend on.
- Keep a class of incident manual on purpose. Pick one recurring, genuinely low-risk failure mode and leave it to humans. Treat the time cost as training spend, because that is what it is, and it is cheaper than the alternative.
Need help building this? REPTILEHAUS builds and runs production systems under support agreements where the response targets have to survive a real outage. If your incident metrics look better than your last hard incident felt, get in touch.
📷 Photo by Andrés Dallimonti on Unsplash
