Anthropic hat den ersten Bereitschaftsdienst für die interne CI/CD-Pipeline an Claude Tag übergeben. In der am 18. August veröffentlichten Erläuterung stechen zwei Zahlen besonders hervor: Nach Eröffnung eines Incidents liefert Claude die erste belegte Analyse im Median nach 14 Minuten; im günstigsten Fall benennt der erste Bericht die Ursache bereits nach 4 Minuten.
Der Hintergrund wird recht offen benannt – die pro Ingenieur und Quartal ausgelieferte Codemenge ist auf das Achtfache des ursprünglichen Werts gestiegen. Mit dem gestiegenen Output steigt auch die absolute Zahl an fehlgeschlagenen Builds, instabilen Tests und Deployment-Rollbacks, während eine einzelne Fehlersuche oft über eine Stunde beansprucht und häufig außerhalb der Arbeitszeit anfällt.
Welche Schlüssel Claude in der Hand hält
Dass das Ganze funktioniert, liegt an der Rechtekonfiguration, nicht am Modell selbst. Claude erhält über MCP-Connectoren eine Reihe von Zugriffsrechten: Grafana und den Log-Speicher, um Metriken und Stacktraces einzusehen, Datadog als Ergänzung fürs Monitoring, GitHub, um Commits durchzusehen, Änderungen zu prüfen und PRs zu erstellen, Kubernetes für Empfehlungen auf Cluster-Ebene sowie PagerDuty und mehrere Slack-Kanäle, um Alerts zu empfangen und Ergebnisse zu melden. Claude verfügt über ein eigenes Service-Konto, dessen Handlungen auditierbar sind.
Ob ein Alert jemanden wecken soll, wird direkt als Regel in natürlicher Sprache formuliert. Das im Beitrag genannte Beispiel: Liegt die Fehlerrate über 2 % und hält das länger als 5 Minuten an, und fällt das nicht in ein bekanntes Release-Fenster, wird der Bereitschaftsdienst alarmiert. Solche Schwellenwerte lagen früher in den Konfigurationsdateien des Monitoring-Systems, jede Änderung musste den Release-Prozess durchlaufen; als für Claude lesbare Regel formuliert, sinkt der Änderungsaufwand auf das Bearbeiten einer einzigen Zeile Text. Neben automatischen Alerts können Teammitglieder und die interne Incident-Seite auch manuell auslösen.
Die Triage-Phase läuft parallel
Kommt ein Incident herein, startet Claude einen orchestrierenden Agenten, der wiederum mehrere Subagenten parallel aussendet, um unterschiedliche Abhängigkeiten zu prüfen: einer durchsucht Logs, einer vergleicht die jüngsten Commits, einer betrachtet die Metrikkurven. Das Ergebnis dieses „dynamischen Workflows“ ist eben jene Analyse nach 14 Minuten.
Die Urteilsbildung stützt sich auf zwei Arten von Dateien. Die eine sind Skill-Dateien, als Untersuchungshandbücher nach Störungstyp verfasst – eine davon behandelt speziell den Suchpfad für eine besonders hartnäckige Bug-Klasse und ist 617 Zeilen lang. Die andere ist lessons.md, die Claude nach jedem abgeschlossenen Incident selbst ergänzt, damit beim nächsten ähnlichen Muster zuerst dort nachgeschlagen wird. Beide Dateiarten liegen auf GitHub und durchlaufen denselben Review-Prozess wie Code.
Bei der Behebung bleibt Platz für den Menschen. Das häufigste Ergebnis ist ein PR, über dessen Deployment erst nach Ingenieurs-Review entschieden wird; das schrittweise Ausrollen steuert Traffic per Feature-Flag; bei Cluster-bezogenen Fällen gibt Claude Empfehlungen zum Draining, Isolieren oder Skalieren, die Ausführung entscheidet der Mensch. Nach der Änderung verifiziert Claude die Behebung mit demselben Werkzeugsatz erneut.
Wer den Rest der Arbeit übernimmt
Anthropic behält ausdrücklich einige Aufgaben dem Menschen vor: mittel- bis langfristige Architekturverbesserungen; das gemeinsame Ergänzen von Hypothesen zusammen mit Claude im Shared-Modus, da dessen Einschätzung nicht immer beim ersten Mal stimmt und menschliche Intuition korrigierend eingreifen muss; die Review-Freigabe für PRs; sowie den Kommunikationston – das Format der Statusberichte musste mehrfach überarbeitet werden, bis es dem Geschmack des Teams entsprach, dieser Teil ließ sich nicht automatisieren.
Auch die Übergabe wurde produktisiert. Es gibt einen wöchentlichen Sammelbericht, tägliche Kurzfassungen, und ein weiterer Agent namens ci-weather fasst mehrere Incidents zu einer nach außen sichtbaren Statusmeldung zusammen.
Eine leicht übersehene Rechnung
Die Zahl Acht steht an zwei Enden – „warum man das macht“ und „wie es sich nach der Umsetzung darstellt“ – und bedeutet dort nicht dasselbe. Zunächst ist sie die Ursache des Drucks: Bei gleicher Teamgröße steigt mit einer verachtfachten Liefermenge auch die Zahl der Incident-Tickets nicht von selbst still. Gleichzeitig ist sie auch die Voraussetzung dafür, dass dieses Bereitschaftssystem überhaupt trägt – würde Code weiterhin Zeile für Zeile von Menschen getippt, lägen Form, Häufigkeit und Erklärbarkeit von Störungen näher an der Intuition der Ingenieure, und der Grenznutzen einer KI-Triage wäre nicht annähernd so ausgeprägt. Nachdem KI in großem Umfang am Code-Schreiben beteiligt ist, passt es logisch zusammen, die KI auch die erste Fehlersuchebene übernehmen zu lassen.
Auch die Einstiegshürde wird klar benannt: erforderlich ist Claudes Team- oder Enterprise-Plan, und die Anbindung der Tools sowie die Rechtekonfiguration nehmen anfangs mehrere Stunden in Anspruch. Für die meisten Teams liegt die Schwierigkeit vermutlich weniger in der technischen Anbindung als in der Frage, ob man sich traut, ein Service-Konto herauszugeben, das PRs erstellen und den Cluster steuern kann.
Quellen: offizieller Anthropic-Blog, CocoLoop; die Angaben zu 14 Minuten medianer Triage-Zeit, 4 Minuten schnellster Ursachenermittlung, achtfacher Quartalsliefermenge und 617 Zeilen Skill-Datei-Länge wurden anhand der öffentlichen Unternehmensangaben abgeglichen.