When AI takes the routine incidents, the hard ones need deliberate practice

If AI handles the routine incidents, the people left on call get fewer chances to practice and the same responsibility for the failures that matter most. That is the argument the observability company SigNoz makes in a post titled "AI Isn't Replacing SREs. It's Deskilling Them." It is an opinion piece, not a study, and I will treat it that way. I also think it is right about the part that matters for incident response, and the fix it points toward is something security teams already know how to run.

The argument SigNoz is making

SigNoz builds on Lisanne Bainbridge's 1983 paper, "Ironies of Automation," which it describes as one of the most cited papers in human factors research. In SigNoz's summary, Bainbridge found that the more you automate a process, the more the human operator matters during the rare moments the automation fails, and the less practice that operator gets for exactly those moments.

SigNoz then draws the parallel to site reliability work. AI tools already group alerts, run runbooks for known issues, flag log anomalies, and suggest root causes from past incidents. The post describes a tiered model it attributes to PagerDuty: known issues get fully automated, partially understood ones get AI recommendations with human validation, and novel, cascading failures stay human-led. Then it asks the uncomfortable question. If people only touch the novel failures, where do they build the intuition to handle them?

The post names two versions of the problem. Deskilling is losing a skill you once had because you stopped exercising it. Never-skilling is never building it at all, which is the risk for people who start their careers after the routine work has already been automated away. SigNoz also makes a point I find the most useful: the decline is hard to feel from the inside, because AI makes the work feel easier and the dashboards stay green.

Why this lands harder in security incident response

SigNoz writes about reliability engineers, but the shape of the problem carries over to security operations. Alert triage, enrichment, and known-pattern response are the first things teams hand to automation. They are also the work where analysts used to learn what normal looks like, how to read raw logs, and when a small anomaly deserves a second look.

Security has one extra wrinkle. In a reliability outage, the system is failing on its own. In a security incident, someone may be actively trying to look like the routine case. The incidents least likely to match a known pattern are the ones where a human has to form a hypothesis, test it, and decide under pressure with incomplete information. Those decisions do not get easier because an assistant handled the last two hundred phishing reports well.

There is also the decision layer above the analyst. Isolating a system, taking a service offline, calling outside counsel, notifying a regulator, talking to the press: none of that is automated, and most leadership teams do it rarely. I wrote about what a health system asks before reconnecting a vendor in what a hospital will ask before it reconnects your integration. Those are human calls made under time pressure, and they are exactly the kind of skill that fades without practice.

Deliberate inefficiency, applied to the response team

SigNoz's main suggestion is what it calls deliberate inefficiency. It compares this to manual flying time for pilots: teams can set aside some incidents the AI could handle and work them by hand, as a long-term investment in skill even when it costs speed. Its second suggestion is to build for a human actively working the problem alongside the AI, not a human who only approves its recommendations, because passive approval is the supervisory role Bainbridge's work warns about.

For a security team, I would turn both ideas into concrete habits:

• Pick a small, regular sample of alerts the automation closed and have an analyst work them from raw telemetry, then compare their conclusion to the automated one.
• When the AI suggests a root cause during an incident, ask a person to state their own hypothesis first, before reading the suggestion.
• Rotate who runs the manual path, so the skill does not live in one senior person who then goes on vacation.
• Track the disagreements. The cases where a human and the automation reached different answers are the training material.

None of this means pulling AI out of the workflow. SigNoz is clear that it is not arguing against AI tooling, and neither am I. The point is to decide on purpose which skills you are willing to lose and which ones you need to keep.

Tabletops are practice reps, not compliance artifacts

The cheapest place to practice the rare, hard incident is a room where nothing is actually broken. That is what a tabletop exercise is for. I have run tabletops, and the useful ones feel less like an audit and more like a scrimmage: a realistic scenario, injects that change the picture at awkward moments, and people who have to say out loud what they would do and who they would call.

Tabletops fit the deskilling problem well for three reasons. They target the decisions automation does not make, such as containment trade-offs, escalation, and communication. They are repeatable, so you can run the same failure for a new analyst who has never seen it in production. And they expose the gap SigNoz describes, where everyone feels competent until the scenario stops matching the playbook.

Two design choices make them work better when AI is in the response path. First, include the AI as a participant with failure modes: the assistant suggests the wrong root cause, or its summary leaves out the one log line that matters. Second, run at least one inject where the automation is unavailable and the team has to work from raw data. I covered why evidence of a fix needs a retest in the Detection Evidence Framework post. The same logic applies to people. A skill is current when you have watched it work recently.

Where to start this month

Pick one incident type your automation now handles end to end. Ask who on your team last worked one by hand, and when. If nobody can answer, that is your first practice scenario.

Then schedule a single short tabletop around a failure that does not fit your playbooks, and include a moment where the AI assistant gets it wrong. If you want a starting point, the free AI tabletop exercise kit from Cyber Defense Tactics has one ready-to-run scenario with a facilitator guide.

The question to take back to your team is simple. When the incident does not match anything the automation has seen, who is ready to think it through, and how would you know?