Was bringt KI in der Softwareentwicklung wirklich? ROI messen mit DORA-Metriken statt Bauchgefühl

Das Wichtigste in Kürze KI-Werkzeuge sind in den meisten Entwicklungsteams längst angekommen. Spätestens bei der nächsten Budgetrunde fragt die Geschäftsführung, was sie tatsächlich bringen. Die üblichen Antworten stützen sich auf Herstellerangaben, Akzeptanzquoten von Code-Vorschlägen oder den Eindruck der Entwickler selbst. Keine dieser Zahlen belegt einen geschäftlichen Nutzen. Unabhängige Studien zeigen sogar, dass sich Entwickler mit KI schneller fühlen können, während sie tatsächlich langsamer arbeiten, und dass schnelleres Programmieren nicht automatisch zu schnelleren und stabileren Releases führt. Ein belastbarer Business Case braucht eine Ausgangsbasis, wenige aussagekräftige Kennzahlen zu Auslieferung und Qualität sowie eine ehrliche Gegenüberstellung von Nutzen und Kosten. Dieser Beitrag zeigt, warum die gängigen Zahlen in die Irre führen, welche Kennzahlen sich stattdessen eignen und wie Sie die Messung so aufsetzen, dass sie auch einer kritischen Prüfung standhält.

Gefühlte Produktivität ist keine Kennzahl

Fragt man ein Team, das mit KI-Coding-Assistenten arbeitet, ob es produktiver geworden ist, lautet die Antwort meist Ja. Das Problem: Gefühlte und gemessene Produktivität sind zwei verschiedene Dinge.

Mitte 2025 veröffentlichte die Forschungsorganisation METR eine randomisierte kontrollierte Studie mit erfahrenen Open-Source-Entwicklern, die an ihnen gut bekannten Projekten arbeiteten. Vor Beginn erwarteten die Teilnehmer, mit KI um 24 % schneller zu sein. Tatsächlich brauchten sie mit KI-Werkzeugen im Schnitt 19 % länger. Selbst nach Abschluss der Studie waren sie überzeugt, rund 20 % schneller gewesen zu sein.

Daraus folgt nicht, dass KI-Werkzeuge nutzlos wären. Die Studie bildet ein bestimmtes Umfeld ab, und andere Untersuchungen haben in anderen Konstellationen durchaus Zugewinne festgestellt. Sie zeigt aber, dass der Eindruck der Entwickler keine tragfähige Grundlage für Investitionsentscheidungen ist. Dasselbe gilt für die Zahlen, die in Herstellerunterlagen am häufigsten auftauchen:

• Die Menge an generiertem Code sagt nichts darüber aus, ob der Code gebraucht wurde, korrekt ist oder sich warten lässt.
• Die Akzeptanzquote von Vorschlägen misst, wie oft Entwickler auf „Übernehmen“ klicken, nicht aber, ob der übernommene Code Wert geschaffen hat.
• Der Anteil KI-generierten Codes kann steigen, während Qualität und Auslieferungstempo sinken.

Schneller programmieren heißt nicht schneller ausliefern

Das Schreiben von Code ist nur ein Schritt auf dem Weg einer Änderung in die Produktion. Anforderungen, Review, Tests, Sicherheitsprüfungen, Deployment und Störungsbehebung kosten ebenfalls Zeit. Beschleunigt KI nur das Programmieren, verlagert sich der Engpass lediglich. Reviewer bekommen mehr und größere Pull Requests auf den Tisch, die Testautomatisierung kommt nicht hinterher, und Änderungen stauen sich.

Das DORA-Forschungsprogramm von Google hat ein ähnliches Muster beobachtet. Laut Bericht 2024 ging eine stärkere KI-Nutzung zwar mit leichten Verbesserungen bei Dokumentationsqualität, Codequalität und Review-Geschwindigkeit einher, zugleich aber mit einem geschätzten Rückgang des Auslieferungsdurchsatzes um 1,5 % und der Stabilität um 7,2 % je 25 % mehr KI-Nutzung. Eine mögliche Erklärung der Forscher: KI erleichtert größere Änderungen, und große Änderungen sind beim Release riskanter.

Die Konsequenz lautet nicht, auf KI zu verzichten, sondern die Wirkung auf Ebene des gesamten Auslieferungsprozesses zu messen, nicht auf Ebene einzelner Tastenanschläge.

Welche Kennzahlen wirklich zählen

Ein brauchbares Messmodell setzt auf drei Ebenen an: Auslieferungsleistung, Qualität und Durchfluss sowie geschäftliche Wirkung.

Auslieferungsleistung: die DORA-Metriken

