Wo KI-Produktivität entsteht und verloren geht
KI beschleunigt das Schreiben von Code, und das war selten der Bottleneck. Der Engpass wandert in Review, Tests, Change-Freigabe und Betrieb. Gewinne auf Systemebene entstehen deshalb durch bessere Abstimmung und verbesserte Übergaben, nicht durch schnellere Codegenerierung.
Verfasst von
-
Benedikt Stemmildt Gründer & Co-CEO
Aktualisiert:
Einstieg 2
Unsere Position. Wir erwarten, dass der Bottleneck einen Schritt vor die Stelle wandert, die ihr gerade repariert habt (öffnet in einem neuen Tab). Begleitet eine fertige Änderung bis in Produktion und schreibt jede Warteschlange auf, in der sie liegt. Denn eine Factory verkürzt den Build und ändert nichts an der Wartezeit drumherum (öffnet in einem neuen Tab).
Den größten Teil ihrer Lead Time verbringt eine Änderung mit Warten, Freigaben und Abstimmung. Schnelleres Coden spart deshalb nur einen kleinen Teil des Ganzen.
Warum beschleunigt schnelleres Coden die Auslieferung kaum?
DX hat Daten von fast 140.000 Engineers ausgewertet. Aufs Jahr gerechnet verlieren sie mehr Zeit durch Wartezeiten in der CI, aufgeblähte Meetings, Kontextwechsel und Freigabe-Bottlenecks, als KI beim Coden einspart. DX folgert: KI optimiert lokal, und globale Optimierung verlangt, die menschlichen und systemischen Prozesse rund um den Code zu reparieren (DX AI Impact Report).
Atlassians Zahlen passen dazu. Coden und Fehlerbeheben machen weniger als 25 % eines Arbeitstags von Entwickler:innen aus. Die übrige Zeit entfällt auf Übergaben und das Zusammensuchen von Kontext über die mehr als 150 SaaS-Tools eines typischen Großunternehmens. Die Hälfte der befragten Entwickler:innen verliert pro Woche mehr als 10 Stunden durch Ineffizienzen (Atlassian-Talk - Developer experience fireside (öffnet in einem neuen Tab); Atlassian - State of Developer Experience 2025, Talk (öffnet in einem neuen Tab)).
Golo Roden spitzt das am 11. Februar 2026 zu. Der Engpass war nie das Tempo, in dem Code entsteht, sondern das Tempo, in dem Verständnis entsteht. Missverständnisse zwischen Fachexpert:innen und Entwickler:innen zeigen sich spät und erzeugen Nacharbeit. Dasselbe Versprechen vom “end of developers” ist schon mit CASE-Tools, 4GLs, RAD und Low-Code gescheitert. Roden empfiehlt Denkwerkzeuge wie Amazons Working Backwards. Der ROI von Verständnis bleibt nämlich unsichtbar und zeigt sich darin, dass Probleme ausbleiben (heise - Der wahre Engpass: Warum schnelleres Coden Projekte nicht beschleunigt (öffnet in einem neuen Tab)).
Ein Systemprinzip besagt, dass 90 bis 95 % der Produktivität vom System abhängen, nicht von der einzelnen Person. Es ist die gängige Erklärung dafür, warum individuelles Tooling allein so wenig bewegt (DX - AI strategy playbook, Talk (öffnet in einem neuen Tab)).
Wohin wandert der Bottleneck?
Danach wandert der Bottleneck weiter. Intercom hat den Durchsatz verdoppelt und nennt Review als aktuellen Engpass (Intercom-Talk - Doubling engineering throughput (öffnet in einem neuen Tab)). Review lässt sich aber angehen. Atlassians Agent Rovo Dev führt sofort ein erstes PR-Review durch und hat die PR-Zykluszeit um 45 % gesenkt (Atlassian - State of Developer Experience 2025, Talk (öffnet in einem neuen Tab)). Öffentliche Beispiele zielen auf Engpässe außerhalb der Codegenerierung. Morgan Stanley schreibt Spezifikationen für Legacy-Code, Zapier setzt Agents im Onboarding ein und Spotify automatisiert den Kontext bei Incidents (DX - AI strategy playbook, Talk (öffnet in einem neuen Tab)).
Die Continuous-Delivery-Community beziffert die Obergrenze. Laut ihren Value-Stream-Zahlen braucht eine durchschnittliche Änderung im Großunternehmen rund 281 Tage von der Idee bis in Produktion. Etwa 32 davon entfallen aufs Coden. Doppelt so schnelles Coden spart also rund 6 % der Lead Time. Rund 88 % der Lead Time sind Warten, Freigaben und Abstimmung (MinimumCD.org and DojoConsortium.org - Why Coordination, Not Coding, Sets the Pace (öffnet in einem neuen Tab), Stand Juni 2026).
Aus diesem Verhältnis folgt ihr Rat. Wer die Codeerstellung beschleunigt, bevor die Reibung dahinter verschwunden ist, erhöht vor allem Work in Progress und Risiko. Prozessarbeit kommt deshalb vor schnellerer Generierung (MinimumCD.org and DojoConsortium.org - The New Bottleneck (öffnet in einem neuen Tab), Stand September 2026).

