Eine beschleunigte Codeproduktion ohne Anpassung des restlichen Prozesses führt nicht zu einer schnelleren Auslieferung, sondern zu einem schnelleren Auftreten von Problemen im Produktivbetrieb. Die Geschwindigkeit eines Entwicklungsteams bemisst sich nicht daran, wie schnell es Code schreibt, sondern daran, wie schnell es Änderungen sicher umsetzen kann. Diese beiden Aspekte haben sich in den letzten zwei Jahren zunehmend voneinander entkoppelt.
Es handelt sich um ein messbares Phänomen, nicht um einen Verdacht.
Der DORA-Bericht 2024 von Google Cloud, für den rund 39.000 Fachleute befragt wurden, ergab, dass ein Anstieg der KI-Nutzung um 251 % mit einem Rückgang von 1,5% im Lieferdurchsatz und von 7.2% in Stabilität. Die Erklärung der Autoren selbst lautet nicht, dass der Code schlechter sei, sondern dass die Größe der Änderungspakete zunehme: Es werde mehr auf einmal gesendet, es werde weniger gründlich geprüft und es werde mit einem höheren Risiko bereitgestellt.
Die METR-Studie vom Juli 2025 lieferte weitere Erkenntnisse. In einer kontrollierten Studie mit 16 erfahrenen Entwicklern, die 246 reale Aufgaben bearbeiteten, benötigten die Teilnehmer mit KI-Unterstützung 191 TP3Ts länger, obwohl sie eine Zeitersparnis von 241 TP3Ts erwartet hatten und nach dem Test immer noch glaubten, 201 TP3Ts schneller gewesen zu sein. Es ist anzumerken, dass METR selbst das Studiendesign 2026 auf mögliche Selektionsverzerrungen überprüfte, und eine größere Kohorte zeigte einen deutlich geringeren Unterschied: Das genaue Ergebnis wird derzeit diskutiert.
Unstrittig ist der sekundäre Befund, und dieser ist für jede weitere Vorgehensweise von entscheidender Bedeutung: Die subjektive Geschwindigkeitswahrnehmung und die tatsächliche Geschwindigkeit sind voneinander zu unterscheiden.. Ein Team kann das Gefühl haben, viel schneller voranzukommen, obwohl das System länger braucht, um produktionsreif zu werden.
Die Größe der Änderung ist der oft übersehene Faktor hinter den meisten Implementierungsproblemen. Eine kleine Änderung wird gründlich geprüft, umfassend getestet und schnell implementiert. Schlägt sie fehl, lässt sich die Ursache innerhalb von Minuten identifizieren. Bei einer großen Änderung ist all das nicht möglich.
Variable | Kleingeld | Große Veränderung |
|---|---|---|
Qualität der Rezension | Es ist vollkommen verstanden | «"Das erscheint vernünftig."» |
Testabdeckung | Überprüfbar | Teilweise in der Praxis |
Diagnosezeit, falls es fehlschlägt | Minuten | Stunden oder Tage |
Kosten der Umkehrung | Niedrig | Halt: Es zieht andere Dinge mit sich. |
Einsatzrisiko | Beschränkt | Angesammelt |
Bis vor Kurzem stellte der Aufwand für das Schreiben von Code eine natürliche Grenze für die Losgröße dar. Da diese Grenze nun wegfällt, wächst die Losgröße, sofern sie nicht explizit eingeschränkt wird. Diese Entscheidung – die Begrenzung des Änderungsumfangs – ist wahrscheinlich die kosteneffektivste Maßnahme, die einem Entwicklungsteam heutzutage zur Verfügung steht.
Die Messung von Codezeilen, abgeschlossenen Aufgaben oder der «Produktivität pro Entwickler» verschärft die Situation aktiv, da sie genau das Verhalten belohnt, das das Problem verursacht. Die vier DORA-Metriken bleiben der angemessene Standard:
Einsatzhäufigkeit. Wie häufig wird ein Produkt in Produktion genommen? Eine hohe Frequenz bedeutet kleine Losgrößen.
Lieferzeit für das Wechselgeld. Vom Moment des Schreibens bis zur Produktion. Es misst den gesamten Prozess, nicht nur den Schreibprozess selbst.
Änderung der Ausfallrate. Wie hoch ist der Prozentsatz der Einsätze, der zu einem Zwischenfall führt? Dies ist das Gegengewicht zur Geschwindigkeit.
Zeit bis zur Wiederherstellung des Dienstes. Wie lange dauert die Wiederherstellung? Sie misst die tatsächliche Betriebsfähigkeit.
Die ersten beiden Kennzahlen messen die Geschwindigkeit, die letzten beiden die Stabilität, und sie müssen gemeinsam betrachtet werden. Ein Team, das die ersten beiden verbessert, aber die letzten beiden verschlechtert, hat sich nicht verbessert: Es hat die Arbeit lediglich in die Zukunft und zum Support-Team verlagert.
Begrenzen Sie den Umfang der Änderungen. Die einfachste und effektivste Maßnahme. Sie zwingt dazu, die Arbeit in verständliche Einheiten zu unterteilen und stellt die Qualität der Rezension wieder her.
Investiere in Tests, bevor du auf Geschwindigkeit setzt. Je mehr Code generiert wird, desto wichtiger wird das Sicherheitsnetz, nicht weniger. Ohne zuverlässige Tests ist Drosselung ein wiederholtes Glücksspiel.
Automatisierte Bereitstellung und Rücknahme. Wenn die Bereitstellung teuer ist, sammelt das Team so lange Änderungen an, bis es sich lohnt, und die große Menge wird zurückgegeben.
Stabilität lässt sich mit der gleichen Sichtbarkeit messen wie Geschwindigkeit. Wenn im Dashboard des Komitees nur Lieferungen angezeigt werden, optimiert das Team die Lieferungen.
Belohnen Sie keine isolierte Geschwindigkeit. Anreize erzeugen Verhalten. Wird das Gesendete gefeiert, anstatt das Ertragene, wird mehr gesendet und weniger ertragen.
In vielen Gremien herrscht die Erwartung, dass KI-Unterstützung innerhalb desselben Zeitraums die doppelte Leistung erbringen sollte. Diese Erwartung erzeugt den Druck, der die Stabilität untergräbt.
Das offene Gespräch besteht aus zwei Teilen. Erstens: Die Codegenerierung hat sich tatsächlich spürbar und messbar beschleunigt. Zweitens: Die Bereitstellung ist ein umfassenderer Prozess – Verstehen, Überprüfen, Testen, Integrieren, Bereitstellen und Betreiben – und beschleunigt sich nur, wenn das Gesamtpaket betrachtet wird.
Übersetzt in einen Satz, der in einem Rat funktioniert: Wir haben die Kosten eines Teils des Prozesses gesenkt, nicht die des gesamten Prozesses.. Um von dieser Verbesserung zu profitieren, muss man in den Rest investieren, nicht das Doppelte des Gleichen verlangen.
Dies ist die gleiche Schlussfolgerung, die aus architektonischer Sicht gezogen wird, und deshalb konzentriert sich die Debatte nun wieder auf den Entwurf statt auf die Ausführung, wie wir bereits besprochen haben. Der Flaschenhals ist einmal mehr die Architektur.
Es beschleunigt die Codegenerierung, aber nicht unbedingt die Auslieferung. Der DORA-Bericht von 2024 stellte fest, dass ein Anstieg der KI-Nutzung um 251 Tsd. 300 Tsd. mit einem Rückgang des Durchsatzes um 1,51 Tsd. 300 Tsd. ...
Denn sie bestimmt die Qualität des Reviews, die tatsächliche Testabdeckung, die Zeit zur Fehlerdiagnose und die Kosten für die Rückgängigmachung. Der Aufwand für die Codeentwicklung setzte der Größe eine natürliche Grenze; da diese Grenze wegfällt, muss sie explizit begrenzt werden.
Die vier DORA-Metriken sind: Bereitstellungshäufigkeit, Änderungsbereitstellungszeit, Änderungsfehlerrate und Wiederherstellungszeit des Dienstes. Die ersten beiden messen die Geschwindigkeit, die letzten beiden die Stabilität; sie sollten gemeinsam betrachtet werden.
Eine METR-Studie aus dem Jahr 2025 ermittelte eine Verzögerung von 191 TP3T bei erfahrenen Entwicklern, die bis 241 TP3T eine Beschleunigung erwartet hatten. METR selbst überprüfte später das Studiendesign auf mögliche Verzerrungen, und eine größere Kohorte zeigte einen geringeren Unterschied. Das übereinstimmende Ergebnis ist, dass die wahrgenommene und die tatsächliche Geschwindigkeit voneinander abweichen.
Zuverlässige automatisierte Tests, automatisierte Bereitstellung und Rücknahme sowie eine explizite Begrenzung des Änderungsumfangs sind unerlässlich. Mit zunehmendem Änderungsvolumen gewinnen die Sicherheitsvorkehrungen und die Möglichkeit zur Rücknahme an Bedeutung, nicht an Bedeutung.
Denn sie belohnen das Verhalten, das das Problem verursacht: höhere Produktionsmengen zu produzieren, ohne die zuverlässige Lieferung in die Produktion sicherzustellen. Der Anreiz bestimmt das Verhalten, und die Messung des Outputs anstelle der Ergebnisse verlagert die Kosten auf Support und zukünftige Bedarfe.
Liefert Ihr Team schneller oder produziert es einfach nur mehr? Wir analysieren den gesamten Lieferprozess – Überprüfung, Test, Bereitstellung und Betrieb – und zeigen Ihnen, wo der eigentliche Engpass liegt. Lass uns reden →
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
