Der KI-Engpass: Warum schnellerer Code keine schnelleren Produkte bringt
Dieser Artikel wurde mit KI-Unterstützung verfasst und vom agenthouse-Team redigiert. Die Illustrationen sind KI-generiert.
KI hat das Schreiben von Softwarecode günstiger und deutlich schneller gemacht. Viele Teams haben erwartet, dass Features im selben Tempo bei den Kunden ankommen. Die meisten stellen fest: Das tun sie nicht. Eine Idee aus dem Jahr 1984 erklärt, warum.
Jeder Prozess ist nur so schnell wie sein langsamster Schritt
1984 veröffentlichte der Physiker und Managementdenker Eliyahu M. Goldratt The Goal (deutsch: Das Ziel), einen Roman über einen Werksleiter, der eine angeschlagene Fabrik retten will. Das Buch führte die Theory of Constraints ein, die Engpasstheorie. Ihr Kern ist einfach: Jeder Schritt eines Prozesses hat seinen eigenen Durchsatz, und das Gesamtsystem kann nie mehr liefern als sein langsamster Schritt, der Engpass. Jeden anderen Schritt zu beschleunigen, hilft nicht. Es staut nur Bestand vor dem Engpass auf.
Goldratt wandte die Idee zunächst in der Fertigung an. Später übertrug er sie auf das Projektmanagement, und Bücher wie The Phoenix Project brachten sie in die IT und die Softwareentwicklung.
Der Takt, der die Arbeit vorantreibt
Prozesse folgen einem Rhythmus. Lean Manufacturing nennt ihn den Takt: das Tempo, in dem Arbeit von einem Schritt zum nächsten weitergehen muss. Goldratt beschrieb dasselbe als Trommel, die vom Engpass geschlagen wird und allen anderen das Tempo vorgibt.
Oft ist das Signal kaum sichtbar. Denken Sie an die Glocke in einer Restaurantküche, die dem Kellner sagt, dass ein Gericht servierbereit ist, oder an den Pfiff, der einem Zug die Abfahrt freigibt. Wenn alle Schritte im selben Takt arbeiten, ist der Prozess im Einklang.
Softwareentwicklung ist selten so im Einklang. Ob Wasserfall oder agil: Perfekt ausbalancierte Durchläufe sind die Ausnahme. Anforderungen stocken, Reviews stapeln sich, Releases warten auf Tests.
Was KI verändert: Ein Schritt ist viel schneller geworden
Generative KI hat genau einen Schritt der Kette beschleunigt: das Schreiben von Code. Was früher Tage dauerte, dauert heute Stunden, manchmal Minuten. Das setzt den Prozess von zwei Seiten unter Druck.
Vorgelagert entsteht bei der Frage „Was sollen wir bauen?“ ein Vakuum. Wenn die Umsetzung nicht mehr der begrenzende Faktor ist, zählt die Qualität des Inputs umso mehr. Business Development und Produktmanagement müssen echte Kundenbedürfnisse schneller und genauer verstehen als zuvor. Sonst baut das Team effizient Features, die niemand will und niemand bezahlt. Schneller Code macht eine schlechte Idee nicht besser. Er bringt sie nur früher auf den Markt.
Nachgelagert entsteht ein neuer Engpass. Entwickler, die KI-generierten Code prüfen, Testmanager, Architekten und DevOps-Engineers müssen plötzlich viel mehr Input bewerten. Der Schritt „Code schreiben“ ist um eine Größenordnung schneller geworden. Review, Test und Betrieb sind es nicht.
Das Ergebnis hätte Goldratt vorhergesagt: Unfertige Arbeit staut sich vor dem neuen Engpass. Das Tempo, das Teams beim Generieren von Code spüren, zeigt sich nicht in schnelleren Feature-Releases. Das gilt besonders für Unternehmen, denen wartbare, funktionierende Software weiterhin wichtig ist, und so sollte es auch sein.
Die Lösung: die ganze Kette harmonisieren, nicht nur einen Schritt
Einen Schritt noch schneller zu machen, löst das Problem nicht. Was hilft: jeden Schritt mit derselben agentischen Struktur zu unterstützen, sodass für jeden Schritt klare Erwartungen gelten, von der ersten Markthypothese bis zu den Release Notes. Wir nennen diese Struktur einen Agentic Engineering Harness.
Marktvalidierung. Agenten helfen Teams, Hypothesen zu prüfen, Belege zu sammeln und den Product-Market-Fit zu erreichen, bevor etwas übergeben wird. Das Ergebnis sind strukturierte Artefakte statt loser Ideen.
Produktmanagement. Das Produktmanagement macht aus diesen Artefakten aussagekräftige User Stories. Mit demselben Framework ist jede Story richtig zugeschnitten, testbar und erfüllt eine klare Definition of Ready (DoR), bevor die Entwicklung beginnt.
Entwicklung und Test. Test-Driven Development (TDD) wird direkt gegen die User Story geplant, zusammen mit den eigenen Governance-Regeln des Teams. Qualität entsteht an der Quelle, statt erst im Review gefunden zu werden.
Review und Betrieb. Reviewer fangen nicht mehr bei null an. Sie prüfen Arbeit, die bereits nach vereinbarten Kriterien entstanden ist. Es ist, als würde der Prüfer vom TÜV direkt neben dem Mechaniker arbeiten, statt am Ende der Linie zu warten.
Dokumentation und Go-to-Market. KI-gestützte Dokumentation entsteht als Teil der Arbeit. Produktmarketing und Support erhalten genaue Unterlagen im selben Tempo, in dem sich das Produkt ändert.
Sobald jeder Schritt im selben Takt arbeitet, kommt der Geschwindigkeitsgewinn durch KI-Programmierung endlich beim Kunden an.
Die ganze Geschichte in 18 Sekunden
Animation auf eigener Seite öffnen (18 Sekunden, ohne Ton)
Erste Schritte
Jeder Teil dieses Harness ist im Open-Source-Framework für Agentic Engineering von agenthouse verfügbar: wiederverwendbare Rollen, Skills und Produktprozesse von der Marktvalidierung über die Umsetzung bis zu Support und Lernen.