Claude Code ist kein SRE-Agent

Claude Code ist kein SRE-Agent

Warum Logs in I/O-Geschwindigkeit zu lesen immer noch nicht dasselbe ist, wie den Produktivbetrieb zu verstehen.

Gerade wollen alle dieselbe Geschichte hören: Wenn KI Code schreiben kann, ist der nächste Schritt sicher, dass sie auch die Systeme betreiben kann, die dieser Code erzeugt. Anthropics eigenes Reliability-Team hat gerade einen weitaus nützlicheren Realitätsabgleich geliefert. Auf der QCon London beschrieb Alex Palcuie Claude als bei Incidents wirklich hilfreich, aber trotzdem als schlechten Ersatz für einen SRE. Anthropics eigenes Site-Reliability-Agent-Cookbook sagt dasselbe leise in Form einer Architektur: Sobald Sie vom Demo zum Produktivbetrieb übergehen, brauchen Sie nicht nur ein Modell. Sie brauchen klar abgegrenzte Tools, Sicherheitsgrenzen, Runbooks, festgehaltenes Wissen und menschliche Freigaben rund um das Modell.

Diese Unterscheidung ist wichtig, weil der Markt zur falschen Abstraktion abdriftet. Wir behandeln "KI, die programmieren kann" weiterhin so, als ließe sich das ganz selbstverständlich auf "KI, die den Produktivbetrieb führen kann" ausdehnen. Das stimmt nicht. Palcuie beschrieb Incident-Response als eine Schleife aus Beobachten, Orientieren, Entscheiden und Handeln und sagte dabei ausdrücklich, dass KI beim Beobachten fantastisch ist. In dieser Einordnung steckt die ganze Geschichte. Incident-Response im Produktivbetrieb ist kein Wettbewerb im Log-Lesen. Das Schwierigste ist nicht, mehr Daten zu sehen. Das Schwierigste ist zu entscheiden, was die Daten bedeuten.

Beobachtung ist keine Diagnose

Genau hier wird der Unterschied schmerzhaft deutlich.

Claude ist im Beobachten ausgesprochen gut. In Palcuies Beispielen konnte es Belege in Maschinengeschwindigkeit durchgehen, Daten schnell abfragen und Muster aufzeigen, für die ein Mensch deutlich länger gebraucht hätte. Bei einem Incident half es, eine Häufung von HTTP-500-Fehlern von etwas zu unterscheiden, das sich als Missbrauchs- oder Betrugsmuster herausstellte. Das ist nicht trivial. Im Produktivbetrieb ist die Fähigkeit, Logs "in I/O-Geschwindigkeit" zu lesen, ein echter Vorteil.

Doch das wichtigere Beispiel ist das negative. Während Incidents am KV-Cache sah Claude wiederholt steigendes Anfragevolumen und schloss daraus, das System brauche mehr Server. Das sichtbare Symptom war real. Die Schlussfolgerung war falsch. Das eigentliche Problem war der defekte Cache, kein simpler Kapazitätsmangel. Das ist genau die Fehlerart, die viele KI-für-Betrieb-Demos fähiger aussehen lässt, als sie sind: Sie verwechseln Korrelation mit Kausalität und verpacken den Fehler dann in eine selbstbewusste, gut lesbare Erklärung. Zu Post-Mortems wurde Palcuie noch direkter: Das Modell kann eine überzeugende Geschichte produzieren und dabei trotzdem schlecht darin sein, die wahren Root-Causes zu benennen.

Bei Hyground sind wir überzeugt, dass die Branche genau diese Linie viel klarer ziehen muss. KI ist auf der Beobachtungsebene bereits sehr gut. Sie ist gut im Suchen, Korrelieren, Zusammenfassen und Eingrenzen des Suchraums. Die Root-Cause-Analyse ist etwas anderes. Sie ist Hypothesen-Management unter Unsicherheit. Sie heißt zu entscheiden, welche Signale stromaufwärts liegen, welche stromabwärts und welche nur Rauschen sind. Deshalb ist das richtige Produktziel die geführte Untersuchung, nicht autonome Gewissheit. Anthropics eigenes Cookbook spiegelt dieselbe Logik: Der Agent ist am wirksamsten, wenn er über Metriken, Logs, Alerts und Konfiguration hinweg synthetisieren kann, während die Behebung in einem strukturierten Human-in-the-Loop-Workflow bleibt.

