Es gibt eine Sache, die in der ganzen Diskussion um AI-Coding-Tools gern untergeht: Die CI/CD Pipeline war schon immer schneller als die Entwicklung. Code committen, Tests laufen lassen, deployen, das war nie der Teil, an dem es geklemmt hat. Geklemmt hat es davor, in der eigentlichen Implementierung. Genau da setzen die neuen Tools an. Und sie funktionieren. Entwicklung ist heute spürbar schneller als noch vor zwei Jahren.

Nur löst das nicht das Problem, das viele glauben damit zu lösen. Es verschiebt es.

Der Engpass verschwindet nicht, er wandert

Wer schon einmal versucht hat, einen Produktionsprozess zu optimieren, kennt das Prinzip: Eine Kette ist immer nur so schnell wie ihre langsamste Station. Beschleunigst du eine Station, die ohnehin nicht der Flaschenhals war, gewinnst du nichts. Du erzeugst nur mehr Stau vor der nächsten Engstelle.

Genau das passiert gerade. Die Entwicklung hat hinten aufgeholt, der Durchsatz an dieser einen Station ist gestiegen. Aber der Takt der gesamten Lieferkette wird woanders bestimmt. Und dieses Woanders sitzt fast immer weiter vorne.

Was bringt es dir, zehnmal schneller zu entwickeln und zu deployen, wenn der Vertrieb nicht zehnmal mehr Aufträge liefert? Wenn die Anforderungen, die reinkommen, widersprüchlich sind? Wenn Priorisierung nach Budgetzyklus läuft statt nach echtem Geschäftswert? Dann hast du eine sehr schnelle Maschine gebaut, die in einer langsamen Umgebung steht und Leerlauf produziert. To be fair: KI generierter Code mit guten Vorgaben festigt natürlich die Qualität.

Vorne wird es jetzt eng

Solange die Implementierung der limitierende Faktor war, fielen Schwächen weiter vorne kaum auf. Eine unklare Anforderung kostete zwei Wochen Entwicklung extra, und in zwei Wochen Entwicklung gingen sie unter. Diese Pufferzeit ist jetzt weg.

Wenn Code in Stunden statt Tagen entsteht, wird jede Lücke im Vorfeld plötzlich sichtbar. Fehlendes methodisches Produktmanagement. Kein technisches Systemverständnis auf der Fachseite. Keine Transparenz über Abhängigkeiten zwischen Teams und Plattformen. Wissen, das in einzelnen Köpfen steckt statt dokumentiert zu sein. All das war vorher schon da. Jetzt ist es nur nicht mehr von der langsamen Entwicklung kaschiert.

McKinsey schätzt, dass 30 bis 45 Prozent der Entwicklungsarbeit in Enterprise-Projekten reine Nacharbeit ist. Diese Zahl entsteht nicht in der Entwicklung. Sie entsteht davor, durch unklare Anforderungen und falsche Priorisierung. Wenn du jetzt nur die Entwicklung beschleunigst, beschleunigst du auch die Produktion dieser Nacharbeit.

Geschwindigkeit ohne Richtung skaliert nur den Schaden

Das ist der eigentlich unangenehme Teil. Ein schneller Prozess, der in die falsche Richtung läuft, ist schlimmer als ein langsamer. Du baust schneller am tatsächlichen Bedarf vorbei. Du erzeugst schneller technische Schulden. Du produzierst schneller digitale Produkte, deren Geschäftswert niemand kennt.

Die Tools versprechen mehr Tempo bei der Implementierung. Was sie nicht liefern, ist alles andere: klare Anforderungen, bessere Priorisierung, gesichertes Wissen, organisatorische Steuerung, weniger Komplexität. Wenn diese Grundlagen fehlen, erhöhst du vor allem die Geschwindigkeit, mit der bestehende Ineffizienzen skalieren.

Was tatsächlich hilft

Die Antwort ist unspektakulär, aber sie funktioniert. Du musst dort ansetzen, wo der Engpass jetzt sitzt.

Das heißt zuerst: Anforderungen ernst nehmen. Nicht als Ticket, das irgendwer schnell hinschreibt, sondern als Produkt-Entscheidung mit klaren Abnahmekriterien. Priorisierung nach Wirkung, nicht nach Budgettopf. Abhängigkeiten sichtbar machen, bevor sie im PI Planning eskalieren. Und Wissen aus den Köpfen holen, in dokumentierte Form bringen, damit es nicht an einzelnen Personen hängt.

Das klingt nach klassischem Produktmanagement, weil es genau das ist. Die KI hat dieses Handwerk nicht überflüssig gemacht. Sie hat es wichtiger gemacht. Je günstiger und schneller das Bauen wird, desto teurer wird es, das Falsche zu bauen.

Fazit

Die spannende Frage ist nicht mehr, wie schnell deine Teams entwickeln können. Diese Frage ist beantwortet. Die spannende Frage ist, ob der Rest der Organisation mit diesem Tempo überhaupt etwas anfangen kann.

Solange Vertrieb, Anforderungsklärung und Priorisierung nicht mithalten, baust du eine Hochleistungs-Entwicklung in eine Umgebung ein, die den zusätzlichen Durchsatz gar nicht aufnehmen kann. Du optimierst die schnellste Station einer Kette, deren Takt woanders entschieden wird.

Tempo ist gut. Aber Tempo ohne Richtung beschleunigt vor allem eines: den Weg in die Sackgasse.