Mehr Code, gleiche Lieferzeit? So steuern CTOs KI-Produktivität

KI kann Implementierung beschleunigen. Ob daraus schneller nutzbare Software wird, entscheidet der gesamte Lieferprozess. Ein Mess- und Entscheidungsrahmen für CTOs, CIOs und CFOs.

Mehr Code, gleiche Lieferzeit? So steuern CTOs KI-Produktivität

Das Team erzeugt mehr Code. Die Zahl der Änderungsvorschläge steigt. Trotzdem wartet der Vertrieb auf die neue Angebotsfunktion, und der nächste Release verschiebt sich. In dieser Situation beantwortet die Nutzungsstatistik des KI-Werkzeugs die falsche Frage. Für das Management zählt, ob ein vereinbartes Ergebnis früher und zuverlässig im Betrieb ankommt.

Wer KI in der Softwareentwicklung ausweitet, sollte deshalb die Investition am gesamten Lieferprozess prüfen: vom geklärten Auftrag über Implementierung und Review bis zur produktiven Nutzung. Die zentrale Führungsaufgabe besteht darin, den Engpass zu erkennen, der nach der Beschleunigung übrig bleibt.

:::takeaways{title="Für Ihre Entscheidung"}

:::

Die Forschung liefert keine pauschale Produktivitätsquote

Eine DORA-Auswertung von 1’110 offenen Antworten aus einer Befragung von Google-Entwicklern im dritten Quartal 2025 beschreibt einen relevanten Zielkonflikt: Schnellere Erstellung kann mit zusätzlichem Prüfaufwand einhergehen. DORA berichtet ausserdem einen Zusammenhang höherer KI-Nutzung sowohl mit höherem Lieferdurchsatz als auch mit höherer Instabilität. Das sind keine allgemeingültigen Kausalnachweise für ein bestimmtes Team. DORA, März 2026

Auch alte Einzelwerte sollte niemand zur Budgetregel machen. METR fand für erfahrene Open-Source-Entwickler mit Werkzeugen von Anfang 2025 längere Bearbeitungszeiten. Im Update vom Februar 2026 erläutert METR jedoch erhebliche Auswahl- und Messprobleme der Folgestudie und hält deren Daten für ein unzuverlässiges Signal der aktuellen Wirkung. Daraus lässt sich keine belastbare Quote für heutige Unternehmensprojekte ableiten. METR, Februar 2026

Die praktische Konsequenz: externe Forschung als Hinweis auf mögliche Effekte nutzen und den eigenen Ablauf messen. Ein Benchmark ersetzt weder vergleichbare Aufgaben noch die Prüfung, ob eine Funktion den geschäftlichen Zweck erfüllt.

Der Engpass kann nach dem Coding liegen

Bei Deep Impact beschäftigen wir uns öffentlich mit der Industrialisierung der Softwareentwicklung durch KI. Dieser Beitrag ergänzt die Perspektive um eine konkrete Steuerungsfrage: Wie wird aus höherem Umsetzungstempo eine kürzere Lieferzeit?

Stellen Sie sich ein Team vor, das eine Änderung in vier Tagen implementiert. Danach wartet sie drei Tage auf das Review; Prüfung und Korrekturen benötigen zwei weitere Tage. Bis zum vorgesehenen Release vergeht ein weiterer Tag.

:::callout{type="info"} Das folgende Beispiel ist hypothetisch. Die Phasen liegen vollständig nacheinander und sind als verstrichene Arbeitstage definiert. Es handelt sich weder um erfasste Arbeitsstunden noch um ein Deep-Impact-Kundenergebnis. :::

| Phase | Bisher | Mit KI – Annahme | |---|---:|---:| | Implementierung | 4 Tage | 2 Tage | | Warten auf Review | 3 Tage | 3 Tage | | Prüfung und Korrektur | 2 Tage | 2 Tage | | Warten auf Release | 1 Tag | 1 Tag | | Gesamte Lieferzeit | 10 Tage | 8 Tage |

Die Implementierung halbiert sich, die Lieferzeit sinkt um 20 Prozent. Wächst die Review-Wartezeit gleichzeitig von drei auf fünf Tage, bleibt die Gesamtdauer bei zehn Tagen. Die Rechnung zeigt einen möglichen Zusammenhang; sie prognostiziert keine Wirkung in Ihrem Unternehmen.

Kalenderzeit und Arbeitsaufwand gehören dabei in getrennte Spalten. Drei Tage in einer Warteschlange sind nicht drei Personentage. Für die Kostenbewertung braucht es zusätzlich die tatsächlich eingesetzte Zeit aller Beteiligten.

Ein kleiner Messrahmen reicht für den Einstieg