Root-Causes leben in der Historie

Palcuies wichtigster Punkt ist vielleicht noch einfacher: Modelle kennen die Historie Ihres Systems nicht.

Und in realen Produktivumgebungen ist die Historie die halbe Diagnose. Der Alert-Schwellenwert, der vor drei Jahren wegen einer Migration gelockert wurde. Der Dienst, der noch von einem alten Ownership-Modell abhängt, das niemand je ganz entwirrt hat. Der Config-Workaround, der zum Dauerzustand wurde. Der Incident, an den sich alle erinnern, den aber niemand sauber dokumentiert hat. Nichts davon steht in den heutigen Logs. Nichts davon ist aus dem aktuellen Dashboard ersichtlich. Und doch prägt all das die Bedeutung des aktuellen Ausfalls. Palcuie sagte es direkt: Claude kennt die Historie Ihres Systems nicht, vor allem wenn dieses System seit zehn Jahren existiert.

Deshalb ist der Erhalt von Wissen keine optionale Schicht über einer Incident-KI. Er ist Teil des Kernsystems. Anthropics eigenes SRE-Cookbook landet genau an dieser Stelle. Der generische Agent wird spürbar nützlicher, sobald er Runbooks folgen, institutionelle Abläufe als Skills kodieren, frühere Post-Mortems durchsuchen und neue Post-Mortem-Seiten in Confluence schreiben kann. Das ist kein "zusätzlicher Kontext". Das ist das fehlende operative Gedächtnis, das aus einer plausiblen Geschichte eine nützliche Untersuchung macht.

Genau deshalb haben wir Hyground so entworfen, wie wir es getan haben. Unsere Plattform ist darauf ausgelegt, innerhalb der Umgebung des Kunden zu laufen, sich mit operativen Systemen wie Prometheus, Loki und Kubernetes zu verbinden und mit dem bestehenden Toolchain und Wissensbestand zu arbeiten, statt sich wie ein isolierter Chatbot zu verhalten. Die Produktsprache von Hyground spiegelt das bereits: Zugriff auf Infrastruktur-Daten in natürlicher Sprache, lebendige Dokumentation, die Teamwissen liest und schreibt, und ein geführter Assistent, der Multi-Signal-Ereignisse genau dort untersucht, wo der Incident tatsächlich passiert.

Jevons schert sich nicht um Ihr Demo

Die strategische Erkenntnis aus Palcuies Vortrag ist nicht nur, dass Modelle weiterhin mit Kausalität ringen. Sie ist, dass die Nachfrageseite des Betriebs wahrscheinlich wächst, nicht schrumpft.

Er beruft sich ausdrücklich auf das Jevons-Paradoxon: Wenn Technik etwas billiger macht, tun wir am Ende oft mehr davon, nicht weniger. In der Software bedeutet das: KI macht es leichter, Code zu schreiben, also schreiben Organisationen mehr Code, schaffen mehr Dienste, erhöhen die Komplexität und enden bei interessanteren Ausfällen. Das Ergebnis ist keine Welt mit weniger on-call. Es ist eine Welt, in der die Fläche, auf der Incidents entstehen, schneller wächst, als Teams sie manuell durchdenken können.

Das ist der Teil, den viele KI-Narrative weiterhin übersehen. KI-gestützte Entwicklung ist nicht nur eine Geschichte von Produktivität. Sie ist auch eine Geschichte von Komplexität. Jeder Gewinn an Erzeugungsgeschwindigkeit kann in mehr Dienste, mehr Abhängigkeiten, mehr Deployments, mehr verborgene Kopplung und mehr Gelegenheiten münden, festzustellen, dass ein System nur deshalb "funktionierte", weil es niemand zuvor genau auf diese Weise belastet hatte. Deshalb wird der Markt für operative Intelligenz größer, während KI-Coding-Tools besser werden. Die Tools, die Veränderung beschleunigen, erhöhen zugleich den Bedarf an Tools, die Veränderung im Produktivbetrieb sicher verstehen können.

Lassen Sie das Narbengewebe nicht verdunsten

Palcuie warf auch eine Sorge auf, die jede Engineering-Führungskraft ernst nehmen sollte: den Verfall von Fähigkeiten.