Die vier DORA-Metriken haben sich als Standard zur Bewertung der Softwareauslieferung etabliert:

• Deployment-Frequenz: wie oft das Team Änderungen in Produktion bringt.
• Durchlaufzeit von Änderungen: wie lange es dauert, bis eine eingecheckte Änderung in Produktion ist.
• Change Failure Rate: der Anteil der Deployments, die einen Fehler verursachen und eine Korrektur erfordern.
• Wiederherstellungszeit: wie schnell das Team den Betrieb nach einer Störung wiederherstellt.

Ihre Stärke liegt in der Ausgewogenheit. Zwei Kennzahlen messen Tempo, zwei messen Stabilität. Ein Team kann also nicht die eine Seite verbessern, indem es stillschweigend die andere opfert.

Qualität und Durchfluss

DORA-Metriken zeigen das Ergebnis, aber nicht immer die Ursache. Einige ergänzende Kennzahlen helfen, die Entwicklung einzuordnen:

Geschäftliche Wirkung

Schließlich müssen die Kennzahlen mit dem verknüpft werden, was für das Unternehmen zählt: Time-to-Market neuer Funktionen, freigewordene Entwicklungskapazität für die Roadmap sowie die Kosten von Störungen und Nacharbeit. Genau hier entsteht die ROI-Rechnung.

Was Sie besser nicht messen

Ebenso wichtig ist, was außen vor bleibt: die Leistung einzelner Entwickler, Codezeilen oder die KI-Nutzung pro Person. Individuelle Kennzahlen laden zum Schönen der Zahlen ein, beschädigen das Vertrauen und sagen wenig über Teamergebnisse aus. In Deutschland und Österreich kommt ein weiterer Punkt hinzu: Werkzeuge und Auswertungen, die geeignet sind, Verhalten oder Leistung von Beschäftigten zu überwachen, unterliegen der Mitbestimmung des Betriebsrats, in Deutschland nach § 87 Abs. 1 Nr. 6 BetrVG. Auch die DSGVO setzt der Auswertung personenbezogener Daten Grenzen. Kennzahlen auf Team- und Systemebene sind daher nicht nur aussagekräftiger, sondern auch rechtlich deutlich unkomplizierter.

So setzen Sie eine belastbare Messung auf

1. Vor der Einführung eine Ausgangsbasis schaffen. Erheben Sie mindestens vier bis acht Wochen lang Daten, bevor KI-Werkzeuge eingeführt oder ausgeweitet werden. Ohne Ausgangsbasis bleibt jede spätere Verbesserung eine Behauptung.

2. Mit einem Pilotteam und einer Vergleichsgruppe starten. Führen Sie KI zunächst in einem oder zwei Teams ein, während vergleichbare Teams wie bisher weiterarbeiten. So lässt sich der Effekt der KI von saisonalen Schwankungen, Umorganisationen oder Roadmap-Änderungen trennen.

3. Daten automatisch erfassen. Versionsverwaltung, CI/CD-Pipeline und Ticketsystem enthalten bereits den Großteil der benötigten Daten. Eine automatische Erfassung ist verlässlicher und belastet das Team weniger als manuelle Berichte. Gut instrumentierte CI/CD-Pipelines und ein sauber aufgesetzter Cloud-Betrieb erleichtern das erheblich.

4. Die Lernkurve einplanen. Teams werden oft zunächst langsamer, bevor sie schneller werden, weil sie erst herausfinden, welche Aufgaben die KI gut übernimmt, und ihre Abläufe anpassen. Bewerten Sie die Ergebnisse über mindestens ein bis drei Monate, nicht nach der ersten Woche.

5. Zahlen mit Rückmeldungen aus dem Team verbinden. Kurze, regelmäßige Befragungen zu Zufriedenheit, kognitiver Belastung und Vertrauen in KI-Ergebnisse erklären die Zahlen und machen Probleme sichtbar, bevor sie sich in den Kennzahlen niederschlagen.

6. Den Prozess anpassen, nicht nur die Werkzeuge. Steigt die Review-Dauer, helfen kleinere Pull Requests oder KI-gestützte Reviews. Sinkt die Stabilität, muss die Testautomatisierung nachziehen. Messen lohnt sich nur, wenn es die Arbeitsweise des Teams verändert.

Von der Kennzahl zum ROI: eine einfache Rechnung

Ein glaubwürdiger ROI stellt realistischen Nutzen den vollständigen Kosten gegenüber. Das folgende Beispiel arbeitet ausschließlich mit Beispielwerten, um die Logik zu veranschaulichen.

