Einleitung – Missverständnisse und Realität bei der Produktivität von KI-Entwicklern
- Mark Zuckerberg (Meta-CEO) erklärte, er wolle „bis Ende 2025 alle Mid-Level-Ingenieure durch KI ersetzen“, wodurch CTOs in vielen Unternehmen unter ähnlichen Druck geraten.
- Der Vortragende macht klar, dass „KI Entwickler nicht vollständig ersetzen kann“, und betont, dass die Einführung von KI die Produktivität zwar eindeutig verbessern kann, aber nicht immer – und dass Produktivitätsrückgänge keineswegs selten sind.
Studiendesign und Daten
- Gemessen über 3 Jahre hinweg bei rund 600 Unternehmen, mehr als 100.000 Softwareingenieuren, über einer Milliarde Codezeilen und zig Millionen Commits.
- Die meisten Daten stammen aus privaten Repositories (Private Repos) → dadurch lassen sich tatsächliche Produktivitätsveränderungen auf Team- und Unternehmensebene messen.
Grenzen bisheriger Forschung
- Vendor-getriebene Berichte dienen oft der Vermarktung eigener KI-Tools und sind daher nur begrenzt objektiv.
- Die bloße Zahl von Commits/PRs oder Veränderungen der durchschnittlichen Bearbeitungszeit kann die tatsächliche Produktivität verzerren.
- Beispiel: Direkt nach dem Einsatz von KI steigen oft auch Bugfix- oder Rework-Commits, sodass es oberflächlich so wirkt, als sei die Produktivität gestiegen.
- In „Greenfield-(neues Projekt)-Experimenten“ erscheint der Effekt von KI sehr groß, bei bestehendem Code (Brownfield) schrumpft der Unterschied jedoch.
- Entwicklerumfragen (Self-Reports) korrelieren kaum mit realer Produktivität (eine Lücke von mehr als 30 Prozentpunkten zwischen empfundener und tatsächlicher Wirkung).
Stanfords Modell zur Produktivitätsmessung
- Einsatz eines KI-basierten Automatisierungsmodells, das einer Bewertung durch Expertengremien ähnelt:
- Messung funktionaler Veränderungen pro Commit (added/removed/refactored/rework)
- Fokus nicht auf der bloßen „Zeilenzahl“, sondern auf „Funktionalität, Wartbarkeit und Qualität“
- Präzise Erfassung von Umfang der Funktionseinführung, Refactoring und Anteil späterer Überarbeitungen (rework) an aktuellen Commits.
Zentrale Forschungsergebnisse
- Insgesamt steigt die durchschnittliche Produktivität bei Einführung von KI um 15–20 %.
- Allerdings geht dies mit einem erheblichen Anteil an „Nacharbeit“ (rework) einher, wodurch der gefühlte Nutzen tendenziell überschätzt wird.
- Je nach Team, Unternehmen und Aufgabentyp gibt es große Unterschiede.
Ursachen der Produktivitätsunterschiede: Aufgabenschwierigkeit, Projekttyp, Sprache, Größe der Codebasis
| Projekttyp | Geringe Komplexität | Hohe Komplexität |
|---|---|---|
| Greenfield (neu) | 30–40 % ↑ | 10–15 % ↑ |
| Brownfield (bestehend) | 15–20 % ↑ | 0–10 % ↑ |
- Bei wenig komplexen, neuen (Greenfield-)Projekten ist der Effekt von KI groß.
- In bestehenden (Brownfield) und komplexen Systemen sinkt der Effekt deutlich; in einigen Fällen wurden sogar Produktivitätsrückgänge festgestellt.
- Grundlage ist eine Stichprobe von 136 Teams aus 27 Unternehmen (im Vortrag erwähnt).
Beliebtheit von Sprachen und KI-Effekt
- Bei Python/Java/JavaScript (populäre Sprachen) ist der Produktivitätsschub durch KI deutlich,
- bei COBOL/Elixir/Haskell (weniger populäre Sprachen) hilft KI kaum und verursacht bei komplexen Aufgaben teils sogar Zeitverlust und Produktivitätsrückgang.
- Beispiel: Bei unpopulären Sprachen & hoher Schwierigkeit „viele Fehler, kein korrekter Code“ → dann ist es besser ohne.
Größe der Codebasis und KI-Effekt
- Je größer die Codebasis, desto stärker nimmt der Produktivitätsgewinn durch KI ab.
- Gründe:
- Grenzen des Kontextfensters: Ein LLM kann nicht den vollständigen Kontext vieler Dateien bzw. von Hunderttausenden bis Millionen Zeilen erfassen.
- Sinkendes „Signal/Rauschen-Verhältnis“: Je mehr Kontextinformationen vorhanden sind, desto schlechter kann KI relevante Informationen korrekt identifizieren.
- Mit zunehmender domänen- und servicebezogener Komplexität steigt auch die reale Schwierigkeit der Umsetzung.
- Tatsächlich fällt bei aktuellen großen LLMs (z. B. Gemini 1.5 Pro) die Genauigkeit mit wachsender „Token-Zahl“ stark von 90 % auf unter 50 %.
- Gründe:
Zusammenfassung: Wann ist KI effektiv?
- KI steigert in den meisten Fällen – insbesondere beim Schreiben einfacher neuer Codes – klar die Produktivität von Entwicklern.
- Doch in Umgebungen mit komplexer Wartung, altem (großem) Code, Nischensprachen und vielen Abhängigkeiten sind die Grenzen groß,
- und die beste KI-Produktivitätsstrategie muss sorgfältig auf Unternehmen, Team und Aufgabentyp zugeschnitten werden (kein „one size fits all“).
- Umfragen, Marketing-Metriken und steigende Commit-Zahlen allein sind wenig verlässlich; nötig sind „realitätsnahe Messungen“ anhand tatsächlicher Funktionalität, des Anteils wiederholter Arbeit und des Umfangs von Nacharbeit.
Zusätzliche Kommentare und Beispiele
- „Ghost Engineers“: In den Daten wurden auch Fälle gefunden, in denen 10 % der Ingenieure kaum arbeiten und nur Gehalt beziehen.
- Betont wird die Notwendigkeit von „metrikenbasierter Entscheidungsunterstützung“, damit Teamleiter und CTOs reale Probleme schnell diagnostizieren können.
Fazit
- KI steigert in „den meisten Situationen“ die Produktivität, aber sowohl Über- als auch Unterschätzung sind zu vermeiden.
- Man sollte die konkreten Bedingungen für erfolgreiche Einführung („einfach/neu/populäre Sprache/kleine Codebasis“) identifizieren und gezielt anwenden; eine unkritische, pauschale Einführung kann sogar kontraproduktiv sein.
2 Kommentare
Auch wenn man sie nicht direkt in der Hauptsoftware einsetzt, spart AI bei Testprogrammen oder in der Startphase eines Projekts sehr viel Zeit.
Selbst wenn man das Schreiben von Code außen vor lässt, haben sich die Assistentenfunktionen seit der Einführung von AI meiner Meinung nach grundlegend verändert. Ich denke, wir leben inzwischen in einer Zeit, in der AI keine Option mehr, sondern eine Notwendigkeit ist.
Tatsächlich hilft es bei einem MVP sehr. Besonders bei Kommentaren, Logging und dem Schreiben der Historie sollte man es meiner Meinung nach unbedingt verwenden.
Wenn die Codebasis jedoch größer wird, kommt es zu Halluzinationen, und das Modell vergisst den bestehenden Code und erzeugt seltsame Ergebnisse. Man muss überlegen, Context Engineering einzusetzen oder Wege zu finden, die Codebasis zu verkleinern.
Wahrscheinlich würde es sich verbessern, wenn man größere Prompts verwenden könnte.
Derzeit scheint es mit Java, Python, JavaScript und Go gut zu funktionieren. Ich nutze hauptsächlich Copilot und außerdem Claude und ChatGPT.