Can Claude fix itself? From no to maybe

Anthropic engineer Alex Palcuie said at Signals Berlin that Claude's ability to fix its own production incidents has shifted from a March "no" to a "maybe," citing three incidents where the model traced an HTTP 500 spike to 200 abusive accounts among 4,000 created three days earlier, identified a monitoring resharding error that inflated token rates for five minutes, and in a third case chased a convincing but wrong cache explanation while one cluster returned errors for 41% of requests over five minutes. Palcuie said Claude's ability to search far more graphs than a human also gives it more chances to find misleading patterns, a trap he said he could have fallen into himself.

Back to the blog https://www.sylvainkalache.com/blog Can Claude fix itself? From no to maybe Alex Palcuie https://www.linkedin.com/in/alexpalcuie/ 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 https://www.theregister.com/software/2026/03/19/fixing-claude-with-claude-anthropic-reports-on-ai-sre/5224819 .” 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<sup user-content-fn- </sup 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 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 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 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 ai-capabilities-are-jagged-across-incident-response To assess Claude's ability to fix itself, Alex borrows the OODA loop https://en.wikipedia.org/wiki/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 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 https://rootly.com/ , 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. Footnotes 1. Move 37 refers to AlphaGo's unexpected move against Go champion Lee Sedol https://deepmind.google/blog/10-years-of-alphago/ : what initially looked like a mistake to experts helped the AI win the game. ↩ user-content-fnref- Sylvain Kalache https://www.sylvainkalache.com/my-story AI Labs lead and DevRel at Rootly. Former LinkedIn SRE and co-founder of Holberton School.