Can Claude fix itself? From no to maybe

Alex Palcuie helps keep Claude running at Anthropic; he is on-call and handles incidents. When he gave a talk called Can Claude fix itself? in March, his answer was “no.” At Signals Berlin earlier this month, that had become a "maybe": Claude can investigate production systems, come up with valid fixes and surprise Alex with Move 37^* moments, yet it can also still send responders chasing a convincing, wrong explanation.

Alex shared three incidents to illustrate how mature the technology is.

Incident one: look beyond the bug

On New Year's Eve, Opus started returning more HTTP 500 errors, so Alex asked Claude Code to investigate.

Claude traced the errors to a bug in image preprocessing: the failing requests contained exactly 22 images. Alex says he would probably have only filed a ticket for the API team at that point. But Claude kept going, checking who was sending those requests.

It found 200 accounts sending similar requests at the same time, all belonging to a batch of 4,000 created three days earlier with the same email pattern. That led Claude to recommend involving the safeguards team, which confirmed the abuse. Claude had gone beyond the technical work on the bug and looked at the bigger picture, catching something a responder focused on the fix would probably have missed.

For Alex, this became his Move 37 moment, as he knew that from now on his incident response work would be different.

Incident two: when monitoring is wrong

Claude surprised him again when the inference router drained a healthy cluster and overloaded the servers that received its traffic. While the humans in the channel blamed the data center, Claude noticed that a handful of servers were reporting more tokens per second than physically possible, something that, in my opinion, a human might not even think to check. It came to the conclusion that the system was fine, but the measurement was wrong.

Claude traced it to the monitoring system: the metric collectors had just been resharded, and for five minutes two shards scraped the same servers, inflating the rate the router relied on. It then proposed and tested a fix while the team paused the collectors' autoscaler to prevent a repeat.

For Alex, this was another Move 37: Claude had gone beyond his own infrastructure into the observability stack, a system he was himself not an expert in.

Incident three: red herring trap

But Claude also falls into the classic red herring trap. In the last incident Alex described, one cluster returned errors for 41% of requests over five minutes. Claude noticed that local cache hit rates had dropped just beforehand. A lost cache seemed to explain the errors, and the timing made the story convincing. An hour later, another engineer's Claude session helped uncover what was missing: requests that missed the local cache still retrieved data from a shared cache. The overall cache hit rate had barely dipped; the overloaded servers were the problem.

Alex says he could have made the same mistake because the graph fit the explanation he expected. In other words, Claude fell into a trap that humans fall into too. He recalled his first manager at Google, Steve McGhee, who was always warning that looking at graphs without an explicit reason can turn up problems that aren't really problems. Ironically, an agent's superpower of being able to search far more graphs also gives it more opportunities to find misleading patterns.

AI capabilities are jagged across incident response

To assess Claude's ability to fix itself, Alex borrows the OODA loop from the United States Air Force: observe, orient, decide, act. The idea is that whoever makes sense of a changing situation fastest gains the advantage, which, in Alex’s eyes, is as true in an incident channel as in a cockpit.

Observing is where LLMs shine. They can search logs, query metrics, and investigate multiple paths in parallel, faster than any human responder. However, orienting, where they need to make sense of what they found, is where things get jagged.

Deciding is also in good shape. Claude can propose fixes, compare their trade-offs, and test them against past incidents. Finally, acting is where the line is still to be drawn. For Alex, any fix in production should require human approval, and he wants to understand every command he runs. For more autonomy, he argues, you'd need a production action classifier that approves routine operations and flags riskier ones for review.

The model needs evidence to work with

Alex is a talented SRE who rose to Staff level during his eight years at Google. He now works at Anthropic, with access to its best models and almost unlimited tokens. If his answer to “Can Claude fix itself?” is still “maybe,” I think that sets reasonable expectations for the rest of the AI SRE industry.

I work at Rootly, where we build AI-assisted incident response tools, and I'd argue most teams start from further back than Alex, for a reason that has nothing to do with the model: an agent is only as good as the context it can access.

Code and infrastructure may lack instrumentation, security restrictions may block access to existing data, or key context may live only in people's heads. Cost matters too. For example, I've repeatedly heard engineers say the cost of sending application logs to Datadog far exceeded what their budget allowed, leaving the incident response agent useless because it did not have the context it needed.

While these tools can certainly reduce toil for on-call engineers, we are still far from a fully autonomous situation, and I expect humans to stay in the loop for quite some time.

Move 37 refers to AlphaGo's unexpected move against Go champion Lee Sedol: what initially looked like a mistake to experts helped the AI win the game. ↩