# denisov-blanch-stanford-quantify-ai-roi-software-engineering-2025-11-23

## Veille

Stanford-Forschung – Messung des KI-ROI – Entwicklerproduktivität – Metrik-Framework – KI-Adoptionslücke

## Titre Article

How to Quantify AI ROI in Software Engineering (Stanford Study / 120k Devs)

## Date

2025-11-23

## URL

https://www.youtube.com/live/cMSprbJ95jg?si=4HnxK8w1ELvSr4tz&t=9705

## Keywords

Stanford, AI ROI, Developer Productivity, Metrics, Code Quality, Tech Debt, AI Adoption, Engineering Output, Rework

## Authors

Yegor Denisov-Blanch (Researcher, Stanford)

## Ton

**Profil:** Akademisch-wissenschaftlich | Datengetrieben | Analytisch | Objektiv

Der Ton entspricht rigoroser akademischer Forschung, angewandt auf die Industrie. Der Ansatz stützt sich auf quantitative Evidenz (longitudinale und Querschnittsstudien über 120.000 Entwickler hinweg). Der Diskurs zielt darauf ab, den „Hype“ durch solide Daten zu entmystifizieren, indem ausgefeilte Messrahmen vorgeschlagen werden (ML-Modelle zur Bewertung des Outputs, Code-Sauberkeitsindizes). Es handelt sich um einen Aufruf zu metrischer Genauigkeit, gerichtet an technische Führungskräfte.

## Pense-betes

- **Widening Gap**: Teams, die mit KI gut abschneiden, verbessern sich noch weiter („rich gets richer“), während schwächelnde Teams weiter zurückfallen. Zu wissen, zu welcher Kohorte man gehört, ist entscheidend.
- **Qualität der Nutzung > Quantität**: Die Korrelation zwischen der Anzahl der genutzten Tokens und der Produktivität ist schwach. Entscheidend ist, *wie* KI genutzt wird (Engineering-Muster).
- **Code Hygiene (Cleanliness Index)**: Sauberer, modularer, getesteter Code verstärkt die Gewinne der KI. Umgekehrt beschleunigt auf unordentlichem Code eingesetzte KI die Entropie und die technischen Schulden.
- **ROI messen**:
- Nicht auf Geschäftsergebnisse verlassen (zu viel Rauschen/Störfaktoren).
- Nicht auf vereinfachte Metriken verlassen (Codezeilen, Anzahl der PRs). Eine Zunahme der PRs kann einen Qualitätsrückgang und eine Zunahme des „Rework“ (Nacharbeit) verschleiern.
- **Vorgeschlagenes Metrik-Framework**:
- **Primärmetrik**: Engineering Output (bewertet durch ein ML-Modell, das ein Expertengremium simuliert, nicht nur das Volumen).
- **„Guardrail“-Metriken**: Qualität, Rework/Refactoring, Team-Gesundheit (DevOps-Metriken). Ziel ist es, den Output zu maximieren und dabei die Guardrails gesund zu halten.
- **Fallstudie (Warnung)**: Ein Unternehmen verzeichnete +14 % PRs durch KI, aber einen Qualitätsrückgang um 9 % und eine Verdreieinhalbfachung (2,5x) des Rework. Ohne feingranulare Messung sah dies wie ein Erfolg aus, während der ROI wahrscheinlich negativ war.

## RésuméDe400mots

Yegor Denisov-Blanch, Forscher an der Stanford University, präsentiert die Ergebnisse einer groß angelegten Studie zur Auswirkung von KI auf die Produktivität von mehr als 100.000 Entwicklern. Ziel ist es, über den „Hype“ hinauszugehen und den tatsächlichen Return on Investment (ROI) zu quantifizieren.

Die Studie zeigt eine **sich vergrößernde Kluft**: Der Leistungsunterschied zwischen Teams, die mit KI erfolgreich sind, und solchen, die scheitern, wächst. Entgegen der landläufigen Meinung korreliert der Umfang der KI-Nutzung (Anzahl der Tokens) nur schwach mit der Produktivität. Der entscheidende Faktor ist die **Qualität der Code-Umgebung** („Codebase Hygiene“). Sauberer, gut getesteter, gut dokumentierter Code ermöglicht es der KI, gute Leistung zu erbringen. Umgekehrt riskiert KI bei einer degradierten Codebasis, Entropie und technische Schulden zu beschleunigen, was mehr menschlichen Aufwand zur Fehlerkorrektur erfordert.

Denisov-Blanch warnt vor vereinfachten Metriken wie der Anzahl der Pull Requests (PRs). Er nennt das Beispiel eines Unternehmens, das eine Zunahme der PRs um 14 % beobachtete, was zunächst als Erfolg interpretiert wurde. Eine detailliertere Analyse ergab einen Rückgang der Codequalität um 9 % und eine Verdreieinhalbfachung (2,5x) des „Rework“ (Nacharbeit an kürzlich geschriebenem Code). Der Gewinn an Volumen wurde durch den Qualitätsrückgang aufgewogen, wodurch der ROI potenziell negativ war.

Um den ROI korrekt zu messen, schlägt Stanford ein Framework vor:
1. **Nutzung messen**: Unterscheidung zwischen theoretischem Zugang und tatsächlicher Nutzung (mittels feingranularer Telemetrie) und Identifikation von Nutzungs-„Mustern“ (persönliche Nutzung vs. agentische Orchestrierung).
2. **„Engineering Outcomes“ messen**: Verwendung einer primären **„Engineering Output“**-Metrik (basierend auf einem ML-Modell, das darauf trainiert ist, die Bewertung menschlicher Experten nachzubilden, anstatt auf dem Volumen der Codezeilen) gekoppelt mit **„Guardrail“-Metriken** (Qualität, Rework-Rate, Team-Gesundheit), die auf einem gesunden Niveau gehalten werden müssen.

Die Schlussfolgerung lautet, dass KI ein Verstärker ist: Sie beschleunigt sowohl gute als auch schlechte Praktiken. Führungskräfte müssen die Auswirkungen präzise messen, um nachzusteuern und in die Code-Hygiene zu investieren, um das Potenzial der KI zu erschließen.

## GrapheDeConnaissance

- Yegor Denisov-Blanch —a_créé→ étude ROI IA développement (EVENEMENT, 0.95)
- Stanford —emploie→ Yegor Denisov-Blanch (PERSONNE, 0.95)
- étude Stanford —mesure→ 120 000 développeurs analysés (MESURE, 0.95)
- hygiène du code —améliore→ gains IA (CONCEPT, 0.92)
- code sale —permet→ dette technique avec IA (CONCEPT, 0.9)
- métriques simplistes —permet→ masquage de la baisse qualité réelle (CONCEPT, 0.88)
- Engineering Output —remplace→ métriques volume (lignes, PRs) (CONCEPT, 0.85)
- IA développement —permet→ creusement écart équipes performantes/faibles (CONCEPT, 0.9)
- étude Stanford —affirme_que→ la quantité de tokens corrèle faiblement avec la productivité développeur (AFFIRMATION, 0.88)
- Yegor Denisov-Blanch —recommande→ framework métriques guardrails (METHODOLOGIE, 0.88)

---
Canonical: https://www.thekb.eu/de/fiches/denisov-blanch-stanford-quantify-ai-roi-software-engineering-2025-11-23/