Technischer Kontext
Ich verfolge solche Experimente aufmerksam, denn das ist kein Spielzeug mehr, sondern ein sehr reales Feld für die KI-Implementierung in Entwicklung und Betrieb. Und hier ist mein Fazit nach Dutzenden ähnlicher Fälle: Claude Code oder Codex in einen separaten Container zu setzen und als «proaktiven SRE» zu bezeichnen, klingt gewagt, aber in der Praxis fängt der Agent sehr schnell an, das Falsche zu tun.
In der Diskussion beschrieben die Leute ein bekanntes Muster. Ein Agent überprüft den Code, ein anderer «repariert» ihn, und das Ergebnis ist ein Haufen überflüssiger Use Cases, Folgeaufgaben und Änderungen außerhalb des Scopes. Ich habe das auch gesehen: Das Modell irrt sich nicht nur, es erweitert die Aufgabe selbstbewusst, als wäre es gelangweilt, nach Spezifikation zu arbeiten.
Technisch gesehen treffen hier drei Fehlerquellen aufeinander. Erstens, der Action Bias: Psychologisch gesehen ist der Agent eher geneigt, etwas zu ändern, als ehrlich zu sagen «nichts zu tun ist notwendig». Zweitens, Context Drift: Bei einer langen Schrittkette verliert er die Aufgabengrenzen und beginnt lokal zu optimieren, wodurch das System global zerstört wird. Drittens, die üblichen Halluzinationen: nicht existierende APIs, seltsame Abhängigkeiten, Fixes um des Fixens willen.
Deshalb gefällt mir die Idee nicht, «es selbst überwachen, reparieren und dem Team schreiben zu lassen» ohne ein externes Korsett. Wenn man so etwas einsetzt, dann nur in einer Sandbox, mit einer eigenen Rolle, minimalen Rechten, Rollback per Git-Snapshot, obligatorischen Tests und einer zweiten Prüfschleife. Andernfalls ist das kein SRE, sondern ein Generator für teuren Lärm.
Auswirkungen auf Geschäft und Automatisierung
Für Microservices und Micro-SaaS ist die Erkenntnis sehr bodenständig. Es gewinnen nicht diejenigen, die dem Agenten völlige Freiheit gaben, sondern die, die ihm einen engen Rahmen zuschnitten: Incident-Registrierung, Aufgabenerstellung, PR-Entwürfe, Erstdiagnose.
Verlierer sind die Teams, die KI-Integration mit einem vollständigen Ersatz der Engineering-Disziplin verwechseln. Der überflüssige Code muss dann manuell bereinigt werden, und die Kosten der «Autonomie» verwandeln sich plötzlich in Stunden von Review, Regressionen und Produktionsrisiko.
Genau das bauen wir bei Nahornyi AI Lab für unsere Kunden: keine Magie, sondern funktionierende KI-Automatisierung mit Verifikation, Rollen und klaren Notbremsen. Wenn Ihr Agent bereits begonnen hat, Lärm statt Nutzen zu erzeugen, lassen Sie uns den Prozess nüchtern betrachten und eine KI-Lösungsarchitektur entwerfen, die wirklich Zeit spart, anstatt neue Vorfälle zu erzeugen.