KI-⁠Wirkung im Engineering messen: was zählt und was ihr ignorieren könnt

KI treibt jede Zahl nach oben, die leicht zu zählen ist. Codemenge, Pull Requests, erledigte Tasks und Tool-Nutzung steigen, ob beim Kunden mehr ankommt oder nicht. Die Studien, die Ergebnisse gemessen haben, beziffern den typischen Gewinn auf etwa 10 Prozent, mit großen Unterschieden zwischen Unternehmen, die dieselben Tools nutzen.

Messt deshalb die Delivery statt der Aktivität: was in Produktion ankommt, wie lange es dauert, was kaputtgeht und was nachgebessert werden musste. Messt eure eigene Baseline, bevor ihr das Playbook eines anderen übernehmt. Und rechnet mit einer Delle vor den Gewinnen: Nach unserer Erfahrung bindet KI zuerst mehr Kapazität, als sie freisetzt.

Die Abschnitte unten beantworten die Fragen in der Reihenfolge, in der Engineering-Führungskräfte sie meist stellen.

Warum führen die üblichen Kennzahlen in die Irre?

Weil KI genau das aufbläht, was leicht zu messen ist:

• Die Codemenge steigt, weil Code zu erzeugen billig ist.
• Die Zahl der PRs steigt, weil kleinere, schnellere Änderungen sich produktiv anfühlen.
• Die Zahl erledigter Tasks steigt, weil die leichten Tasks zuerst drankommen.
• Die Velocity in Story Points steigt, weil Punkte Aufwand messen, keine Wirkung.

Die Dashboards zeigen nach oben, und die Geschäftsleitung feiert. Ungemessen bleibt der Teil, der über den Wert entscheidet: Features, die Kunden wirklich nutzen, Code, der sechs Monate ohne Neuschreiben übersteht, die Zeit für das Korrigieren von KI-Output gegen die Zeit, die KI “gespart” hat, technische Schulden pro Feature und die KI-Nacharbeitsquote bei generiertem Code.

Ein Rechenbeispiel, keine Messung, macht die Lücke sichtbar. Ein Team liefert dreimal so viel Code, und seine Nutzer:innen sehen 1,1-mal so viele nützliche Features. Die fehlenden 1,9 sind in Code geflossen, der sofort repariert werden musste, in Features, die niemand bestellt hat, und in Komplexität, die alles andere bremst. KI steigert die Produktivität und ist beim Wert neutral.

Nutzungszahlen haben dasselbe Problem. Viele Unternehmen verfolgen täglich aktive Nutzer:innen, Akzeptanzraten und Sitzungsdauer. Hohe Nutzung und negative Wirkung schließen sich nicht aus: 100 Prozent Adoption eines Tools, das alle langsamer macht, ist möglich.

Auch die Zahl der PRs sieht gut aus und sagt wenig. In der Telemetrie von Faros mit mehr als 10.000 Entwickler:innen mergen Teams mit hoher KI-Nutzung 98 Prozent mehr Pull Requests, und die Review-Zeit steigt um 91 Prozent. Die meisten dieser Entwickler:innen nutzten Autovervollständigung, keine Agenten, und die Daten sind korrelativ. Mehr gemergte PRs bedeuten nicht mehr gelieferten Wert.

Was sagen die gemessenen Zahlen?

Sie sind bescheiden und liegen weit weg von den 10x aus den Vorstandsfolien.

Die Produktivitätsforschung von Stanford umfasst mehr als 120.000 Entwickler:innen. In einem Vortrag darüber verglich Yegor Denisov-Blanch 46 Teams, die KI nutzten, mit 46 ähnlichen Teams ohne KI. Für diese Gruppe lag der mediane Produktivitätsgewinn im Juli 2025 bei etwa 10 Prozent. Die DX-Daten zu 121.000 Entwickler:innen aus 450 Unternehmen, die Laura Tacho vorgestellt hat, kommen ebenfalls auf etwa 10 Prozent.

Gefühlte und gemessene Geschwindigkeit liegen weit auseinander. In METRs randomisierter kontrollierter Studie waren 16 erfahrene Open-Source-Entwickler:innen mit KI-Tools von Anfang 2025 um 19 Prozent langsamer und hielten sich für 20 Prozent schneller. Die Stichprobe ist klein, und METR kennzeichnet das Ergebnis inzwischen als veraltet. Es geht aber um den Abstand zwischen Gefühl und Messung: Der Vorstand sieht nur die gefühlte Zahl. In PwCs CEO-Umfrage 2026 sagen 56 Prozent der CEOs, dass sie bisher keinen nennenswerten finanziellen Nutzen aus KI gesehen haben. Der Bericht von MIT NANDA sagt, 95 Prozent der Organisationen erzielten gar keinen Ertrag. Kevin Werbach bestreitet diese Zahl (öffnet in einem neuen Tab), weil der Bericht nicht zeigt, woher sie kommt.

