Mehr Code, kaum mehr Produkt: Wo KI-Produktivität stecken bleibt

KI kann die sichtbarste Arbeit in der Softwareentwicklung spektakulär beschleunigen: Code schreiben. Doch Unternehmen verdienen nichts an Commits allein. Wert entsteht erst, wenn Änderungen geprüft, integriert, getestet, veröffentlicht und tatsächlich genutzt werden. Genau auf diesem Weg schrumpft der gemessene KI-Effekt erheblich.

Eine neue Studie mit mehr als 100.000 Entwicklerinnen und Entwicklern verfolgt erstmals mehrere Generationen von KI-Coding-Werkzeugen durch diese Produktionskette. Ihr Ergebnis ist weder „KI bringt nichts“ noch „KI macht Teams dreimal produktiver“. Es lautet: Der Gewinn ist real, aber er bleibt an den langsameren Gliedern der Organisation hängen.

Die kurze Antwort

KI beschleunigt das Schreiben von Code, aber Softwarewert entsteht erst nach Review, Integration, Test, Release und Nutzung. Weil diese komplementären Stufen nicht gleich schnell mitwachsen, übersetzt sich viel mehr Aktivität nur teilweise in fertige Produkte.

• Über mehrere KI-Werkzeuggenerationen hinweg stiegen Commits kumulativ um etwa 180 Prozent, Releases aber nur um ungefähr 30 Prozent.
• Bei synchronen Agenten stand mehr als siebenmal so viel Code nur rund 65 Prozent mehr Pull Requests und etwa 20 Prozent mehr Releases gegenüber.
• In vier App-Marktplätzen entstanden moderat mehr neue Anwendungen, ohne messbaren Zuwachs der Gesamtnutzung.
• Die Daten sprechen für reale Produktivitätsgewinne, aber gegen Codevolumen als ausreichendes Erfolgsmaß.

KI macht den ersten Teil der Kette schneller – produktiv wird sie erst, wenn der Rest der Organisation mithält.

Kernpunkte

• Über mehrere Werkzeuggenerationen hinweg stiegen Commits kumulativ um etwa 180 Prozent; bei Releases blieben davon rund 30 Prozent übrig.
• Mit synchronen Coding-Agenten wuchs die erzeugte Codemenge um mehr als das Siebenfache, Pull Requests aber nur um rund 65 Prozent und Releases um etwa 20 Prozent.
• In vier App-Marktplätzen kamen moderat mehr neue Anwendungen hinzu, die Gesamtnutzung stieg jedoch nicht messbar.
• Die Studie ist umfangreich und methodisch sorgfältig, aber beobachtend. GitHub-Aktivität, Releases und Marketplace-Nutzung sind keine vollständigen Maße für Qualität oder wirtschaftlichen Wert.
• Für Unternehmen folgt daraus: Nicht Codevolumen belohnen, sondern Durchlaufzeit, Qualität, Veröffentlichung und Kundennutzen messen – und Engpässe jenseits des Schreibens gezielt stärken.

Eine Produktivitätszahl hängt davon ab, wo man misst

Wer KI-Produktivität nur am Programmieren misst, blickt auf die schnellste Stelle der neuen Produktionslinie. Forschende um Mert Demirer, Leon Musolff und Liyuan Yang verknüpften für ihr NBER-Working-Paper „Writing Code vs. Shipping Code“ Nutzungsdaten verschiedener KI-Werkzeuggenerationen mit öffentlichen GitHub-Verläufen von mehr als 100.000 Entwicklern. Dazu verglichen sie frühe Nutzer mit möglichst ähnlichen Personen, die dasselbe Werkzeug erst ein Jahr später einführten.

Bei einfachen Autovervollständigungswerkzeugen stieg die Zahl der Commits demnach um ungefähr 40 Prozent. Synchrone Agenten, die größere Coding-Aufgaben im Dialog übernehmen, brachten kumulativ rund 140 Prozent. Asynchrone Agenten, die im Hintergrund selbstständiger arbeiten, hoben den Effekt über die Generationen hinweg auf etwa 180 Prozent. Das ist die Zahl, die leicht zur Schlagzeile wird.

