Nach dem Commit wird es erst richtig schwer
KI hat das Codeschreiben beschleunigt. Testing, Security und Deployment haben nicht mitgehalten.
In Engineering-Kreisen macht dieses Jahr ein Begriff die Runde: das AI Velocity Paradox. Schicker Name, einfache Beobachtung.
KI-Agents haben das Schreiben von Code dramatisch beschleunigt. Aber Testing, Security, CI/CD und Deployment? Genauso langsam wie vor zwei Jahren. In vielen Organisationen sogar langsamer — weil jetzt mehr Code durch Pipelines fließt, die für dieses Volumen nie gebaut wurden.
Der Engpass hat sich verschoben. Die meisten Teams starren noch auf den alten.
Der Inner Loop ist schnell geworden
Wer im letzten Jahr mit Cursor, Claude Code oder GitHub Copilot gearbeitet hat, kennt das Gefühl. Der „Inner Loop“ — Code schreiben, lokal ausführen, iterieren — hat sich grundlegend verändert.
2024 fühlte sich die Arbeit mit einer KI an wie die Zusammenarbeit mit einem sehr schnellen, aber unzuverlässigen Junior-Entwickler. Man musste alles vorkauen. Anfang 2026 navigieren die besten Agents eigenständig durch Codebases, planen Änderungen über mehrere Dateien und iterieren gegen Tests ohne ständige Anleitung. Sie sind keine Senior Engineers — ihnen fehlt das Urteilsvermögen, was man nicht bauen sollte — aber der Output ist beeindruckend.
Ich habe darüber schon geschrieben: KI macht Code billig. Vibe Coding ist nur Rapid Prototyping. Der Inner Loop ist gelöst, oder fast.
Und es geht nicht nur um Geschwindigkeit. Agents machen inzwischen Dinge, die sich die meisten Entwickler sparen würden — ein Legacy-Modul refactoren, bevor sie ein Feature einbauen, drei Ansätze ausprobieren und den saubersten wählen, umfassende Tests als Teil der Implementierung schreiben statt als Nachgedanken. Die Qualitätsobergrenze des Inner Loop ist zusammen mit der Geschwindigkeit gestiegen.
Aber was ich bis vor kurzem nicht voll erfasst hatte — und was in jedem Gespräch mit Engineering-Leads gerade aufkommt: Ein schneller Inner Loop heißt nicht, dass Software schneller ausgeliefert wird. Es heißt, dass mehr Code in der Pipeline landet. Und die Pipeline war schon vorher das schwächste Glied.
Der Outer Loop knickt ein
Der „Outer Loop“ ist alles zwischen Commit und Produktion: CI-Builds, Testsuiten, Security-Scans, Compliance-Checks, Code Review, Staging, Deployment.
Die meisten dieser Prozesse wurden für menschliche Geschwindigkeit gebaut. Ein Team von fünf Entwicklern, das ein paar Pull Requests pro Tag produziert. Manuelle Review-Gates, bei denen ein Senior Engineer oder ein Security-Team Änderungen freigibt.
Jetzt stell dir vor, dieselben Pipelines verarbeiten den Output von Agents, die Pull Requests in Minuten generieren. Die Rechnung geht nicht auf.
Die Zahlen sprechen für sich. 63 % der Organisationen sagen, sie liefern schneller seit sie KI einsetzen. Aber 45 % der Deployments mit KI-generiertem Code verursachen Probleme in Produktion. Noch mal: fast die Hälfte. Schneller liefern und dabei mehr kaputt machen ist kein Produktivitätsgewinn. Es ist eine Haftung.
Und die Probleme sind nicht immer dramatisch. Oft ist es eine schleichende Erosion. CI-Queues stauen sich, weil die Pipeline nicht für diesen Durchsatz gebaut wurde. Security-Findings häufen sich in einem Backlog, das niemand reviewt. Pull-Request-Freigaben werden zu Stempeln, weil Reviewer nicht mehr hinterherkommen. Die Organisation meldet höhere Velocity auf dem Papier, während die Zuverlässigkeit dessen, was ausgeliefert wird, leise abnimmt.
Der DORA-Report 2025 hat das präzise erfasst: Organisationen berichteten selbst, dass KI den Delivery-Durchsatz positiv beeinflusst hat. Aber objektive Daten zeigten keine Reduktion von Reibung oder Burnout bei Entwicklern. KI repariert keine schwache Delivery-Pipeline. Sie flutet sie.
Manuelle Gates skalieren nicht
Das Muster sehe ich in den meisten Organisationen:
- Ein Entwickler (oder ein Agent) öffnet einen Pull Request
- Ein menschlicher Reviewer liest das Diff
- Vielleicht macht ein Security-Team eine manuelle Prüfung
- Jemand klickt auf „Approve“
- CI läuft, und wenn es grün ist, wird deployed
Das hat funktioniert, als man zehn Pull Requests pro Tag hatte. Es funktioniert nicht, wenn Agents fünfzig generieren. Der Reviewer wird zum Engpass. Reviews werden oberflächlicher. Dinge rutschen durch.
Die Antwort ist nicht „schneller reviewen.“ Die Antwort ist: Das meiste, was Reviewer prüfen, braucht gar keinen Menschen.
Was fängt ein typisches Code Review auf? Stil-Verletzungen. Fehlende Tests. Verwundbare Dependencies. Hardcoded Secrets. Inkonsistente Benennung. Das ist alles wichtig — aber es ist auch deterministisch. Eine Maschine prüft das schneller, konsistenter und ohne Review-Müdigkeit um 16 Uhr am Freitag.
Die Dinge, die wirklich einen Menschen brauchen — Architekturentscheidungen, Business-Logik-Korrektheit, Abwägung von Trade-offs — genau das geht unter, wenn der Reviewer in fünfzig Diffs versinkt und anfängt zu überfliegen.
Leitplanken statt Schranken
Shift left. Alles automatisieren. Schnelle Feedback-Loops. Das sagen wir in DevOps seit einem Jahrzehnt. Die Prinzipien sind nicht neu. Neu ist der Preis dafür, sie zu ignorieren. Als der Inner Loop auf menschlicher Geschwindigkeit lief, war ein halb-manueller Outer Loop erträglich — langsam, nervig, aber er hielt mit. Wenn der Inner Loop auf Agent-Geschwindigkeit läuft, wird jeder manuelle Schritt zur Mauer.
Ist diese Dependency verwundbar? Steckt ein hardcoded Secret im Commit? Wird der Test-Coverage-Schwellenwert erreicht? Besteht die Infrastructure-as-Code-Validierung? Das sind Ja-oder-Nein-Fragen. Die brauchen keinen Menschen — die brauchen eine Policy, die automatisch läuft, bei jedem Commit, bevor irgendjemand ein Pull-Request-Review öffnet.
Das Ziel: 80–90 % der bisherigen manuellen Checks als automatisierte Policies direkt in die Pipeline einbetten. Menschen kommen für die 10–20 % ins Spiel, die tatsächlich Urteilsvermögen brauchen. Es geht nicht darum, Menschen aus dem Prozess zu entfernen. Es geht darum, Menschen von der deterministischen Arbeit zu befreien, damit sie Kapazität für die Entscheidungen haben, die zählen.
Und im Idealfall blockiert die Pipeline nicht einfach, wenn etwas fehlschlägt. Sie gibt den Fehler als Kontext an den Coding Agent zurück. Der Agent bekommt eine weitere Chance, das Problem zu beheben — innerhalb strikter Grenzen. Wenn er es nach ein paar Versuchen nicht lösen kann, eskaliert das System an einen Menschen.
Das ist es, was „Closing the Loop“ bedeutet: Der Outer Loop spricht zurück zum Inner Loop. Nicht über ein Jira-Ticket drei Tage später. Im selben Workflow, in Echtzeit.
Platform Engineering ist das eigentliche Investment
Diese automatisierten Pipelines zu bauen ist nichts, was einzelne Entwickler nebenbei erledigen. Das ist Infrastrukturarbeit. Sie braucht dedizierte Platform-Engineering-Teams, deren Aufgabe es ist, den sogenannten „Golden Path“ zu konstruieren — einen standardisierten, sicheren Weg vom Commit bis in Produktion.
Ein ordentlicher Golden Path deckt vier Bereiche ab:
- Governance: Soll diese Pipeline überhaupt laufen, angesichts bestehender Policy-Vorgaben?
- Integration: Schnelles Feedback an den Entwickler oder Agent — die Verbindung zum Inner Loop.
- Supply-Chain-Vertrauen: Provenienz, SBOMs, kryptografische Verifikation, dass das Artefakt nicht manipuliert wurde.
- Delivery: Der eigentliche Push in Produktion, mit Rollback-Fähigkeit wenn etwas schiefgeht.
Die meisten Organisationen haben Teile davon. Sehr wenige haben alle vier als zusammenhängendes System.
Das Denkmodell, zu dem ich immer wieder zurückkomme: Wenn das, was den Code produziert, agentisch ist, muss das, was den Code ausliefert, auch agentisch sein. Man kann keinen autonomen Inner Loop mit einem manuellen Outer Loop koppeln und erwarten, dass das System hält. Die Delivery-Seite braucht dasselbe Maß an Autonomie, Feedback und Selbstkorrektur, das die Coding-Seite bereits hat.
Hier schneidet die KI-Verstärkung in beide Richtungen. Hat die Organisation starke Engineering-Grundlagen — saubere Pipelines, gute Testabdeckung, klare Ownership — macht KI alles schneller und besser. Sind die Grundlagen schwach — fragile Skripte, instabile Tests, manuelle Übergaben — macht KI diese Probleme schlimmer, schneller, in einem Ausmaß, das schwerer zu entwirren ist. Es gibt kein Neutral. KI ist ein Multiplikator, und Multiplikatoren wirken in beide Richtungen.
Die Organisationen, die das 2026 richtig machen, sind nicht die mit der schnellsten Codegenerierung. Es sind die, deren Delivery-Pipelines das Volumen aufnehmen können, ohne die Qualität zu opfern.
Worauf es hinausläuft
KI hat den Inner Loop schnell gemacht. Das ist real und wertvoll. Aber Geschwindigkeit ohne Sicherheit ist nur Risiko im großen Maßstab.
Die Engineering-Aufgabe hat sich verschoben. Es geht nicht mehr um „Wie schreibe ich schneller Code?“ Es geht um „Wie liefere ich sicher aus, in der Geschwindigkeit, die Agents generieren?“
Wenn das Team Prompts und Modellauswahl optimiert, aber die CI/CD-Pipeline seit zwei Jahren nicht angefasst hat — löst es das falsche Problem.
Der Engpass hat sich verschoben. Zeit, ihm zu folgen.