Wer den Output nach der Einführung misst, kommt auf größere Zahlen. Eine Studie mit 300 Engineers in einem Unternehmen (öffnet in einem neuen Tab), die einen KI-Coding-Assistenten nutzten, maß 31,8 Prozent kürzere Review-Zyklen für PRs, 60,1 Prozent mehr ausgelieferten Code und etwa 20 Minuten Ersparnis pro Entwickler:in und Tag. In denselben Faros-Daten bearbeiten Entwickler:innen in der Gruppe mit hoher Nutzung 47 Prozent mehr Pull Requests pro Tag.

Das sind PR-basierte Kennzahlen: Output, kein Ergebnis. Wir gehen davon aus, dass mit der Zeit bessere Zahlen kommen. Bis dahin ist die beste Zahl, die der Kunde hat, mehr wert als das Warten auf die perfekte Messung.

Was sollten wir stattdessen messen?

Messt in drei Dimensionen, wie es das AI Measurement Framework von DX tut, und lasst jede eine Frage beantworten:

• Nutzung: Wird es verwendet? Täglich aktive Nutzer:innen, Akzeptanzraten, wie tief jedes Team die Funktionen nutzt. Das messen die meisten Unternehmen. Es ist nötig und reicht nicht.
• Wirkung: Wird die Delivery besser? Produktivität pro Team, Qualität des Produktionscodes, Zeit bis zur Auslieferung, Zufriedenheit und Zuversicht der Entwickler:innen. Das ist schwerer zu messen und der Teil, der zählt.
• Kosten: Was braucht es? Token-Verbrauch und Inferenzkosten, Lizenzkosten pro Nutzer:in, Infrastruktur und die Investition in Context Engineering. Die Kosten entscheiden über den ROI und fallen oft erst bei der Budgetprüfung auf.

Für die Dimension Wirkung zeigen diese Kennzahlen, was in Produktion ankommt, statt was zwischen Menschen hin- und hergeht:

1. Deployment-Frequenz: Code, der in Produktion ankommt, nicht gemergte PRs.
2. Durchlaufzeit von der Idee bis zu den ersten Nutzer:innen: DORA misst die Durchlaufzeit vom Commit bis zur Produktion. Wir starten die Uhr, wenn die Idee erfasst ist, und stoppen sie, wenn die ersten Nutzer:innen die Änderung nutzen können. So zählt die Wartezeit vor dem ersten Commit, und ein Feature hinter einem geschlossenen Flag ist noch nicht angekommen.
3. Change Failure Rate nach der KI-Einführung.
4. Rework Rate: der Anteil der Änderungen, die nach Review oder Abnahme neu gemacht werden, bevor sie bei den Nutzer:innen ankommen, eine Kennzahl von uns. Sie zeigt, ob Exploration und Spezifikation getragen haben. Sie ist nicht DORAs Deployment Rework Rate, die ungeplante Deployments infolge von Incidents in Produktion zählt.
5. Bestehensquote im ersten Anlauf: wie oft Output die Quality Gates beim ersten Versuch besteht.
6. Nutzung: der Anteil der Zielnutzer:innen, die ein Feature nach 30 Tagen aktiv nutzen, statt der Zahl ausgelieferter Features.
7. Wartbarkeit und Verlauf der Komplexität: Versteht jemand anderes diesen Code in sechs Monaten, und wird die Codebasis einfacher oder schwerer zu ändern? Wenn jeder Sprint Komplexität hinzufügt, ist die Velocity eine Illusion.
8. Zufriedenheit und Zuversicht der Entwickler:innen.

Je reifer eine Software Factory wird, desto mehr ersetzen automatische Quality Gates manuelle Reviews. Übrig bleiben die Kennzahlen, die messen, was in Produktion ankommt und was dort kaputtgeht.

Warum unterscheiden sich die Ergebnisse so stark zwischen Unternehmen?

Der DORA-Bericht 2025 beschreibt KI als Verstärker der vorhandenen Stärken und Schwächen einer Organisation. So gelesen können dieselben Tools und Modelle ein Unternehmen viel schneller machen und ein anderes langsamer, und der Durchschnitt verdeckt beides. Die Streuung ist das eigentliche Signal. Selbst ein gut dokumentierter Fall lässt sich schlecht übertragen. Spotify berichtet, dass KI-geschriebener Code bei den bisher ausgewerteten Incidents keine wesentliche direkte Ursache war. Das Änderungsvolumen wuchs aber schneller, als sich manche Prüfmechanismen anpassen konnten. Das beschreibt Spotifys Delivery-System, eures hat andere Schwachstellen.

Die Ergebnisse gehen aus diesen Gründen auseinander:

