KI hat DevOps nicht getötet, aber sie hat den Einsatz drastisch erhöht

Unter Ingenieuren kursiert gerade der Running Gag, dass „zwei Menschen mit KI die technischen Schulden von fünfzig erzeugen können“. Er ist witzig, weil er stimmt. Oder zumindest unangenehm nah dran ist.

KI hat DevOps nicht ersetzt. Wenn überhaupt, hat sie DevOps noch stärker ins Rampenlicht gerückt. Plötzlich passieren Entscheidungen, die früher unbemerkt in YAML-Dateien, Terraform-Modulen und Shell-Skripten lebten, schneller, häufiger und manchmal, ohne dass die tippende Person vollständig versteht, was sie gerade ausgeliefert hat. Die Geschwindigkeit steigt. Das Vertrauen ist … kompliziert.

In der Debatte um KI im DevOps ist längst klar, dass sie funktioniert. Offen ist, was passiert, wenn Geschwindigkeit auf Infrastruktur, Sicherheit und Produktionssysteme trifft, die Fehler nicht verzeihen.

Schneller heißt nicht sicherer

In einem Punkt sind sich die meisten Ingenieure einig: KI ist großartig, wenn man bereits weiß, was man tut. Wer Kubernetes-Networking, IAM-Policies oder Deployment-Pipelines versteht, dem kann ein LLM wie ein Elektrowerkzeug vorkommen. Es füllt Boilerplate aus, erinnert an vergessene Flags und erspart einem, zum fünfzehnten Mal dasselbe Helm-Chart-Grundgerüst zu schreiben. Fehlt dieses Verständnis, beschleunigt KI Sie allerdings in die falsche Richtung, statt Sie auszubremsen.

Infrastruktur-Code ist nicht wie Frontend-Code, wo eine schlechte Entscheidung eine Konsolenfehlermeldung wirft und einen Button-Hover-Effekt ruiniert. Infrastruktur versagt laut oder, schlimmer, lautlos: ein Backup-Skript, das immer Erfolg meldet, eine Scaling-Policy, die richtig aussieht, aber zur falschen Zeit Kapazität abzieht, eine IAM-Rolle, die nur ein kleines bisschen zu freizügig ist.

Solche Bugs kommen in der Praxis vor und bleiben unbemerkt, bis jemand anderes um drei Uhr morgens Bereitschaftsdienst hat, auf Logs starrt und sich fragt, wer das für eine gute Idee hielt.

„Vibe Coding“ fühlt sich in der Produktion anders an

Es gibt einen Grund, warum der Begriff „Vibe Coding“ erfahrenen Ingenieuren einen Schauer über den Rücken jagt. Anwendungscode mit einem vagen Verständnis der internen Abläufe zu schreiben ist eine Sache, dasselbe mit Infrastruktur zu tun eine ganz andere.

KI ist sehr gut darin, Dinge zu erzeugen, die korrekt aussehen: sauberes YAML, plausibles Terraform, selbstbewusste Erklärungen. Genau diese Souveränität ist Teil der Gefahr. Halluzinierte Felder sehen nicht halluziniert aus, und erfundene Flags schlagen keine Warnglocken, bis etwas kaputtgeht.

Sobald KI-generierte Änderungen in Produktionssystemen landen, wird der Blast Radius real. Rollbacks sind nicht immer sauber. Der State geht nicht immer zurück. „Vorschläge“ zur Kostenoptimierung können sich in gelöschte Ressourcen verwandeln, und Auto-Remediation kann zu Auto-Zerstörung werden.

Die Ironie ist: Je abstrakter moderne Plattformen werden, desto leichter fällt es, der Ausgabe zu vertrauen, ohne sie zu hinterfragen. Wenn sich sowieso schon alles ein bisschen magisch anfühlt, wird KI einfach zu einer weiteren Schicht „vertrau mir einfach“.

Security-Teams sind zu Recht nervös

Wenn es eine Gruppe gibt, die der Hype nicht mitgerissen hat, dann Security- und Compliance-Teams. Altmodisch ist diese Skepsis nicht, sie ist realistisch.

KI-Tools verstehen nicht den vollen Kontext Ihrer Organisation. Sie wissen nicht, welche Risiken akzeptabel sind und welche nicht. Sie kennen weder Ihre regulatorischen Pflichten noch Ihr Bedrohungsmodell noch das eine Legacy-System, das kaputtgeht, wenn man es falsch anfasst.

Einem KI-Agenten Ausführungszugriff auf Produktionsumgebungen zu geben ist deshalb eine Governance-Entscheidung und nicht bloß eine Tooling-Frage. Wer hat diese Änderung genehmigt? Wer ist verantwortlich, wenn es schiefgeht? Wie auditieren Sie Aktionen eines probabilistischen Systems, das seine Argumentation nicht so erklären kann, dass sie einer genauen Prüfung standhält?

