Notiz

KI schreibt DevOps neu: von der Syntax zum Urteil

Was KI heute besser kann als ein Ingenieur, wo der menschliche Mehrwert bleibt und wie sich die Senior-DevOps-Rolle bis 2026 verschiebt.

Vor ein paar Jahren erkannte man Senior-DevOps am Umfang ihres kubectl-Muskelgedächtnisses und an der Geschwindigkeit, mit der sie HCL schrieben. Heute liefert Claude oder Codex das gleiche Volumen in zehn Sekunden, Einrückung inklusive. Die Arbeit ist nicht verschwunden; sie ist im Stack nach oben gewandert, und mit ihr die Definition des wertvollen Ingenieurs.

Wo die KI dem Menschen bereits voraus ist

Jedes schablonenhafte Artefakt — ein Dockerfile, Helm-Values, ein Terraform-Modul aus einer Anforderung, eine IAM-Policy nach Beschreibung — schreibt die KI schneller, sauberer und ohne Ermüdung. Einen zweihundertzeiligen terraform plan in drei verständliche Thesen zu zerlegen, ist heute eine billige Operation. Die KI erkennt den Drift zwischen Git und Cluster als strukturelles Pattern-Matching. Der Triage eines typischen Incidents über die Top-N-Root-Causes geschieht in der Zeit eines einzigen menschlichen Scrolls.

Das ist der Teil von DevOps, auf dem Junior-Ingenieure im Jahr 2020 ihre Karriere aufgebaut haben. Bis 2026 ist er kein Zeichen von Qualifikation mehr.

Wo der Ingenieur bleibt

Capacity Planning ist keine Schablonenaufgabe. „Drei Replikas reichen" gegen „wir brauchen fünf wegen unvorhersehbarer Spitzen" entscheidet sich durch Urteilskraft über das Geschäft und das Lastprofil, nicht durch ein Muster aus dem Trainingskorpus. Die Verantwortung für einen Production-Outage lässt sich nicht delegieren: Die KI trägt nicht die Folgen einer gelöschten Tabelle um zwei Uhr nachts und sitzt nicht im On-Call.

Architektur-Trade-offs — sync oder async, Konsistenz oder Verfügbarkeit, Region-Failover oder Per-Region-Isolation — sind Fragen, ob das System überhaupt diese Form haben soll, nicht Fragen der Syntax. Die Failure Modes verteilter Systeme (CAP, Partial Failures, Tail Latency, Split-Brain) beschreibt die KI aus dem Lehrbuch, verliert aber den Boden in einer fremden Topologie. Der lange Horizont — wohin den Stack in zwei Jahren bewegen, welche technische Schuld zuerst abbauen — verlangt Wissen über das Team, das Produkt und die Entscheidungsgeschichte, das dem Modell nicht zur Verfügung steht.

Und schließlich Verhandlungen. Dem Produktteam zu erklären, warum die Datenmigration zwei Wochen statt zwei Tage dauert, wird die KI nicht für Sie übernehmen.

Was sich im Alltag ändert

Weniger Zeit fließt in kubectl rollout restart, terraform apply, helm upgrade. Mehr Zeit fließt in das Review dessen, was der Agent erzeugt hat, in die Konstruktion von Failure-Szenarien und in Gespräche über Trade-offs mit Stakeholdern. Der Senior-Ingenieur 2026 verbringt weniger Stunden mit Tippen und mehr mit Entscheidungen, die das Tippen früher überdeckt hat.

Für Juniors heißt das: kubectl get pod auswendig zu beherrschen, hat keinen Karrierewert mehr. Wert hat das Verständnis — warum drei Replikas, warum ein PodDisruptionBudget, was ein Readiness-Probe beim Graceful Shutdown zurückgibt. Architektur-Skills werden früher zum Differentiator, als es die alte Karrierekarte vorsah.

Das Team rund um die KI: Arbeitsregeln

Ein paar Regeln trennen einen Arbeitsprozess von einem gefährlichen Experiment.

Read-only zuerst. Ein neuer Agent beginnt mit reinem Lesezugriff. Schreibzugriff folgt erst nach Wochen Verhaltens-Tracking an echten Aufgaben.

Human-in-the-loop für destruktive Operationen. terraform destroy, kubectl delete, Schreibzugriffe auf eine Produktions-Datenbank — immer hinter einer expliziten menschlichen Freigabe. Keine Allowlists „vertrauenswürdiger Kommandos" für destruktive Aktionen.

Guardrails als Code. PreToolUse-Hooks blockieren gefährliche Muster (Anfragen an Prod-Credentials, 0.0.0.0/0 in einer Security Group, IAM-Wildcards). Max-Turns wird nach Aufgabentyp begrenzt: 5 für PR-Review, 15 für Bug-Diagnose, 25 für Multi-Module-Drift. Das ist es, was vor Endlosschleifen mit kumulierendem Fehler schützt.

Dokumentation als Vertrag mit dem Agenten. Wikis, Runbooks und CLAUDE.md sind jetzt nicht nur Onboarding für Menschen, sondern auch RAG-Kontext für das Modell. Gute Dokumentation zahlt sich doppelt aus: das Team liest sie bei Rotationen, der Agent liest sie bei jeder Anfrage.

Warum sich Verantwortung nicht delegieren lässt

Die Production-Failure-Modes von KI-Agenten sind bekannt und wiederkehrend. Hallucinated Tool Calls — Aufruf der falschen API mit plausiblen Parametern. Reasoning Gaps — ein selbstbewusster „deployed"-Report, wo kein Deploy stattgefunden hat. Over-Permissioning — Root-Zugriff verwandelt sich in DROP DATABASE trotz einer „never touch prod"-Zeile im Prompt. Compounding Errors — ein kleiner Fehler in einem frühen Schritt wächst kaskadierend durch eine Kette aus zehn Tool-Calls.

Jeder dieser Failure Modes ist kein „passiert manchmal", sondern eine Betriebsbedingung: man muss sie erwarten und die Abwehr fest einbauen. Der Ingenieur in der Schleife ist keine Hilfe für den Agenten, sondern die Bedingung, unter der das System überhaupt an die Produktion angeschlossen werden darf.

Was sich nicht geändert hat

Pipelines müssen weiterhin geschrieben werden. Cluster müssen weiterhin konfiguriert werden. Production fällt nachts um zwei nach wie vor aus, und ans Telefon geht ein Mensch, nicht das Modell. Die Arbeit selbst hat sich nicht verändert; die Verteilung der Stunden darin schon. Weniger Syntax, mehr Urteilskraft; weniger Tippen, mehr Review; weniger „wissen wie", mehr „wissen wann und warum".

Cloud Literacy ist nicht das Auswendiglernen von Kommandos. Sie ist die Fähigkeit, eine Entscheidung zu treffen, deren Folgen länger leben als die Session irgendeines Agenten.