Doch schon eine Stufe weiter wird das Bild nüchterner. Die Zahl aktiver Projekte nahm nur um etwa 50 Prozent zu, die der Releases um ungefähr 30 Prozent. Besonders anschaulich ist die Detailanalyse synchroner Agenten: mehr als siebenmal so viel erzeugter Code stand rund 65 Prozent mehr Pull Requests und ungefähr 20 Prozent mehr Releases gegenüber. Die von den Autoren veröffentlichte CEPR-Einordnung fasst das als „Weak-Link“-Problem zusammen: Das langsamste komplementäre Glied begrenzt den Gesamtertrag.

Wo der KI-Gewinn entlang der Kette schrumpft

1. Code

   Agenten erzeugen Vorschläge, Funktionen und Änderungen sehr schnell; hier ist der gemessene Mengeneffekt am größten.

2. Commit und Pull Request

   Änderungen werden strukturiert, erklärt und zur Prüfung vorgelegt; nicht jeder erzeugte Code erreicht diese Stufe.

3. Review und Test

   Menschen und Prüfsysteme bewerten Architektur, Sicherheit, Wartbarkeit und Fehlerfolgen; die Kapazität wächst nicht automatisch mit.

4. Release

   Nur integrierte, ausreichend belastbare Änderungen werden veröffentlicht; der beobachtete Effekt ist hier viel kleiner.

5. Nutzung

   Erst Nachfrage und tatsächlicher Gebrauch machen aus zusätzlichem Angebot einen wirtschaftlichen oder gesellschaftlichen Wert.

Der Engpass wandert hinter den Editor

Das Schreiben war nie die gesamte Softwareproduktion. Ein Pull Request muss verständlich genug sein, damit jemand ihn verantwortungsvoll prüfen kann. Neue Funktionen müssen zur Architektur passen, automatische und manuelle Tests bestehen, Sicherheitsanforderungen erfüllen, dokumentiert und ausgerollt werden. Danach beginnt erst die härteste wirtschaftliche Prüfung: Löst das Produkt ein Problem, für das Menschen oder Unternehmen Zeit und Geld aufbringen?

Wenn KI das Schreiben stark verbilligt, werden diese nachgelagerten Schritte nicht automatisch schneller. Im Gegenteil: Mehr vorgeschlagener Code kann mehr Review-Arbeit, mehr Integrationskonflikte und mehr Testbedarf erzeugen. Ein Team kann deshalb enorm beschäftigt aussehen, ohne im gleichen Verhältnis mehr belastbare Software zu liefern.

Das ist kein Argument gegen Coding-Agenten. Es erklärt vielmehr, warum lokale Beschleunigung und Unternehmensproduktivität zwei verschiedene Größen sind. Ähnlich wie eine schnellere Maschine in einer Fabrik wenig bringt, wenn Qualitätsprüfung und Versand unverändert bleiben, muss auch die digitale Produktionslinie als Ganzes betrachtet werden.

Die Studie findet tatsächlich zusätzliche Endprodukte: Releases nehmen zu, nur eben deutlich weniger als die vorgelagerte Aktivität. In vier App-Marktplätzen steigt die Zahl neu veröffentlichter Apps moderat. Für die Gesamtnutzung dieser Apps zeigt sich dagegen kein Zuwachs. Mehr Angebot ist also noch kein Beleg für mehr Nachfrage oder Nutzen.

Wie belastbar sind diese Zahlen?

Die Untersuchung ist ungewöhnlich groß und nutzt mehrere Einführungsschritte als natürliche Zeitpunkte. Die Forschenden gleichen frühe Nutzer mit späteren Nutzern ab, prüfen Trends vor der Einführung und führen Placebotests durch. Das stärkt die Interpretation, dass die Sprünge mit den Werkzeugen zusammenhängen.

Trotzdem handelt es sich nicht um ein randomisiertes Experiment über die gesamte Kette. Wer früh neue Coding-Agenten nutzt, kann sich in schwer messbaren Eigenschaften von anderen Entwicklern unterscheiden. Öffentliche GitHub-Spuren bilden proprietäre Unternehmenssoftware nur teilweise ab. Ein Release kann winzig oder sehr wertvoll sein; die bloße Zahl misst weder Fehlerfreiheit noch Umsatz. Und eine ausbleibende Gesamtnutzungssteigerung in App-Marktplätzen kann auch bedeuten, dass sich Aufmerksamkeit auf mehr Angebote verteilt oder wirtschaftliche Effekte zeitversetzt eintreten.

