When AI Handles the Easy Incidents, How Do You Keep Your Troubleshooting Skills Sharp?

A field note on keeping incident skill on purpose. Sources checked Nov 6, 2026.

The short version

A lot of on-call work now starts the same way. The alert fires. Somebody pastes it into a chat bot. The bot suggests a restart, a rollback, or a known runbook. The page clears. The board goes green.

That loop is fine for the pages that match a pattern. The trap is quiet. You stop writing your own hypothesis. You stop opening the raw logs. You stop building a map of how the system actually fails. The day a novel failure shows up, the bot has no pattern, and you have less practice than the dashboard makes it feel like you do.

This note is not an anti-AI rant. Auto-remediation for known failures still belongs in production. The question is how you keep the skill that the rare failure still needs. Below is the reasoning path an operator uses by hand, the research frame that explains why that skill fades, and three drills you can run tonight without buying anything.

Why this is spreading again

On Feb 28, 2026, Elizabeth at SigNoz published AI Isn’t Replacing SREs. It’s Deskilling Them. The piece asks a better question than the usual prophecies. Not “will AI take the SRE job,” and not “SRE is the last safe job.” When AI handles most incident responseThe structured process of detecting, containing, eradicating, and recovering from a cybersecurity incident to minimize damage and prevent recurrence. Read more →, do you get worse at the remainder?

The essay resurfaced on Hacker News on Oct 30, 2026 as item 50305693. As of this morning (Nov 6) the Firebase score sat at 684 points with 509 comments. Earlier posts of the same URL in Feb and Mar 2026 barely moved. The Oct resurface is what made it worth a field note.

SigNoz builds observability tooling, so the essay ends with a product pitch. Steal the teaching frame. Skip the CTA.

The ironies, from the primary paper

The SigNoz piece leans on Lisanne Bainbridge’s 1983 brief paper Ironies of Automation (Automatica Vol. 19 No. 6, pp. 775-779). I opened the PDF before writing this. The abstract thesis is plain: automation of industrial processes may expand, rather than eliminate, problems with the human operator. The more advanced the control system, the more critical the human contribution becomes in abnormal conditions.

Two ironies from the paper matter for on-call work:

1. Designers who try to eliminate the operator still leave the operator the tasks they could not figure out how to automate. Those leftover tasks are often the hard, irregular ones.
2. Physical and cognitive skills deteriorate when they are not used. A formerly experienced operator who has been monitoring an automated process may now behave like an inexperienced one when take-over is required. Bainbridge is explicit that when manual take-over is needed, something is likely already wrong with the process, so the operator needs more skill, not less, and less load, not more.

She also flags vigilance: even a motivated person cannot maintain effective visual attention toward a quiet information source for more than about half an hour. Monitoring “that the automatics are fine” is a worse job than it looks on a org chart.

Bainbridge wrote about process plants and flight decks. The mapping to chat-assisted incident response is analogy, not proof. Treat it as a frame for practice design, not as a measured SRE statistic.

Terms worth pinning down

• SRE (site reliability engineering): the craft of keeping production systems up, measurable, and recoverable. Not “the person who restarts the box.” The person who designs how failures are found and fixed.
• Deskilling: you once could do the hard path by hand. After months of handing the first pass to a tool, you get rusty.
• Never-skilling: juniors who never built the intuition because the tool always did the first pass. SigNoz uses this word. Keep it attributed to that essay.
• Human-in-the-loop: you still form the hypothesis and use the tool as a check.
• Human-on-the-side: you mostly approve or reject the tool’s answer. Bainbridge’s vigilance point lands hardest here.
• AI-off drill / game day: a planned exercise where you solve a real or staged incident with the assistant closed, then compare.

The SigNoz subtitle uses a “95% / 5%” split. That is rhetoric, not a measured SRE workload. Do not treat it as data. Same for secondary claims in that essay about endoscopy detection rates and FAA orders. Those need their own primary papers before they belong in a BytesNation note. I left them out.

How an operator reasons through an incident by hand

This is the original element of the note. Walk one failure without pasting anything into a bot. Then, only at the end, compare.

I will use a concrete shape many homelab and production readers already know: an APIA set of rules and protocols that allows different software applications to communicate with each other and share data or functionality. Read more → latencyThe time delay between sending a request and receiving the first byte of the response, typically measured in milliseconds. Read more → page that spikes after a deploy window. SwapDisk space the operating system uses as overflow when physical memory (RAM) fills up, at the cost of being much slower than RAM. Read more → in your own signals. The sequence stays the same.

1. Write the signal in one sentence

Alert text: p99 latency on payments-api > 800ms for 5 minutes in us-east-1.

Your sentence, on paper or in a scratch doc: “Payments API in us-east-1 has been slow for five minutes.”

Do not open the assistant yet. The point of this step is to force a plain claim you can later falsify.

2. Check scope with a second signal

If the alert came from metrics, open logs or a trace. If it came from logs, open a dashboard that is not the alert’s source.

Ask: one host, one region, one customer, or everything?

Example checks:

# Is the spike only us-east-1, or also us-west-2?
# Replace with your own metrics CLI or UI. The habit matters more than the tool.

In a homelab version of the same drill, that might be: is only jellyfin unhealthy, or are caddy and postgres also complaining?

If your only view of the system is an AI summary panel with no one-click path to raw logs, traces, and deploy markers, fix that first. Deskilling accelerates when raw signals are annoying to reach.

3. Build a hypothesis board before you remediate

Write two or three causes. Rank by “what would kill this fast.”

For the latency page:

You are not looking for a clever answer. You are looking for the cheapest test that would make the top row false.

4. Falsify the top row

Run the smallest check. Example for “bad deploy”:

