Die gesteigerte Produktivität der Entwickler führte nicht zu einer vergleichbaren Beschleunigung der Releases. Der Grund: Das Nadelöhr hat sich weiter oben im Stack verlagert – in den Bereich der Formalisierung der Anforderungen und der Überprüfung des Ergebnisses.
Mit dem Aufkommen von KI-gestütztem Coding erwarteten Teams eine lineare Beschleunigung der Auslieferung. In der Praxis wurde jedoch nur eine Phase beschleunigt – das Schreiben des Codes. Danach beginnt das System zu degradieren: Die Warteschlange für Reviews wächst, die Abstimmungszeiten nehmen zu, die Überprüfung der Korrektheit wird komplexer. Daten von Faros AI zeigen ein charakteristisches Muster: Bei einem Anstieg der Aufgabenanzahl um 21 % und einer fast verdoppelten Anzahl von Merges stieg die Review-Zeit um 91 %. Das ist ein klassischer Fall lokaler Optimierung, die den Druck auf benachbarte Phasen erhöht. Code ist kein Engpass mehr – das Verständnis, was genau gebaut werden soll und wie man sicherstellt, dass es korrekt funktioniert, ist zum Engpass geworden.
Als Reaktion darauf ändert sich das Arbeitsmodell selbst. Der „White-Box“-Ansatz – jede Zeile zu lesen – ist bei der Generierung von Tausenden von Zeilen pro Stunde nicht skalierbar. „Black Box“ – das Ergebnis ohne Prüfung zu akzeptieren – ist in der Produktion nicht anwendbar. Die Praxis verschiebt sich hin zu „Grey Box“: Der Engineer ist für zwei Kontrollpunkte verantwortlich – die Formulierung der Spezifikation und die Verifikation des Ergebnisses anhand beobachtbarer Artefakte. Dadurch verschiebt sich der Fokus von der Implementierung auf die Intention. Der Trade-off ist offensichtlich: Wir verlieren die Detailkontrolle über den Code, gewinnen aber an Geschwindigkeit, wenn wir in der Lage sind, Anforderungen zu formalisieren und das Systemverhalten anhand testbarer Kriterien zu überprüfen.
Die Umsetzung dieses Ansatzes erfordert eine Umstrukturierung der Prozesse. Die Spezifikation wird zum zentralen Artefakt: Sie muss präzise genug sein, damit ein Agent sie ausführen kann, und ausreichend prüfbar, damit das Ergebnis ohne Lesen der Implementierung validiert werden kann. In der Praxis bedeutet das:
– explizite Akzeptanzkriterien und Abdeckung von Randfällen
– Festhalten von Architekturentscheidungen als Teil der Spezifikation
– Verschiebung des Reviews von „wie wurde es geschrieben“ zu „ist bewiesen, dass es funktioniert“
– Einsatz von Metriken (DORA) und Priorisierung (RICE) zur Beseitigung von Engpässen im DevEx
Dies beeinflusst auch die Teamstruktur. Wenn der Hauptwert in der Abstimmung der Intention liegt, ist Kommunikation kein Overhead mehr, sondern wird zur Hauptaufgabe. Kleine Teams profitieren nicht wegen geringerer Koordinationskosten, sondern weil sie schneller ein gemeinsames Verständnis erreichen und präzisere Spezifikationen formulieren.
Das verändert letztlich den „Verantwortungsvertrag“: Der Engineer ist nicht mehr Autor jeder einzelnen Codezeile, bleibt aber Eigentümer des Ergebnisses. Die Kontrolle wird eine Ebene höher gehoben – vom Code zur Intention. Metriken bestätigen diese Verschiebung, aber die endgültigen Effekte hängen von der Reife der Prozesse ab: Ohne Investitionen in Spezifikation und Verifikation führt die Beschleunigung des Codings nur zu einer Umverteilung der Verzögerungen, nicht zu deren Beseitigung.