Abbildung 1. Doppelt so schnelles Coden nimmt einer Änderung von 281 Tagen 16 Tage ab, etwa 6 Prozent. Die 249 Tage Warten, Freigaben und Abstimmung bewegen sich nicht. Gezeichnet von hackers&wizards nach den Value-Stream-Zahlen in MinimumCD.org and DojoConsortium.org - Why Coordination, Not Coding, Sets the Pace (öffnet in einem neuen Tab), CC BY 4.0, Stand Juni 2026.
Derselbe Leitfaden nennt die Kräfte, die Abstimmung so teuer machen (MinimumCD.org and DojoConsortium.org - Why Coordination, Not Coding, Sets the Pace (öffnet in einem neuen Tab), Stand Juni 2026):
- Auslastung. Eine Ressource bei 90 % Auslastung baut eine Warteschlange von etwa dem Neunfachen ihrer Bearbeitungszeit auf. The Phoenix Project hat diesen Zusammenhang bekannt gemacht.
- Abhängigkeiten. Jede Abhängigkeit von einem anderen Team halbiert ungefähr die Chance, pünktlich zu liefern. Bei vier Abhängigkeiten bleiben etwa 6 %, und wer eine entfernt, verdoppelt die Chance wieder.
- Übergaben. Bei jeder Übergabe geht etwa die Hälfte des Verständnisses der ursprünglichen Absicht verloren. Lean Software Development beschreibt das als Verlust impliziten Wissens.
Die Symptome gruppiert der Leitfaden in drei Arten: Konkurrenz um geteilte Personen und Ressourcen, Kopplung an Ergebnis oder Freigabe eines anderen Teams und verlorene Kohärenz des gemeinsamen Verständnisses. Unter allen dreien sieht er eine Wissensabhängigkeit. Eine Abhängigkeit zu entfernen ist deshalb mehr wert als jede Beschleunigung beim Coden.
Review ist nur eine Stelle, an der der Engpass landet. Eine Karte des Delivery-Lebenszyklus nennt fünf, jede mit eigenem Warnsignal (MinimumCD.org and DojoConsortium.org - Where the Bottleneck Moves (öffnet in einem neuen Tab), Stand September 2026):
- Discovery. Der Agent baut schnell das Falsche. Hier hilft KI, Unklarheiten aufzudecken und messbare Akzeptanzkriterien zu entwerfen, bevor die Arbeit beginnt.
- Architektur. Wegen unklarer Service-Grenzen warten Änderungen im Review auf wenige Expert:innen. Das hört auf, sobald Decision Records, Service Maps und automatisierte Abhängigkeitsregeln die Vorgaben tragen.
- Testing. Generierte Tests bestätigen die Implementierung statt der Absicht der Nutzer:innen. Verhaltenstests müssen deshalb gegen bekannte Fehlerfälle geprüft werden.
- Change Management. Ein Fix vom selben Tag wartet auf ein Freigabefenster. Das verlangt Kontrollen in der Automation, Standard-Risikoklassen, kleinere Batches und verlässliches Rollback.
- Betrieb. Der Agent bleibt stecken, weil Ownership und Runbooks in den Köpfen der Leute liegen. Erst ein Katalog, den der Agent durchsuchen kann, löst das.
Woher kommen die echten Gewinne?
Die Gewinne, die es gibt, kommen weniger aus Tippgeschwindigkeit als aus kognitiver Umverteilung. Entwickler:innen schreiben traditionell nur 1 bis 2 Stunden am Tag Code, der Rest ist Routinearbeit. KI übernimmt das Mechanische wie Boilerplate, Nachschlagen und Scaffolding. Das macht Aufmerksamkeit frei für Architektur und die Wahl der richtigen Probleme. Praktiker:innen sehen darin den tieferen Wandel hinter ihren gemessenen Einsparungen von rund 30 % (From Trees to Forest: The Real Impact of AI on Developer Productivity (öffnet in einem neuen Tab)).
Messungen auf Aufgabenebene bestätigen diese Aufteilung. McKinseys interne Daten zeigen bei Code-Dokumentation 45 bis 50 % Verbesserung und bei Codegenerierung 35 bis 45 %. Aufgaben hoher Komplexität gewinnen unter 10 % (From Trees to Forest: The Real Impact of AI on Developer Productivity (öffnet in einem neuen Tab)). DX rankt Use Cases nach dem Anteil der Entwickler:innen, die damit mindestens eine Stunde pro Woche sparen. Ganz oben steht ein interpretierender statt generierender Fall: Stack-Trace-Analyse (DX - AI strategy playbook, Talk (öffnet in einem neuen Tab); Vibe-coding workflows (öffnet in einem neuen Tab)).
Auch wohin die gewonnene Zeit fließt, verschiebt sich. Entwickler:innen nennen inzwischen bessere Codequalität als wichtigsten Zweck der durch KI gesparten Zeit. In der vorigen Ausgabe der Umfrage stand diese Antwort nicht unter den ersten zehn (Atlassian - State of Developer Experience 2025, Talk (öffnet in einem neuen Tab)).
Das zahlt sich nur unter bestimmten Bedingungen aus: modulare, gut getestete Codebases, erfahrene Reviewer:innen und ständige Aufsicht. KI neigt dazu, von der Anforderung abzudriften und ungefragt Features einzubauen (From Trees to Forest: The Real Impact of AI on Developer Productivity (öffnet in einem neuen Tab)).
Wie reagieren Organisationen auf die Gewinne?
Auf Organisationsebene führen Gewinne pro Engineer oft zu mehr Einstellungen statt zu weniger. Die Nachfrage nach Software ist elastisch. Top-Organisationen zeigen einen Rebound-Effekt und bauen Personal auf, wenn KI den Output pro Engineer steigert (Refactoring - How Engineering Teams use AI (öffnet in einem neuen Tab)). Zapier schloss aus den eigenen Gewinnen, dass es schneller einstellen sollte als je zuvor (DX - AI strategy playbook, Talk (öffnet in einem neuen Tab)).
Als Betriebsmodell zeichnet sich “delegate, review and own” ab. KI übernimmt den ersten Durchgang, Engineers reviewen, und Menschen verantworten Architektur und Ergebnisse. Engineers schreiben so weniger selbst und kuratieren mehr. Der Schwerpunkt der Fähigkeiten wandert von Prompt Engineering zu Orchestrierung (How agentic AI will reshape engineering workflows in 2026 (öffnet in einem neuen Tab), Februar 2026, Prognose).
Der Rollout beschleunigt sich, ist aber unreif. Laut KPMGs quartalsweisem Pulse Survey unter Unternehmen mit mehr als 1 Milliarde Dollar Umsatz sprang der Anteil mit Agents voll in Produktion von 11 % im ersten Quartal 2025 auf 42 % im dritten. McKinseys State-of-AI-Studie findet nur 7 % der Organisationen vollständig skaliert, rund 62 % experimentieren noch oder stecken in Piloten. Organisationen mit mehr Use Cases berichten systematisch besseren ROI, und Coding gehört zu den überdurchschnittlichen Bereichen (AI Consulting in Practice - NLW, Superintelligent (öffnet in einem neuen Tab), Talk des Hosts von The AI Daily Brief bei AI Engineer, 18. Dezember 2025).
Verwandte Seiten
- KI-Produktivität: Evidenz und Qualität: was kontrollierte Studien und Telemetrie über Tempo und Defekte messen.
- Impact messen: wie ihr die Lead Time pro Stufe instrumentiert, damit ein schneller Schritt keinen langsamen verdeckt.
- Was KI-Adoption voranbringt: die organisatorischen Bedingungen, die aus Zugang Nutzung machen.
- Agentic Continuous Delivery: wie eine Pipeline Änderungen von Agents an dieselbe Messlatte hält wie die von Menschen.
- Abschied von Agile: McKinseys Studie zum KI-Operating-Model: warum Teamstrukturen aus der Sprint-Ära die Gewinne auf Unternehmensebene deckeln.
Quellen
Delivery-Praxis
- The New Bottleneck (öffnet in einem neuen Tab) - Überblick über den Diagnose-Teil von Agentic Continuous Delivery. Er argumentiert, dass Abstimmung statt Coden das Liefertempo bestimmt, CC BY 4.0.
- Where the Bottleneck Moves (öffnet in einem neuen Tab) - Karte von fünf Delivery-Bottlenecks, die KI-Beschleunigung freilegt, jeweils mit Warnsignal und Gegenmaßnahme, CC BY 4.0.
- Why Coordination, Not Coding, Sets the Pace (öffnet in einem neuen Tab) - Value-Stream-Zahlen sowie Modelle zu Warteschlangen, Abhängigkeiten und Übergaben. Sie zeigen, warum Coden nur einen kleinen Teil der Lead Time ausmacht, CC BY 4.0.