• “Einfach anschalten” stiftet Verwirrung. Entwickler:innen nutzen KI unterschiedlich, die Codequalität schwankt stark, und Sicherheitslücken tauchen zufällig auf.
• Kultur wiegt schwerer als Tools. In Organisationen, die KI-gestützte “Fehler” bestrafen, verstecken Entwickler:innen ihre Nutzung ganz.
• Ohne gemeinsamen Kontext keine gemeinsamen Ergebnisse. Ohne strukturierte Konventionen und Dokumentation fängt jede:r Entwickler:in bei null an.
• Ein kopiertes Playbook übergeht eure Engpässe, eure Codebasis und die Dynamik in euren Teams.

Im Stanford-Vortrag sagte die Sauberkeit der Codebasis den Gewinn besser voraus als der Token-Verbrauch: ein R-Quadrat von 0,40 für die Sauberkeit, gegenüber einem Korrelationskoeffizienten r von etwa 0,2 für Tokens. Das sind zwei verschiedene Kennzahlen: Quadriert wird aus 0,2 ein Wert von 0,04, ein Zehntel der 0,40. Teams um 10 Millionen Tokens pro Engineer und Monat schnitten schlechter ab als Teams, die etwas weniger verbrauchten. Der Vortragende nannte diese Delle ausdrücklich eine Tendenz. Unsere Lesart: Dem Agenten geht der verlässliche Kontext aus, und er erzeugt plausiblen Code, der an Konventionen scheitert, die in der Codebasis nie aufgeschrieben wurden.

Eine saubere Codebasis zeigt dem Agenten, woran er guten Code erkennt, was er nie tun darf und was vor dem Ausliefern geprüft wird. Tests fangen, was Reviewer:innen nicht fangen können, Namensmuster lassen sich ohne Anleitung nachahmen, Architekturgrenzen melden Verstöße laut, und Linting und Fitness Functions blockieren schlechten Output, bevor er gemergt wird. Wer Tokens kauft, bevor die strukturellen Schulden abgebaut sind, macht die Kurve schlechter. Die Teams, deren Gewinne sich aufbauen, behandeln den Zustand der Codebasis als das Betriebsbudget ihrer KI.

Die andere Hälfte ist Enablement. Laut Tacho garantiert Adoption allein keine Ergebnisse, in ihren Worten: “This is really a management problem.” Enablement heißt für uns: die Prozesse rund um die Arbeit, die Review-Warteschlangen und der Spielraum, den Teams haben, um ihre Arbeitsweise bei der Auslieferung zu ändern. So wirkt DORAs Verstärker: Wer einen langsamen Review-Prozess mit KI ausstattet, bekommt schnelleren Code, der sich vor einer langsamen Review-Warteschlange stapelt. Die Studie mit 300 Engineers fand dasselbe Muster von der anderen Seite: Die Gewinne folgten der Nutzungsintensität, und wer wenig nutzte, sah kaum oder sogar negative Wirkung.

KI-Adoption ist ein Veränderungsvorhaben, wie Agile vor 20 Jahren: derselbe Widerstand, dieselbe Dynamik in der Organisation, derselbe Bedarf an strukturiertem Enablement.

Woher kommen die Erträge?

Aus Wartungsarbeit, nicht aus den Demos. DX Research ließ Entwickler:innen zehn Aufgaben nach der KI-Zeitersparnis ordnen, die sie wahrnehmen. Oben, mit klarem Abstand: Stacktrace-Analyse, Refactoring bestehenden Codes, Codegenerierung im laufenden Arbeitsfluss und das Erzeugen von Testfällen. Alle vier sind musterlastig und kontextreich. Unten: Code erklären, erstes Code-Scaffolding, Brainstorming und Planung. Code erklären steht ganz unten, das erste Scaffolding knapp darüber, und ausgerechnet diese beiden zeigen die meisten KI-Demos. Dort beginnen auch die meisten Rollouts. Aus unserer Erfahrung, nicht aus den DX-Daten: Teams, die KI für Greenfield-Entwicklung einführen, stagnieren nach wenigen Wochen. Teams, die sie für Brownfield-Arbeit einführen, für Debugging, Refactoring und Testgenerierung, finden auch nach sechs Monaten noch neuen Nutzen.

Aus dem Verstehen von Code. Nach unserer Lesart ist das etwas anderes als “Code erklären” unten auf der DX-Liste: Einen Assistenten eine Funktion erklären zu lassen ist etwas anderes, als ein Tool ein ganzes Altsystem lesen und dessen Spezifikation schreiben zu lassen. Morgan Stanley gibt an, dass sein hauseigenes Tool DevGen.AI Entwickler:innen bis Juni 2025 mehr als 280.000 Stunden gespart hat. Es übersetzt Code in alten Sprachen in Spezifikationen in einfachem Englisch, die sich danach neu schreiben lassen. In einem solchen Altsystem geht die Zeit ins Lesen, Verstehen und Zurückentwickeln dessen, was schon da ist, nicht ins Schreiben von Code.