Er sagte, gute SREs tragen Narbengewebe. Das ist genau der richtige Ausdruck. Großartige Incident-Responder sind nicht nur Menschen, die wissen, wo die Logs liegen. Sie haben gesehen, welche Dashboards lügen, welche Symptome sich wiederholen, welche Rollbacks sicher sind, welche "offensichtlichen Fixes" zwanzig Minuten später einen zweiten Incident auslösen und welche Systeme nur im Architekturdiagramm unabhängig aussehen. Dieses Narbengewebe ist teuer aufzubauen und leicht zu verlieren.

Die richtige Rolle für KI ist nicht, dieses Narbengewebe zu ersetzen. Sie ist, es zu bewahren, zu verbreiten und dem Rest der Organisation zugänglicher zu machen. Lassen Sie das Modell die langweilige, aber umfangreiche Arbeit erledigen: Logs durchforsten, die Deploy-Historie vergleichen, Alerts korrelieren, den Zustand zusammenfassen, das erste Post-Mortem entwerfen. Lassen Sie Menschen das Urteil, die Eskalation, die Abwägungen und das Handeln unter Risiko verantworten. Selbst Anthropics eigener Aufbau trennt Untersuchung von Behebung und behandelt die Grenze zwischen rein lesender Analyse und Schreibzugriff als erstklassige Designentscheidung. Das ist Teammate-Design, kein Ersatz-Design.

Anthropics Architektur bestätigt leise das richtige Design

In Anthropics eigenem Material steckt ein zweites Signal, und es ist wahrscheinlich das nützlichste für alle, die in diesem Feld bauen.

Ihr offizieller Site Reliability Agent ist nicht "einfach Claude Code". Er ist eine Architektur. Er nutzt MCP-angebundene Tools für Metriken, Logs, Configs, Alerts und Deployment-Historie. Er grenzt Zugriffe über eingeschränkte Verzeichnisse, Command-Allowlists und Validierungs-Hooks ab. Er trennt Untersuchung von Behebung. Er unterstützt Runbooks und Post-Mortem-Workflows. Er reicht in Tools wie PagerDuty und Confluence hinein. Mit anderen Worten: Selbst Anthropic behandelt operative KI nicht als Modell allein. Sie behandeln es als Modell, das in ein sorgfältig strukturiertes operatives System eingebettet ist.

Das bestätigt unabhängig die Richtung, die aus unserer Sicht am wichtigsten ist. Der Produktvorsprung bei KI für den Betrieb liegt nicht darin, dass "unser Modell magisch ist". Er liegt darin, ob das System mit den richtigen Belegen verbunden ist, ob es institutionelles Wissen abrufen kann, ob es eine Untersuchung sicher strukturieren kann und ob es innerhalb der richtigen Freigabegrenzen handeln kann. Auch die heutige Architektur von Hyground weist genau in diese Richtung: Deployment im Cluster, lokale Datenverarbeitung, Integration in das bestehende Toolchain, lebendige Dokumentation und geführte Untersuchung statt blinder Autonomie.

Die eigentliche Chance

Also ja: Claude Code ist kein SRE-Agent.

Doch das ist keine Anklage gegen Claude Code. Es ist eine Aussage über die Kategorie. SRE-Arbeit ist kein Programmieren mit anderen Eingaben. Sie ist das Gewichten von Belegen unter Unsicherheit, in Systemen, die von Jahren technischer Entscheidungen, organisatorischer Kompromisse und angesammeltem operativem Gedächtnis geformt sind. Ein Modell, das schneller liest, ist hilfreich. Ein System, das sicher untersuchen, Historie abrufen, Teamwissen bewahren und mit Menschen zusammenarbeiten kann, ist das, was Betriebsteams wirklich brauchen.

Die Gewinner in diesem Markt werden nicht die Unternehmen sein, die versprechen, das SRE-Team zu entlassen. Es werden die sein, die jeden Engineer in den ersten fünfzehn Minuten eines Incidents wirksamer machen, das in den fünfzehn Stunden danach Gelernte bewahren und die besten SREs freistellen, an schwierigeren Zuverlässigkeitsproblemen zu arbeiten. Anthropics eigene Erfahrung ist eines der klarsten öffentlichen Signale bislang, dass die Branche tatsächlich dorthin steuert. Wenn Ihre KI Logs lesen, aber Symptome nicht von Ursachen trennen, die Historie des Systems nicht abrufen und nicht innerhalb sicherer Workflows arbeiten kann, dann haben Sie keinen SRE-Agenten. Sie haben einen sehr schnellen Beobachter.