Can Claude fix itself? From no to maybe news update

Good, I have all the source material. Now I'll write the article based on the real facts: Alex Palcuie, Anthropic SRE/on-call engineer; three incidents; the OODA loop framework; the "Move 37" moments; the red herring trap with 41% error rate for 5 minutes; 200 accounts from a batch of 4,000; the monitoring reshard causing 5 minutes of double-scraping; Sylvain Kalache at Rootly; the shift from "no" to "maybe" between March and Signals Berlin.

An Anthropic on-call engineer named Alex Palcuie gave a talk in March this year titled "Can Claude fix itself?" His answer at the time was no. Six months later, at Signals Berlin, that answer had shifted to maybe. Three real production incidents drove the change — incidents in which Claude Code traced bugs, caught abuse, corrected a broken monitoring metric, and also confidently led responders toward the wrong conclusion for an hour.

This piece walks through those three incidents, the framework Palcuie used to assess Claude's capabilities, and the hard constraint that still keeps a human hand on every production action. It is for site reliability engineers, platform teams, and anyone evaluating whether an AI agent belongs in their incident channel.

01What actually changed

Between March and September 2026, Alex Palcuie's assessment of Claude's incident-response capability moved from a firm no to a qualified maybe. The shift came not from a model announcement but from direct experience: Palcuie is on the Anthropic on-call rotation, and he used Claude Code during live production incidents on systems running Claude itself. The difference was not theoretical — it was measured in minutes, in missed patterns a human responder would have skipped past, and in one case in a plausible but entirely wrong root-cause analysis that took a second engineer's Claude session to unravel.

To structure what he saw, Palcuie borrowed the OODA loop from the United States Air Force: observe, orient, decide, act. The framework describes how fast a decision-maker can cycle through those four stages under pressure. Palcuie's view is that whoever makes sense of a changing situation fastest gains the advantage, and that insight applies as cleanly to an incident channel as to a cockpit.

02How it works

Observing is where Claude performs strongest. It can search logs, query metrics, and explore multiple diagnostic paths in parallel, faster than a human responder can open the right dashboards.

On New Year's Eve, when Claude Opus started returning elevated HTTP 500 errors, Palcuie asked Claude Code to investigate. Claude traced the failures to an image-preprocessing bug: requests containing exactly 22 images were failing.

Palcuie says he would probably have filed a ticket for the API team at that point. Claude kept going.

It found 200 accounts sending similar requests simultaneously, all belonging to a batch of 4,000 accounts created three days earlier with the same email pattern. That led Claude to recommend involving the safeguards team, which confirmed the abuse.

It concluded the system itself was healthy but the measurement was wrong. The metric collectors had just been resharded, and for five minutes two shards scraped the same servers, doubling the reported rate that the router was using to make routing decisions. Claude proposed a fix and tested it while the team paused the collectors' autoscaler.

It concluded the system itself was healthy but the measurement was wrong. The metric collectors had just been resharded, and for five minutes two shards scraped the same servers, doubling the reported rate that the router was using to make routing decisions. Claude proposed a fix and tested it while the team paused the collectors' autoscaler.

03Why it matters now

Palcuie calls both of those moments his "Move 37" — a reference to AlphaGo's unexpected move against Go champion Lee Sedol, the one that initially looked like a mistake before it helped the AI win the game. The analogy holds because in both incidents Claude pursued a path a focused human responder would have been unlikely to take: checking who was sending the failing requests rather than stopping at the technical fix, or questioning whether the metric itself was accurate rather than accepting what the monitoring dashboard said.

The third incident is equally important because it cuts the other way. One cluster returned errors for 41% of requests over five minutes.

Claude noticed that local cache hit rates had dropped just beforehand, and that timing made a lost cache seem like the explanation. An hour later, a second engineer's separate Claude session uncovered what was missing: requests that missed the local cache still retrieved data from a shared cache, meaning the overall cache hit rate had barely dipped.

The overloaded servers were the real cause. Palcuie noted he could have made the same mistake, because the graph fit the story he expected to find.

04Who is affected

The direct audience is SRE teams considering AI-assisted incident response. Palcuie's position makes his assessment unusually meaningful: he is a former eight-year Staff-level engineer at Google, now at Anthropic, with access to the company's best models and effectively unlimited tokens. If someone with that context and those resources still arrives at "maybe," it sets a realistic baseline for teams starting from further back.

Sylvain Kalache, who published the writeup of Palcuie's talk and works at Rootly building AI-assisted incident-response tooling, points out that most teams face a constraint that has nothing to do with the model: an agent is only as good as the context it can access. Code and infrastructure that lack instrumentation, security restrictions that block log access, and institutional knowledge that lives only in engineers' heads all limit what any AI agent can reason about. Cost is also real — Kalache notes that teams have repeatedly found the cost of sending application logs to services like Datadog to be prohibitive, leaving an incident agent without the data it needs.

05What to watch

Acting in production is a different question. His position is that any fix applied to a live system should require explicit human approval, and that he wants to understand every command that runs before it runs. Moving further toward autonomy, in his view, would require a production action classifier that approves routine, low-risk operations automatically while flagging riskier ones for human review.

Acting in production is a different question. His position is that any fix applied to a live system should require explicit human approval, and that he wants to understand every command that runs before it runs. Moving further toward autonomy, in his view, would require a production action classifier that approves routine, low-risk operations automatically while flagging riskier ones for human review.

That classifier does not yet exist in any standardized form. Until it does, the practical takeaway for engineering teams is narrow but concrete: verify that your incident agent has access to the context it actually needs — logs, metrics, runbooks, and relevant account data — before evaluating whether its reasoning is good.

A correct diagnosis that a human would not have reached is only useful if the agent had the evidence to reach it. The red-herring incident shows the inverse is also true: broad graph access gives an agent more opportunities to find convincing patterns that point the wrong way.