Beginnen Sie mit einer wiederkehrenden Aufgabenklasse, beispielsweise überschaubaren Erweiterungen einer bestehenden Anwendung. Neue Produktentwicklung, Fehlerbehebung und schwierige Datenmigrationen getrennt betrachten: Ein veränderter Aufgabenmix kann einen scheinbaren Produktivitätsgewinn erklären.

Legen Sie vorab fest, wann die Messung startet und endet. Ein sinnvoller Rahmen für diesen Versuch beginnt mit einem ausreichend geklärten Auftrag und endet mit einer produktiv verfügbaren, fachlich akzeptierten Änderung. Änderungen des Umfangs werden dokumentiert.

Erheben Sie dazu fünf Grössen:

Ein Median allein kann schwierige Fälle verdecken. Zeigen Sie deshalb zusätzlich die Streuung und einzelne besonders lange Fälle. Vergleichen Sie ausreichende Mengen ähnlicher Aufgaben; eine universell richtige Fallzahl gibt es dafür nicht. Halten Sie Wechsel von Werkzeugen, Teamzusammensetzung und Anforderungen fest.

Die Review-Warteschlange ist ein Führungsproblem

Wenn Review zum Engpass wird, hilft die Aufforderung «prüft schneller» wenig. Zuständigkeit, verfügbare Zeit und Grösse der Änderungen müssen zusammenpassen. Eine KI kann umfangreiche Änderungen in kurzer Zeit erzeugen; jemand muss deren Auswirkungen trotzdem verstehen.

Als erster Versuch bietet sich eine begrenzte Änderung mit einem klaren fachlichen Zweck an. Der Vorschlag enthält eine kurze Begründung, die betroffenen Abläufe und die Ergebnisse relevanter Prüfungen. Eine Zahlungsregel und ein visueller Umbau gehören beispielsweise nicht allein deshalb zusammen, weil das Werkzeug beides gleichzeitig erledigen kann.

Automatisierte Prüfungen sollten vor der Übergabe laufen. Sie helfen, bekannte Fehlerklassen früh zu erkennen. Fachliche Abnahme, nachvollziehbare Architekturentscheidungen und Verantwortung für den Betrieb bleiben Teil des Ablaufs. Prüfen Sie auch, ob Tests das gewünschte Verhalten abdecken oder lediglich den erzeugten Code bestätigen.

Für dringende Änderungen kann eine gemeinsame Prüfung sinnvoll sein. Für andere Arbeiten sind feste Review-Zeiten und begrenzte parallele Vorgänge ein Versuch wert. Welche Variante wirkt, zeigt die gemessene Wartezeit bei gleicher Qualitätsanforderung.

Wofür das nächste Budget freigegeben wird

Nach dem Versuch stehen drei unterschiedliche Entscheidungen an. Sinkt der gesamte Aufwand bei stabiler Qualität, kann eine Ausweitung auf vergleichbare Aufgaben sinnvoll sein. Wird nur die Implementierung schneller, während Arbeit vor der Abnahme liegen bleibt, braucht der Folgeversuch einen anderen Schwerpunkt. Verschlechtert sich die Betriebsqualität, gehört zunächst die Fehlerursache geklärt.

Auf die Kostenseite gehören Lizenzen, Modellnutzung, Integration, Schulung und Betreuung. Fachliche Prüfung und Nacharbeit werden im menschlichen Aufwand erfasst. Rechnen Sie dieselbe Tätigkeit nicht zusätzlich als separate Betriebskosten nochmals an.

Eine frühere Lieferung kann wirtschaftlich wertvoll sein, etwa wenn eine benötigte Funktion rechtzeitig zu einem Kundenstart verfügbar wird. Dieser Wert braucht eine nachvollziehbare Verbindung zum Geschäft. Zusätzliche Codezeilen oder akzeptierte Vorschläge sind dafür kein Ersatz.

:::highlight Die nächste Investition sollte den nachgewiesenen Engpass bearbeiten. Eine zusätzliche KI-Lizenz ist eine mögliche Massnahme; bessere Abnahmekriterien oder schnellere Prüfungen können ebenso entscheidend sein. :::

Benennen Sie für den Versuch eine verantwortliche Person aus der Entwicklung und eine aus dem Fachbereich. Beide vereinbaren vor dem Start, welches Ergebnis eine Ausweitung rechtfertigt. So wird aus einer Werkzeugdiskussion eine überprüfbare Entscheidung über Lieferfähigkeit.

Sie möchten herausfinden, wo KI Ihren Lieferprozess verbessert? Wir prüfen mit Ihnen einen konkreten Softwareablauf.

Quellen und Einordnung

Recherche: 12. Oktober 2026. Die Forschungsbefunde oben sind zeitlich eingeordnet; das Phasenmodell und der Messrahmen sind unsere redaktionelle Ableitung. Die Beispielrechnung enthält keine Kundendaten. Ergänzend: Softwareentwicklung bei Deep Impact und Kapazität und finanzielle Wirkung sauber unterscheiden.