Site Reliability Engineering (SRE) Is Having Its Claude Code Moment

"The Claude Code moment for SRE has finally arrived." That's how an engineer at American Express recently described Traversal to a colleague, unprompted.

That claim points at something bigger than one product. Coding already went through a moment like this: a single tool arrived that understood the whole codebase and could act on it, anywhere, changing what engineers actually did all day. SRE is having that same moment now, on the way to what we call self-driving production: a system that detects, diagnoses, and remediates on its own.

Traversal makes that moment possible. See it live today.

A brief history of AI coding

In less than half a decade, AI in the code editor went from finishing your sentences to doing the work itself. It moved there in steps, so they are worth putting in order:

  • In-line autocomplete came first. For years, tools like IntelliSense guessed the rest of a line from what you'd typed, useful but never reaching past the keystroke you were already making.
  • Multi-line, predictive completion came next. GitHub Copilot made it LLM-based in 2021, predicting the next few lines instead of the next token, but it still only finished thoughts you'd started. Conversational reasoning about code followed with ChatGPT and Copilot Chat, a real leap, but the model still didn't do anything. You did, copy-pasting between the chat window and your editor.
  • Whole-codebase context came after that. Cursor was first to take it seriously: your imports, conventions, types, edits spanning many files at once. The user got real context, though only inside Cursor's own editor.
  • Full context with end-to-end execution, unconstrained by any single interface, arrived last. Claude Code, in 2025, is where the constraints came off. Real work from start to finish, with no prescribed home. It ran in the terminal, so it fit whatever workflow you already had.

Here is the part most people misread. Across those years, the story looks like one about capability: the models got smarter, holding more and more of the codebase in view. But two things were actually moving simultaneously. The first is comprehensiveness: how much of the codebase a tool understands, from a single line to the whole repository's imports, types, and conventions. The second is generalizability: how many different jobs that understanding could be pointed at, and who got to decide. Every product before Claude Code drew that boundary for you: which editor, which sidebar, which tasks it was built to do. Claude Code didn't. Once the model held enough of the codebase and the harness stopped prescribing what it was for, people pointed it at anything: refactors, unfamiliar code, documentation, one-off scripts nobody planned for. Comprehensiveness got it in the door; generalizability is what let it go everywhere.

The same arc is now running in SRE

The coding timeline matters precisely because SRE is climbing the very same ladder, a few rungs behind. The category taking shape has a name, AI SRE: a system that investigates production end to end rather than flagging what changed or firing a predefined playbook. Here is how it's arriving:

  1. Threshold alerts and anomaly detection came first. Dashboards flagged that something had changed, a graph spiked or a metric crossed a line. Then observability platforms added correlation on top: metrics, events, logs, and traces (MELT) pulled into one view, anomalies grouped together. But the reasoning still relied on individual humans. The tool told you what changed; you still had to figure out why. This is the autocomplete layer of SRE.
  2. Agentic runbook execution came next. AI started acting on incidents, but only within workflows humans had already mapped out: auto-triggered the moment an alert fired, running a predefined playbook, surfaced through an opinionated UI built for that one moment. Real automation, but confined to a prescribed workflow. This is SRE's Cursor moment: genuine context confined to a prescribed workflow.
  3. Full context with end-to-end investigation, unconstrained by any playbook, is arriving now. Not just flagging or executing a predefined step, but investigating the anomaly, finding the root cause, and proposing the fix, delivered wherever engineers already are: Slack, the terminal, over MCP. No console to live in, no workflow handed down.
Once the workflow is no longer fixed in advance, what the tool can be used for stops being something anyone decides up front. This is SRE's Claude Code moment, and like Claude Code, the signal isn't the capability itself. It's what engineers do once they have it: reaching for it on workflows nobody scoped, using it in ways no roadmap anticipated. The same way Claude Code broke out of writing code into reviews, migrations, and one-off scripts nobody planned for, an AI SRE with both axes at full strength breaks out of incident response: engineers point it at deploy validation, capacity questions, onboarding, the daily "why is this behaving strangely" that never rises to an incident. The use cases arrive faster than anyone can enumerate them.