Eine Produktorganisation beschäftigt 20 Entwicklerinnen und Entwickler mit durchschnittlichen Vollkosten von 90.000 € pro Jahr, insgesamt also 1,8 Mio. €. Nach einer strukturierten Einführung liegt der gemessene Netto-Effizienzgewinn über den gesamten Auslieferungsprozess bei 10 %. Das entspricht Entwicklungskapazität im Wert von rund 180.000 € pro Jahr, die in Roadmap-Themen fließen kann.

Auf der Kostenseite stehen Lizenzen, Einführungsprogramm und Schulungen, der Aufwand für die Einrichtung von Abläufen und Messung sowie gegebenenfalls zusätzlicher Review-Aufwand. Belaufen sich diese Kosten im ersten Jahr auf 40.000 €, ergibt sich ein Nettonutzen von rund 140.000 €, also etwa das 3,5-Fache der Investition.

Wichtiger als die genauen Zahlen sind zwei Grundsätze. Erstens muss der Gewinn netto gerechnet werden: Zeit, die beim Programmieren gespart, im Review oder bei der Störungsbehebung aber wieder verloren geht, zählt nicht. Zweitens schafft freigewordene Kapazität nur dann Wert, wenn sie sinnvoll eingesetzt wird, etwa um Roadmap-Funktionen früher auszuliefern oder technische Schulden abzubauen.

Welche Ergebnisse realistisch sind

Ein strukturierter KI-Einsatz verdoppelt die Produktivität von Entwicklungsteams selten, kann aber verlässliche und messbare Verbesserungen bringen. In Projekten, die wir auf unserer Seite zur KI-gestützten Softwareentwicklung beschreiben, gehörten dazu:

• eine um rund 20 bis 25 % kürzere durchschnittliche Review-Dauer von Pull Requests,
• eine um rund 15 bis 20 Prozentpunkte höhere automatisierte Testabdeckung,
• eine um etwa eine Stufe verbesserte Deployment-Frequenz auf der DevOps-Reifeskala,
• rund 15 % Entwicklungskapazität, die für neue Funktionen frei wurde,
• in einem regulierten Fintech-Umfeld ein Netto-Effizienzgewinn von rund 10 bis 15 % bei niedrigerer Change Failure Rate und vollständiger Nachvollziehbarkeit für Prüfungen.

Verglichen mit Marketingversprechen sind das bescheidene Werte, und gerade deshalb sind sie glaubwürdig. Ein nachhaltiger zweistelliger Zugewinn, belegt durch Auslieferungsdaten, ist ein starker Business Case.

Die Ergebnisse hängen allerdings auch vom Ausgangspunkt ab. In großen Legacy-Codebasen mit geringer Testabdeckung kann KI ihren Nutzen kaum gefahrlos entfalten. Hier zeigt ein AI Refactoring Assessment, wo zunächst modernisiert werden sollte.

Typische Fehler

Zu früh messen. Wer KI nach zwei Wochen bewertet, misst die Lernkurve, nicht die langfristige Wirkung.

Nutzung mit Erfolg verwechseln. Eine hohe Nutzungsquote zeigt, dass die Werkzeuge verwendet werden, nicht, dass das Unternehmen davon profitiert.

Stabilität ausblenden. Mehr Tempo bei mehr Störungen ist kein Gewinn.

Einzelpersonen messen. Individuelle Kennzahlen verzerren das Verhalten, untergraben das Vertrauen und bringen in DACH zusätzlich Betriebsrat und Datenschutz ins Spiel.

Auf die Ausgangsbasis verzichten. Ohne Startwert lassen sich selbst echte Verbesserungen nicht überzeugend belegen.

Was sich nicht messen lässt, lässt sich nicht skalieren

KI in der Softwareentwicklung entwickelt sich vom Experiment zum festen Budgetposten. Unternehmen, die messbare Verbesserungen bei Tempo und Stabilität nachweisen können, werden weitere Investitionen deutlich leichter begründen, während Argumente auf Basis von Eindrücken bei Controlling und Geschäftsführung zunehmend auf Skepsis stoßen.

Investoren stellen dieselben Fragen. In einer technischen Due Diligence hebt sich ein Team, das DORA-Metriken im Zeitverlauf vorlegen und die Wirkung von KI auf seine Auslieferung erklären kann, klar von einem Team ab, das lediglich seine Werkzeuge aufzählt. Wenn Sie KI in Ihren Entwicklungsteams einführen oder ausweiten möchten, mit klarer Ausgangsbasis und messbaren Ergebnissen, erfahren Sie auf unserer Seite zur KI-gestützten Softwareentwicklung, wie wir mit einem fokussierten Pilotprojekt und einem Messmodell ab dem ersten Tag starten.