Hinzu kommt ein Interessenkonflikt, der Transparenz verlangt: Zwei Autoren waren zuvor als Postdocs bei Microsoft tätig und arbeiten laut Offenlegung als bezahlte Berater für das Unternehmen; ein Teil der Daten stammt aus proprietärer Microsoft-Telemetrie. Das macht die Resultate nicht falsch, erhöht aber die Bedeutung unabhängiger Replikation.

Drei Messstufen, drei Aussagegrenzen

• Mehr als 100.000 Entwickler

  Eine Matched-Event-Studie findet starke Zuwächse bei Commits, deutlich kleinere bei Projekten und Releases.

  Aussagekraft

  Großer Datensatz, mehrere Werkzeuggenerationen, zeitlich versetzte Vergleichsgruppen und Placebotests.

  Grenze

  Beobachtend statt vollständig randomisiert; öffentliche GitHub-Spuren und Microsoft-Telemetrie bilden nicht jede Softwarearbeit ab.

• Mehr als 12.000 europäische Firmen

  KI-Einführung hängt kurzfristig mit rund vier Prozent höherer Arbeitsproduktivität zusammen, vor allem bei mittleren und großen Firmen.

  Aussagekraft

  Breite Länderbasis und Berücksichtigung unterschiedlicher KI-Exposition; komplementäre Investitionen werden sichtbar.

  Grenze

  Kurzer Beobachtungszeitraum und Firmenauswahl erlauben keine einfache Hochrechnung auf alle Branchen oder Volkswirtschaften.

• Releases und Marktplatznutzung

  Mehr Coding-Aktivität führt zu mehr Releases und etwas mehr neuen Apps, aber nicht zu höherer Gesamtnutzung.

  Aussagekraft

  Die Messung rückt näher an veröffentlichte Produkte und Nachfrage als reine Codekennzahlen.

  Grenze

  Anzahl und Nutzung erfassen Qualität, Umsatz, Langzeitnutzen und zeitverzögerte Effekte nur unvollständig.

Andere Firmendaten zeigen Gewinne – und dieselbe Vorsicht

Die große Linie passt zu weiteren aktuellen Befunden. Ein BIS-Working-Paper zu mehr als 12.000 Unternehmen in 27 europäischen Ländern verbindet KI-Einführung im kurzen Zeitraum mit rund vier Prozent höherer Arbeitsproduktivität. Der Gewinn konzentriert sich jedoch auf mittlere und große Firmen und hängt mit ergänzenden Investitionen in Software, Daten und Weiterbildung zusammen. Einen kurzfristigen Beschäftigungsrückgang findet die Studie nicht.

Auch der OECD-Produktivitätsbericht 2026 warnt vor einer simplen Hochrechnung einzelner Aufgabenexperimente auf ganze Volkswirtschaften. Bislang seien die Effekte in einigen Firmen sichtbar, aber noch nicht breit über Branchen verteilt. Zudem erschweren immaterielle Investitionen, Cloud-Leistungen und Qualitätsänderungen die Messung.

Eine Befragung von rund 750 Finanzchefs durch die Federal Reserve Bank of Richmond zeigt die Wahrnehmungslücke aus Unternehmenssicht. Die Befragten schätzten den Produktivitätsbeitrag ihrer KI-Nutzung im Mittel auf etwa drei Prozentpunkte. Aus dem von ihnen genannten Umsatz je Beschäftigten ließ sich jedoch nur ungefähr die Hälfte ableiten. Eine mögliche Erklärung ist Zeitverzug; eine andere sind optimistische Selbsteinschätzungen.

Im Euroraum zeigt sich zudem ein Unterschied zwischen Ausprobieren und tiefem Einsatz. Laut einer ECB-Auswertung von mehr als 5.000 Unternehmen verwendeten über 70 Prozent bereits irgendeine Form von KI, aber nur sieben Prozent intensiv. Verbreitung allein sagt deshalb wenig darüber aus, ob Prozesse, Rollen und Investitionen bereits zum Werkzeug passen.