# Illustrative. Use your deploy tool's real commands.
kubectl -n payments get deploy payments-api -o jsonpath='{.spec.template.spec.containers[0].image}{"\n"}'
# Compare image tag / digest and change time against the alert's first fire.

If the running image matches the last known-good and the change time is hours earlier than the spike, drop that hypothesis. Move to the next row. Do not restart yet just because restarts often work.

5. Name the blast radius before you act

Before restart, rollback, scale, or failover, say out loud (or write) what else that action can break.

• Restarting payments-api: in-flight charges, webhookAn HTTP callback that automatically sends data to a URL when a specific event occurs, enabling real-time communication between applications. Read more → retries, cache warm-up cost.
• Rolling back: whether the new schema migration is backward compatible.
• Scaling pods: whether the DB connection pool will melt under more clients.

This step is the one chat bots skip when they jump to “have you tried restarting.”

6. Apply the change and write what you expect to see

Only now remediate. Write the expected after-state before you click.

“After rollback to image payments-api:1.48.2, p99 in us-east-1 should fall under 300ms within five minutes, and error rate should stay flat.”

If the after-state does not match, you have a new signal. You did not “fix it and hope.”

7. Optional AI compare

Now paste the same facts you already gathered into your usual assistant. Note three bullets:

1. What you both got.
2. What you caught that it missed.
3. What it suggested that you cannot defend from the evidence.

That delta is the learning log. The assistant is a second opinion after you have a board, not a first pass that replaces the board.

For a worked example of “hypothesis then measure” on a different problem, see our earlier note Your CPU Says 100%. It Might Be Waiting on RAM the Whole Time. Same habit, different layer of the stack.

What the SigNoz tier sketch gets right, and where it bites

The essay sketches a PagerDuty-style split:

• Tier 1: known issues with known fixes, automated.
• Tier 2: AI suggestions with human check.
• Tier 3: novel, cascading failures, human-led.

The catch they name is the right one. If humans only ever see Tier 3, where does the intuition come from? Intuition is repetition under feedback. Strip the reps, and Tier 3 gets harder even as Tier 1 gets faster.

Auto-remediation of Tier 1 is still good engineering. The design question for a team is how juniors still get reps, and how seniors keep them. Bainbridge’s process-plant point maps cleanly here: the most successful automated systems, with rare need for manual intervention, may need the greatest investment in operator training.

Three drills you can run at zero cost

Pick two. Put them on a calendar. Do not wait for a perfect game-day framework.

Drill 1: solve-then-compare on one ticket a day

For one closed or open ticket:

1. Your answer first, written in five lines: signal, scope, top hypothesis, falsifier, fix.
2. Assistant second, on the same facts.
3. Three bullets in an “AI miss log”: agree, you caught, it guessed.

Homelab version: failed backupA copy of data stored separately from the original, used to restore systems and files after data loss from hardware failure, deletion, ransomware, or disaster. Read more → job, disk full, containerA lightweight, portable package that bundles an application with its dependencies and runs in an isolated process on the host OS, sharing the kernel. Read more → crash loop. Same five lines.

Drill 2: monthly AI-off game day

Take one recent Sev2 or Sev3 that the bot would have crushed. Replay it from raw signals with AI tools closed. Timebox 45 minutes. Write what you missed.

Airlines already treat “autopilot flew the easy hours, then handed back a messy approach” as a training problem. You do not need an FAA order number to copy the practice pattern. You need a closed ticket and a timer.

Drill 3: hand-run one familiar runbook

Once a month, execute a runbook you trust without the auto-remediation path. Note which steps the automation hides: auth, ordering, verification, “who gets paged if step 4 fails.”

Those hidden steps are exactly what you will wish you remembered at 3am when the automation path is the thing that is broken.

What a senior engineer should take from this

• Skill decay shows up in other domains. Do not invent a percentage for SRE without a study.
• Never-skilling is the sharper long-term risk for teams hiring juniors into AI-first on-call.
• Observability that only feeds an AI summary, without easy access to raw signals, accelerates the problem.
• Vendor AI-SRE tools that sit on top of your telemetry through an API see a thinner view than tools that sit on the data itself. That is architecture context from the SigNoz essay, not a product ranking from us.
• Deliberate inefficiency is a feature. Handling some AI-solvable incidents by hand is practice, not waste.

First step tonight

1. Pick one closed ticket from the last two weeks that your assistant helped resolve. Homelab failure counts.
2. Open only the raw alert, the deploy marker, and the logs or traces. Close the chat bot.
3. Rebuild the timeline in 15 minutes: signal, scope, hypotheses, falsifying checks, fix, verification.
4. Reopen the assistant transcript. Write three bullets: what you both got, what you caught that it missed, what it suggested that you cannot defend.
5. Put those three bullets in a running “AI miss log.”

No paid API. No new SaaS. No kit.

If you want a BNLC lesson that matches this drill exactly, we do not have one yet. The closest live Field Note for the “hypothesis then measure” habit is the CPU waiting on RAM note. Tomorrow’s WireGuard lab on BytesNation is a different kind of practice: build the tunnel, then try to leak around it.

Sources

• Elizabeth, SigNoz newsletter, Feb 28, 2026: AI Isn’t Replacing SREs. It’s Deskilling Them (read Nov 6, 2026).
• Hacker News item 50305693, resurfaced Oct 30, 2026. Score checked via Firebase API morning of Nov 6: 684 points, 509 descendants.
• Lisanne Bainbridge, Ironies of Automation, Automatica 19(6), 1983, pp. 775-779 (PDF opened Nov 6, 2026).
• BytesNation, Your CPU Says 100%. It Might Be Waiting on RAM the Whole Time (live Nov 4, 2026).