What changes for site reliability engineering with AI?

The shift

Diagnosing an incident — correlating logs, metrics, traces, recent deploys, and past postmortems into a ranked list of likely causes — goes from scarce senior-engineer pattern-matching under pressure to abundant, near-instant synthesis available to anyone on the page.

The axioms

• On-call engineers are valuable because they hold tribal knowledge of the system in their heads. Rests on institutional memory being scarce and undocumented.
• Diagnosing an incident requires an expert to manually correlate dashboards, logs, and traces. Rests on cross-signal synthesis being slow, human-paced work.
• Runbooks and postmortems are written after the fact because writing them well takes time nobody has mid-incident. Rests on documentation being expensive relative to firefighting.
• Toil (manual, repetitive ops work — restarts, scaling, log-scraping, ticket triage) has to be absorbed by headcount. Rests on routine operational execution being labor, not automation.
• Paging a human is the only reliable way to get a fix applied at 3am. Rests on judgment and remediation authority being inseparable from a person.
• Capacity planning and anomaly detection depend on an engineer noticing a trend before it becomes an outage. Rests on pattern-spotting across noisy telemetry being scarce attention.
• The org trusts a human to decide when a system is safe to bring back and who's accountable if it isn't. Rests on accountability and liability requiring a person.
• SLOs and error budgets only work if someone owns the tradeoff between velocity and reliability. Rests on judgment about acceptable risk being a human call.

Invalid axioms

1. On-call engineers are valuable because they hold tribal knowledge in their heads. Institutional memory — what broke last time, which service is flaky, what the fix was — is exactly what an LLM with access to past incidents, runbooks, and chat history can retrieve and synthesize instantly. The habit-trap: teams still treat "knows the system's history" as a reason to route every page to the same two senior people, instead of feeding that history into a system anyone on rotation can query.
2. Diagnosing an incident requires an expert to manually correlate dashboards, logs, and traces. Cross-referencing metrics, logs, traces, and recent deploys into a ranked hypothesis list is pattern-matching against structured data — abundant now. The habit-trap: paging the most senior engineer first "because they'll figure out the correlation fastest," when a model can produce the same correlation in seconds and let anyone act on it.
3. Runbooks and postmortems are written after the fact because writing them well takes time nobody has mid-incident. Drafting a clear, structured postmortem or runbook update from a timeline of Slack messages, alerts, and commands is now a near-free first draft. The habit-trap: still budgeting a week of someone's time to write up an incident, when the bottleneck should just be review and sign-off.
4. Toil has to be absorbed by headcount. A large share of toil — restarting known-flaky services, scaling responses to predictable load, triaging and routing tickets, writing the first-pass remediation script — is exactly the repetitive, pattern-bound work AI automates well, especially as agentic tool-use matures. The habit-trap: sizing on-call rotations and ops headcount for a volume of manual toil that's shrinking.
5. Capacity planning and anomaly detection depend on an engineer noticing a trend before it becomes an outage. Spotting a slow memory leak or a gradual latency creep across weeks of noisy telemetry is synthesis at scale — AI does this continuously and doesn't get bored or distracted. The habit-trap: still relying on a human dashboard-watcher as the primary trend-detection mechanism.

Unchanged axioms

1. The org trusts a human to decide when a system is safe to bring back and who's accountable if it isn't. A model can propose a fix or a rollback; it cannot be the party that answers to customers, regulators, or leadership when a decision goes wrong. Someone with authority still has to say "ship the rollback" and own the consequence.
2. SLOs and error budgets only work if someone owns the tradeoff between velocity and reliability. Deciding how much risk a business should tolerate for a given feature is a judgment call about the business, not a pattern in telemetry — there's no ground truth to pattern-match against, only a bet on the future.
3. Paging a human is the only reliable way to get a fix applied when the fix requires real-world action. Restarting a bare-metal box in a colo, cutting over a physical network link, coordinating with a cloud provider's own outage — these remain physical or transactional acts outside token generation. AI can draft the plan; a person or a tightly-scoped automated action executes it, and someone is on the hook if the action is wrong.
4. Novel, high-stakes incidents — the ones with no precedent — still need human judgment. AI diagnosis is pattern-matching against what's been seen before. The incident that doesn't match any known pattern (a genuinely new failure mode, a cascading multi-system interaction never logged before) is precisely where confident-but-wrong output is most dangerous, and where a human has to reason from scratch.
5. Verifying that an AI-proposed fix is actually safe to run in production stays scarce. A plausible-sounding remediation script or config change can be wrong in ways that are expensive to discover after the fact (data loss, cascading failure). Someone still has to validate blast radius before executing, especially under time pressure where the temptation to skip verification is highest.

New axioms

1. When anyone can generate a plausible root-cause hypothesis in seconds, who verifies it before action is taken on it? Fast, confident, wrong diagnoses during a live incident can send responders down the wrong path faster than a slower human process would have, and speed makes the mistake feel more trustworthy, not less.
2. When postmortems and runbooks are cheap to draft, does documentation volume outpace anyone's ability to keep it accurate? A flood of AI-drafted runbooks that quietly drift out of sync with the actual system becomes a new failure mode — stale documentation that looks authoritative.
3. When agentic AI can execute remediation steps directly (restart a service, roll back a deploy, scale a cluster), who is accountable when the automated action itself causes the outage? Autonomous remediation collapses response time but also collapses the human checkpoint that used to catch a bad automated decision before it executed.
4. When AI can watch every signal continuously, does alert volume and false-positive noise grow faster than trust in the system? Abundant anomaly detection can produce more alerts than any team can triage, reproducing the alert-fatigue problem at a new scale unless someone solves the aggregation and prioritization layer.
5. As on-call rotations shrink because toil is automated, who retains the tacit operational knowledge needed to catch the novel incident AI can't pattern-match? If juniors no longer cut their teeth on the toil that used to build systems intuition, the bench of engineers capable of judgment on truly novel incidents may thin just when it's needed most.

Where it breaks

"Toil has to be absorbed by headcount" (invalid) collides directly with "who's accountable when automated remediation causes the outage" (new): the same agentic capability that lets a team safely cut headcount for toil is the capability that, unsupervised, can take a real production action on a wrong diagnosis — and most teams are cutting the headcount faster than they're building the verification layer that would make autonomous remediation safe.

A second collision: "runbooks are written after the fact because writing takes time" (invalid) meets "documentation volume outpacing accuracy" (new) — teams celebrating that AI now writes postmortems in minutes haven't built the review discipline to keep that suddenly-abundant documentation from silently going stale, which defeats the purpose of writing it at all.

ai-axioms.vercel.app/axioms/engineering/sre-ai-axioms