Was Unternehmen jetzt anders messen sollten

Wer eine Code-KI einführt, braucht ein Messsystem, das nicht an der bequemsten Zahl endet. Mehr Codezeilen, Commits oder erledigte Tickets können frühe Signale sein. Als Erfolgsmaß taugen sie nur, wenn sie mit nachgelagerten Ergebnissen verbunden werden: Wie lange braucht eine Änderung bis zur Produktion? Wie oft muss sie nachgebessert werden? Bleiben Sicherheits- und Qualitätsziele stabil? Werden Funktionen genutzt? Lösen sie ein Kundenproblem?

Die organisatorische Antwort besteht daher nicht bloß aus besseren Modellen. Review-Kapazität, automatische Tests, klare Produktentscheidungen, dokumentierte Schnittstellen und ein sicherer Release-Prozess werden wertvoller, wenn die Zufuhr an Code wächst. Wo diese Bereiche knapp bleiben, verwandelt KI den alten Schreibengpass in einen Prüf- und Integrationsengpass.

Welche Kennzahl passt zu welchem Ziel?

• Wenn: du prüfen willst, ob ein Werkzeug den Schreibschritt beschleunigt

  Dann: beobachte Bearbeitungszeit, Vorschlagsannahme und Commit-Durchsatz

  Diese Maße zeigen lokale Effizienz, beweisen aber noch keinen fertigen Produktwert.

• Wenn: du die Leistung eines Entwicklungsteams bewerten willst

  Dann: miss Durchlaufzeit bis zur Produktion, Fehlerrate, Nacharbeit und Zuverlässigkeit gemeinsam

  Geschwindigkeit ohne Qualitäts- und Stabilitätsgrenze kann lediglich Arbeit nach hinten verschieben.

• Wenn: du den wirtschaftlichen KI-Ertrag bewerten willst

  Dann: verknüpfe Releases mit Nutzung, Kundenproblem, Umsatz oder eingespartem Aufwand

  Erst nachgelagerte Ergebnisse zeigen, ob zusätzliche Software tatsächlich Wert schafft.

• Wenn: Code schneller wächst als geprüfte Releases

  Dann: investiere in Review, Tests, Integration, Produktentscheidung und Weiterbildung

  Der neue Engpass liegt dann nicht im Modell, sondern in den komplementären Stufen der Organisation.

Das verändert auch die Personalfrage. Wenn Unternehmen nur auf eingesparte Programmierzeit schauen, unterschätzen sie die komplementäre Arbeit. Fachleute müssen Ziele formulieren, Vorschläge bewerten, Fehlerfolgen verstehen und Verantwortung für das Ergebnis tragen. Die passenden Fähigkeiten verschwinden nicht; ihr Schwerpunkt verschiebt sich.

Für Teams, die mit mehreren autonomen Werkzeugen experimentieren, wird Koordination noch wichtiger. Unser Beitrag über Multi-Agenten-Systeme in der Softwareentwicklung zeigt, warum Arbeitsteilung ohne Konfliktlösung schnell neue Reibung erzeugt. Und die automatische KI-Fehlerbehebung erinnert daran, dass eine plausible Reparatur erst durch Tests und menschliche Kontrolle belastbar wird.

Mehr Output ist ein Versprechen, kein Endergebnis

Die neue Studie liefert ein wichtiges Korrektiv für die Debatte. KI-Coding ist nicht bloß Theater: Selbst am Ende der Kette bleiben messbar mehr Projekte und Releases. Aber die größten Zahlen liegen dort, wo Aktivität am einfachsten zu erzeugen ist. Je näher die Messung an Qualität, Veröffentlichung und Nutzung rückt, desto kleiner wird der Effekt.

Deshalb sollten Unternehmen weder auf die größte Prozentzahl starren noch Coding-Agenten vorschnell abschreiben. Die bessere Frage lautet: Welches Glied unserer Produktionskette ist jetzt das langsamste – und investieren wir dort ebenso entschlossen wie in die KI am Anfang? Erst wenn aus zusätzlichem Code verlässlich genutzte Produkte werden, ist aus technischer Beschleunigung wirtschaftliche Produktivität geworden.