Das Engineering-Team von Agoda hat viel Zeit in die Förderung von KI-Programmierwerkzeugen investiert und anschließend eine Bilanz gezogen. Das Ergebnis gibt zu denken:
Die Produktivität einzelner Entwickler stieg, aber die Gesamtgeschwindigkeit der Projektauslieferung änderte sich kaum.
Dies ist kein Problem, das nur Agoda betrifft. Faros AI hat unternehmensübergreifende Daten zusammengestellt und liefert ernüchternde Zahlen:
Teams mit hoher KI-Nutzung verzeichneten eine Steigerung der PR-Merges um 98 % und der erledigten Aufgaben um 21 %. Gleichzeitig stieg die Review-Zeit für PRs um 91 %.
Mehr Output, aber langsamere Reviews. Die beiden Effekte heben sich nahezu gegenseitig auf.
Wo der wahre Engpass liegt
Das Agoda-Engineering-Team ist der Ansicht: Das Problem liegt darin, dass "Codieren nie der Hauptengpass bei der Softwareauslieferung war".
KI-Vervollständigung macht das Schreiben von Code schneller. Aber das Schreiben von Code ist nur ein Schritt in der Pipeline – davor liegen Anforderungsanalyse, Systemdesign und Abstimmung der technischen Lösung, danach kommen Code-Review, Tests, Integration und Deployment.
Wenn man die Geschwindigkeit des mittleren Schritts verdreifacht, wird die gesamte Pipeline nicht automatisch dreimal so schnell.
Wenn KI die Code-Produktion explosionsartig steigert, wird die Fähigkeit, "diesen Code zu verdauen", zum neuen Engpass:
- Jeder PR enthält mehr Code (KI-generierter Code ist oft nicht präzise genug)
- Code-Reviews müssen mehr prüfen
- Aber die Zeit der Senior Engineers ist begrenzt
Der Engpass verlagerte sich von "langsamem Codieren" zu "langsamem Reviewen", der tatsächliche Auslieferungsrhythmus verbesserte sich nicht.
Das tiefere Problem: Spezifikation
Agoda-Ingenieur Leonardo Stern geht noch weiter: Er sieht die wirklich knappe Ressource weiter oben – nicht das Review, sondern die Spezifikation – die Fähigkeit, vage Geschäftsanforderungen in klare, umsetzbare technische Spezifikationen zu übersetzen.
Früher verbrachten Ingenieure viel Zeit mit dem Schreiben von Code, die Spezifikation konnte vager sein, weil "man es beim Schreiben schon klären würde".
Heute gibt man eine vage Anforderung an die KI, die dann Code generiert, der "nutzbar aussieht", aber in die falsche Richtung geht. Dann überarbeitet man die Spec, die KI generiert neu – mehrere Runden. Oberflächlich ist die Code-Produktion hoch, tatsächlich probiert man mit Code herum, die Effizienz ist gering.
Hochpräzise Anforderungsspezifikationen werden zum zentralen Engineering-Artefakt. Nicht der Code selbst, sondern "wie man beschreibt, was man will".
Sterns "Gray-Box"-Ansatz
Stern schlägt eine Arbeitsweise namens "Gray Box" vor, die zwischen zwei Extremen liegt:
- White Box: Jede von der KI generierte Codezeile wird geprüft, man trägt die volle Verantwortung für die Implementierungsdetails
- Black Box: Die KI schreibt den Code und er geht direkt live, man ist für das Ergebnis verantwortlich, kümmert sich aber nicht um den Prozess
- Gray Box: Eingriff an zwei entscheidenden Punkten – präzise Spezifikation schreiben und verifizieren, ob das Ergebnis der Spezifikation entspricht
Die Kernlogik der Gray Box: Man muss nicht verstehen, mit welcher Methode die KI das Problem löst, aber man muss klar sagen können, "was als gelöst gilt", und verifizieren können, dass es tatsächlich gelöst wurde.
Das Wesen dieser Methode ist, die Zeit und Aufmerksamkeit der Ingenieure auf das zu konzentrieren, was KI am schlechtesten kann – die Definition von Absichten und die Verifikation von Ergebnissen, statt auf Implementierungsdetails.
Wohin entwickelt sich die Rolle des Ingenieurs?
In der traditionellen Rollenannahme des Softwareingenieurs war "guten Code schreiben" die Kernkompetenz.
Diese Annahme gerät nun ins Wanken. Wenn KI Code von akzeptabler Qualität schreiben kann, wo liegt dann die Knappheit der Ingenieure?
Aus der Praxis von Unternehmen wie Agoda deutet die Antwort in diese Richtung:
- Menschen, die Geschäftsprobleme in präzise technische Spezifikationen übersetzen können
- Menschen, die effektive Verifikationsschemata entwerfen können
- Menschen, die beurteilen können, ob der von der KI erzeugte Code tatsächlich das richtige Problem löst
Das bedeutet nicht, "die Fähigkeit, Code zu schreiben, ist unwichtig" – sondern dass diese Fähigkeit von einer knappen Ressource zur Grundvoraussetzung wird, die wirkliche Differenzierung liegt weiter upstream.
In Sterns Worten: Die Autorität des Menschen verlagert sich vom "Code schreiben" zum "Absichten definieren". Dies ist eine Verschiebung auf eine höhere Abstraktionsebene, kein Verschwinden von Fähigkeiten.
Wie das Management dies sehen sollte
Für Engineering-Manager liefert die Agoda-Studie eine direkte Handlungsempfehlung: Messen Sie den Wert von KI nicht an der Code-Produktion.
PR-Anzahl, Codezeilen, erledigte Aufgaben – all diese Kennzahlen werden durch KI-Tools schöner aussehen. Aber wenn die ausgelieferten Funktionen nicht mehr, nicht schneller und nicht besser werden, sind diese Zahlen nur Zahlen.
Die wirklich verfolgenswerten Kennzahlen sind: Feature-Release-Zyklus, Fehlerrate in der Produktion, End-to-End-Zeit von der Anforderung bis zur Auslieferung. Diese Zahlen zeigen, ob KI dem Team wirklich hilft oder nur dabei, die GitHub-Statistiken aufzuhübschen.
Wenn Ihnen das nächste Mal jemand mit PR-Merge-Zahlen den ROI eines KI-Tools präsentiert, können Sie fragen: Und wie sieht es mit der Review-Zeit aus?
Quellenangabe: CocoLoop, AI Coding Assistants Haven't Sped Up Delivery Because Coding Was Never the Bottleneck (InfoQ)