The same two axes are what's shifting here:

  1. Comprehensiveness of the data model: a continuously updating representation of the full production environment, not a static slice of it, so it can trace root causes that sit many hops away, across services, infrastructure, and time. Traversal calls this the Production World Model™
  2. Generalizability of the agentic harness: a system that reasons over that model for any question put to it, not a workflow wired to a single task. We built the Causal Search Engine™ for the hardest agentic task in production, real-time root cause analysis during a live incident, and as an emergent property, we found it generalized  to every other task by default.

Dashboards and observability platforms have partial comprehensiveness, locked to alerting and triage. A narrow agent might generalize within a single task, but not beyond it. Holding both at full strength, comprehensive enough to be able to look at production data at scale, and general enough to go beyond incident RCA to whatever it is pointed to, is what's new here, the same threshold Claude Code crossed for code.

The tell: uses you didn't put on the roadmap

Think back to the Claude Code long tail. The pattern is simple: when people start reaching for a tool well past the job it was scoped for, and those unplanned uses pile up faster than the ones you planned, the tool has crossed the threshold, from a feature you ship to a foundation people build on.

Anthropic saw this happen with its own teams. The engineering uses were the predictable ones: debugging, navigating unfamiliar codebases, managing workflows. The uses that surprised them were the tell: lawyers building phone-tree systems to route questions to the right attorney, marketers spinning up hundreds of ad variations at once, data scientists shipping dashboards in a language they'd never written. None of it was on a roadmap.

At American Express, Traversal’s Production Support capability fielded more queries exploring how production behaves than triaging live ones. The biggest single category was open-ended exploration, engineers iteratively making the system more resilient when nothing is on fire.

Onboarding a new SRE in their first week, by letting them ask the system how production actually works instead of interrupting a senior engineer.
Catching drift on services nobody owns (the quiet ones no one watches until they break).
Running blast-radius analysis before a deploy, to see what a change could touch before it ships.

Customers have also started using it to translate incidents across teams, so the database group and the application group are working from the same incident story instead of two separate dashboards, and to explore their production environment through general natural language questions, like how many of a given alert they've had in the past 60 days. These are a couple of examples among many.

None of these were planned. Customers found them on their own, as the foundation has finally become stable enough to build on.

Why the threshold is crossable at all

A variety of use cases is not a coincidence. It's what comprehensiveness and generalizability produce once both are strong enough simultaneously. Once that combination exists, "what caused this incident" becomes just one question among many. The same foundation maps a blast radius before a deploy, audits which telemetry is load-bearing, or gets a new engineer fluent in a system they've never seen. Those weren't features we added; they fell out of getting the underlying combination right.

That's what makes the threshold crossable: the long tail on the surface is downstream of that combination. Without it, an SRE tool is stuck in the autocomplete era, fast, narrow, and forced to tell you how to use it.

The surface that shows up on its own

There is one thing production cannot copy from coding. Every tool in the coding story that reasons broadly, from Cursor to Claude Code, still waits to be invoked. The proactive tools coding does have--bots that open a PR or flag a failing build--work one narrow job and nothing else. Nobody has combined the two: a system with Claude Code's generality that also shows up on its own. An incident doesn't wait, so that's where SRE's surface has to go first.

That is Traversal Workers. A Worker is proactive by design: no one summons it. It joins an incident channel the moment something breaks, and works with full agency, until it nails the fix. It runs on the same RCA engine as the rest of Traversal, with the same rigor, in a form that behaves like a superintelligent SRE. It speaks up when it has something worth saying, keeps the rest in-thread, and tags the people who need to see it. When the incident is over, it leaves a draft postmortem: timeline, root cause, and what would prevent the next one. 

Most teams today are far closer to the manual war room than to self-driving production, but a Traversal Worker showing up unprompted, on its own, is an early instance of that future. 

What happens further along that curve isn't just fewer incidents. It's engineers spending their time building again instead of firefighting, with the 2 a.m. page becoming a rare exception instead of the price of the job.

See Traversal in your production environment.

The gap between "something is wrong" and "we know what is wrong" is where MTTR is won or lost.
NAME
Member of Technical Staff
“99.9% of API checkout requests over a rolling 28-day window return a successful status under 300 ms.”
“99.9% of API checkout requests over a rolling 28-day window return a successful status under 300 ms.”
Lyndon Vickrey
Member of Technical Staff
Escalating to the right owner takes time, and each handoff resets part of the investigation.
Suhaib Zaheer
SVP & GM of Managed Hosting, Cloudways
Learn More

Some similar reads