Viele Teams lernen das gerade auf die harte Tour. KI funktioniert großartig … bis sie es nicht mehr tut. Und wenn sie versagt, dann meist mit großer Selbstsicherheit.

Wo KI im DevOps wirklich glänzt

Die Geschichte ist nicht nur düster. Tatsächlich haben einige der überzeugendsten Einsatzmöglichkeiten von KI im DevOps gar nichts mit dem Schreiben von Code zu tun: Log-Analyse, Alert-Clustering, Incident-Zusammenfassungen, Change-Korrelation. Das sind Bereiche, in denen Menschen langsam und müde sind und Maschinen sehr gut. KI kann Berge von Rauschen durchforsten und Muster zutage fördern, für die ein Mensch Stunden bräuchte.

So eingesetzt wird KI zum Kraftmultiplikator statt zum Entscheider. Sie hilft Ingenieuren, schneller zu denken, ohne ihnen das Steuer aus der Hand zu nehmen, und reduziert die kognitive Last, statt das Risiko zu erhöhen.

Dokumentation ist ein weiterer unauffälliger Gewinn. Das automatische Erzeugen von README-Updates, Change-Zusammenfassungen oder Migrations-Checklisten spart Zeit, ohne den Produktions-State anzufassen. Dasselbe gilt für kleine, eng abgegrenzte Skripte, die überprüft, getestet und verstanden werden, bevor sie laufen. Der rote Faden ist Zurückhaltung: KI funktioniert am besten, wenn sie eingehegt ist.

Die Erfahrungslücke wird größer

Ein unangenehmer Nebeneffekt KI-gestützter Entwicklung ist, dass sie Erfahrungsunterschiede verstärkt. Senior-Ingenieure nutzen KI tendenziell als Abkürzung für Dinge, die sie bereits verstehen. Junior-Ingenieure nutzen sie manchmal als Ersatz für Verständnis überhaupt.

Das ist eine natürliche Folge von Tools, die Geschwindigkeit versprechen, und niemandem moralisch vorzuwerfen. Aber es bedeutet, dass Teams bei Guardrails, Reviews und Erwartungen bewusster vorgehen müssen.

Wenn jemand an einem Wochenende fünf Microservices generieren kann, ist die spannendere Frage, ob diese Person weiß, was sie gerade gebaut hat. Und wichtiger noch: Kann sie es debuggen, wenn die KI nicht da ist, um zu helfen? KI senkt die Einstiegshürde, hebt aber gleichzeitig die Messlatte für Urteilsvermögen.

Kubernetes ist nicht einfacher geworden

Wenn überhaupt, zeigt KI, wie komplex moderne Infrastruktur bereits ist. Systeme wie Kubernetes waren nie darauf ausgelegt, nachsichtig zu sein. Sie setzen ein gewisses Verständnisniveau voraus, belohnen sorgfältiges Design und bestrafen Rätselraten. KI ändert daran nichts, sie beschleunigt nur, wie schnell man in Schwierigkeiten geraten kann, wenn man die Grundlagen überspringt.

Deshalb kommen so viele erfahrene Ingenieure zur selben Position: KI ist in Ordnung, sogar großartig, solange ein Mensch fest im Loop bleibt. Vorschläge sind willkommen, Auto-Genehmigung nicht.

Was KI im DevOps wirklich verschiebt

Die größte Veränderung, die KI ins DevOps bringt, ist Verantwortungsdichte und nicht Arbeitsplatzverlust. Eine Person kann jetzt die Arbeit mehrerer erledigen. Das klingt effizient, bis man merkt, dass eine Person damit auch die Probleme mehrerer verursachen kann.

Organisationen, die KI als Weg nutzen, um Ecken abzuschneiden, steuern auf teure Lektionen zu. Organisationen, die sie nutzen, um Ingenieure zu schärfen, erzielen tendenziell bessere Ergebnisse. DevOps-Ingenieure wird es deshalb wahrscheinlich nicht weniger geben, Ausreden dagegen schon. Wenn Tools so mächtig sind, hört „wir hatten keine Zeit“ auf, eine Verteidigung zu sein.

Also … einführen oder abwarten?

Die meisten Teams werden nicht den Luxus haben, sich zu verweigern. KI ist bereits da, fest eingebaut in Editoren, Terminals und Cloud-Plattformen. Zu klären ist also nur, wie man sie nutzt.

Nutzen Sie sie, um schneller zu lernen, Toil zu reduzieren, Ideen zu erkunden und Annahmen auf Plausibilität zu prüfen. Aber geben Sie ihr nicht die Schlüssel zur Produktion und hoffen das Beste.

Bei DevOps ging es nie um Automatisierung um ihrer selbst willen. Es ging um Zuverlässigkeit, Feedback-Loops und gemeinsame Verantwortung. KI ändert diese Philosophie nicht, sie macht nur die Folgen, sie zu ignorieren, viel größer, und wer DevOps bloß vortäuscht, fällt damit schneller auf.