Aus Automatisierung und weniger Risiko statt aus Zeitersparnis. Daten aus mehr als 2.500 selbst berichteten Anwendungsfällen (öffnet in einem neuen Tab) zeigen Zeitersparnis als Standardziel: 35 Prozent der Anwendungsfälle zielen darauf, und die Teams liegen zwischen 1 und 10 gesparten Stunden pro Woche, die meisten bei etwa 5. Der Ertrag ist bescheiden. Risikoreduktion macht nur 3,4 Prozent der Anwendungsfälle aus, aber 25 Prozent davon berichten einen transformativen ROI. Wo agentische Automatisierung genannt wird, schneidet sie besser ab als die anderen Kategorien. Bei Führungskräften melden 17 Prozent der Anwendungsfälle transformative Wirkung, mehr als bei Fachkräften ohne Führungsverantwortung, weil sie strategische Anwendungsfälle mit hohem Einsatz wählen. Und Breite zahlt sich aus: Je mehr Anwendungsfälle eine Organisation eingereicht hat, desto besser war ihr ROI über alle hinweg. Anwendungsfälle rund ums Coding zeigen einen höheren ROI und weniger negative Wirkung als der Durchschnitt.

Junior-Engineers gewinnen am meisten. In derselben Studie mit 300 Engineers, einem Preprint der Entwickler:innen des Tools, steigerten Junior-Engineers ihre Produktivität um 77 Prozent, Engineers auf mittlerer Stufe um 45 Prozent und Senior-Engineers um 44 Prozent. Die häufigsten Anwendungsfälle waren UI- und Frontend-Entwicklung (25,2 Prozent), Bugfixing und Debugging (21,8 Prozent) und Backend-Codegenerierung (21,1 Prozent).

Das gemeinsame Bild: KI ist stark bei musterlastigen, kontextreichen Aufgaben und mittelmäßig bei Aufgaben, die tiefes Verständnis verlangen. Die Muster, die sie gut beherrscht, sind die, die sie in eurer Codebasis sieht. Deshalb zählt Context Engineering mehr als Prompt Engineering.

Wie lange dauert es, bis es sich auszahlt?

Nach unserer Erfahrung wird es zuerst schlechter: GenAI erzeugt mehr Arbeit, bevor sie weniger erzeugt. Wann es kippt, ist in jedem Unternehmen anders, und eure eigene Baseline von vor dem Rollout zeigt es euch. Teams, die im Tal stecken und es nicht eingeplant haben, geben dort auf.

Was antworte ich, wenn der Vorstand 10x verlangt?

Stellt zwei Gegenfragen. Messen wir überhaupt? Und hat sich rund um die Arbeit etwas verändert, bevor wir gezählt haben? Lauten die Antworten nein und nichts, habt ihr Adoption ohne Enablement gemessen. Tachos stabile 10 Prozent lesen wir genau so.

Fangt dann dort an, wo eure eigenen Daten liegen:

1. Messt zuerst eure Baseline, bei den DORA-Kennzahlen, Rework Rate, Nutzung des Ausgelieferten und Kosten pro Änderung.
2. Schaut, wohin die Zeit eurer Entwickler:innen geht, bevor ihr irgendetwas automatisiert. Findet, was die meisten Menschen blockiert und die meiste Nacharbeit verursacht, und setzt KI auf diesen Engpass an, nicht auf das, was sich am leichtesten automatisieren lässt.
3. Macht ein kontrolliertes Experiment: ein Team, eine Codebasis, echte Daten.
4. Investiert in die Codebasis und in Enablement, bevor ihr Tokens kauft: gemeinsamer Kontext, Konventionen, Tests und Gates, die der Agent selbst bestehen kann.
5. Plant Ressourcen für das Tal ein: rechnet mit Mehrarbeit vor dem Ertrag, die Grundlagen zuerst.

Was dieser Guide nicht beantworten kann

Viele Zahlen oben stammen aus Umfragen, selbst berichteten Anwendungsfällen oder Anbieter-Telemetrie, und PR-basierte Kennzahlen zählen Output, kein Ergebnis. Die großen Studien sind sich einig über einen bescheidenen Median und eine große Streuung. Wo euer Team auf dieser Spanne liegt, sagen sie nicht. Das sagt nur eure eigene Baseline.

Weiterlesen

Die Artikel der Wissensbasis sind auf Englisch.

• Measuring impact →
• Quality and productivity metrics →
• AI productivity research evidence →
• DORA 2025 Report and AI Strategy →
• Where gains and losses occur →
• The learning curve →
• The surrounding quality system →
• Modernization and interface design →
• Agentic Engineering for Engineering and Product Leaders →