Wo fange ich an, Produktivitätsgewinne beim Einsatz von Large Language Models (LLMs) für die Softwareentwicklung zu messen? Ich greife in dieser kurzen Analyse einfach auf Daten aus dem Vortrag Does AI Actually Boost Developer Productivity? (Stanford 100k Devs Study) von Yegor Denisov-Blanch zurück. Hier wurden 136 Teams aus 27 Ländern befragt, ob sie durch den Einsatz von KI (eigentlich: von LLM-unterstützter Softwareentwicklung) eine Produktivitätssteigerung sehen.
Folgende Diagramme sind für meine Betrachtung des “Worauf kommt es an”-Faktors relevant und werden hier noch einmal von mir wiederholt sowie interpretiert.
Chart I: Die Context-Bremse
Eine der für mich interessantesten Erkenntnisse aus dem Vortrag ist eine 2x2-Matrix, die aufzeigt, in welchen Situationen KI-Unterstützung für Softwareentwickler:innen tatsächlich einen Produktivitätsmehrwert bringt. Anstatt pauschale Aussagen über KI-Produktivität zu treffen, schlüsselt die Matrix die Frage entlang zweier Dimensionen auf: wie ausgereift die Codebasis ist und wie komplex die jeweilige Aufgabe ist. Die Ergebnisse sind differenzierter, als es die üblichen Versprechen auf den Hochglanzbroschüren (oder Websites) diverser AI-Tool-Hersteller vermuten lassen.
Meine Interpretation
Die Matrix zeigt, dass die Produktivitätsgewinne durch KI bei Greenfield-Projekten mit geringer Aufgabenkomplexität am höchsten ausfallen und dort laut den Studienteilnehmenden eine Steigerung von 35–40 % erzielen. Der Grund liegt für mich auf der Hand: Aufgaben mit geringer Komplexität sind häufig repetitiv und klar definiert, sodass KI zuverlässig Boilerplate-lastigen Code mit minimalem Fehlerrisiko erzeugen kann. Zudem denke ich, dass wir uns hier in der Liga von Todo-Listen-Apps befinden: Tausend Mal programmiert, tausend Mal ist damit nichts weiter passiert.
Die Produktivitätsgewinne nehmen jedoch deutlich ab, sobald die Projektreife zunimmt und/oder die Aufgabenkomplexität steigt (also sobald es ernster wird):
- Bei Brownfield- und Legacy-Projekten sinken die Gewinne selbst bei einfachen Wartungsaufgaben auf 15–20 %, da veralteter Code und komplexe Abhängigkeiten einschränken, was KI sicher beitragen kann.
- Bei hochkomplexen Aufgaben in Systemen, die bereits einem Big Ball of Mud gleichen, schrumpfen die Produktivitätsgewinne auf lediglich 0–10 %, weil die KI hier Schwierigkeiten hat, verworrene Architekturen, unklare umgesetzte Ideen und tief verschachtelte Logik zu durchdringen.
Für mich an dieser Stelle nicht weiter verwunderlich: Die zugrundeliegenden Trainingsdaten stammen haufenweise aus öffentlich zugänglichen Code-Repositorien. Hier gibt es einen klaren Bias bezüglich dessen, was geteilt wird: Code, für den man sich nicht in der Öffentlichkeit schämen muss (also ist zumindest bei mir so). Die eigentliche Masse an Code, die anderen Idealbildern entspricht, bleibt in den geschlossenen Softwaresystemen der Unternehmen. Der erste Kontakt mit dieser Art von Code kann daher für ein LLM irritierend sein, wodurch bekannte Muster aus den Trainingsdaten schlechter auf die vorhandene Codebasis adaptiert werden können. Oder wie Ludwig Wittgenstein schon vor über hundert Jahren zu sagen pflegte:
Die Grenzen meiner Sprache bedeuten die Grenzen meiner Welt.
Doch selbst in idealen Greenfield-Umgebungen begrenzt hochkomplexe Arbeit den Einfluss der KI auf 10–15 %, da solche Aufgaben ein tieferes menschliches Urteilsvermögen erfordern, das mechanische Automatisierung nicht ersetzen kann. KI kann unterstützen, aber das architektonische Denkvermögen und das kontextuelle Urteil, das komplexes Engineering sowie Hintergrundwissen abverlangt, kann sie noch nicht ersetzen. Dies hat dann auch mit der begrenzten Menge an verfügbaren Context-Kapazitäten zu tun (siehe auch meine Einschätzung dazu in “Agentic Software Modernization: Chances and Traps”).
TL;DR: KI leistet am meisten, wenn das Problem klar eingegrenzt ist und die Codebasis sauber ist. Hohe Aufgabenkomplexität und Legacy-Code sind die zwei hauptsächlichen Produktivitätskiller beim Einsatz von KI, insbesondere im Zusammenspiel (was für die meisten unter uns die Realität sein dürfte).
Chart II: Die Nischen-Strafe
Das zweite Diagramm verlagert den Blickwinkel von der Projektreife auf die Wahl der Programmiersprache. Es stellt sich heraus, dass die Popularität der verwendete Sprache einen erheblichen Einfluss darauf hat, wie viel ein LLM tatsächlich helfen kann, was hauptsächlich durch die Menge an verfügbaren Trainingsdaten für die jeweilige Sprache bedingt ist.
Meine Interpretation
Bei verbreiteten Sprachen (z. B. Python, Java) entfalten LLMs ihren größten Nutzen: Bei einfachen Aufgaben steigert sie die Produktivität um 20–25 % dank umfangreicher Trainingsdaten (z. B. durch Reinforcement Learning auf Tausenden einfachen Frage-Antwort-Paaren), bei komplexen Aufgaben um 10–15 %. LLMs können hier dann wohl dank Unmengen an vielfältigen Trainingsdaten in der jeweiligen, populären Programmiersprache noch gut unterstützen. Aber auch im besten Fall erfordern komplexe Aufgaben weiterhin menschliches Urteilsvermögen, sodass KI eher als Beschleuniger denn als Ersatz wirkt.
Bei Nischensprachen (z. B. COBOL; wobei das für mich persönlich schon Mainstream ist) hingegen sind die Gewinne bei einfachen Aufgaben mit 0–5 % vernachlässigbar (bedingt durch begrenzte Trainingsdaten. Bei hochkomplexen Aufgaben verschlechtert sich die Situation weiter: Die Produktivität kann auf bis zu -5 % sinken, da die KI in eine halluzinationsanfällige Zone gerät, in der sie selbstsicher plausibel klingende, aber fehlerhafte Ausgaben produziert. Dies verdeutlicht, dass KI-Werkzeuge ohne ausreichende Trainingsdaten bei komplexer Entwicklungsarbeit eher zur Belastung als zum Vorteil werden können. Ich persönlich sehe hier auch in naher Zukunft keine positive Veränderung. Es zeichnet sich auch ab, dass selbst das aktive Bitten um Code in Nischenprogrammiersprachen nicht dazu führt, ordentlich Trainingsdaten hierzu zu bekommen (und ganz ehrlich: Welche Versicherung will schon ihren in COBOL-geschriebenen Rechenkern auf GitHub stellen?).
Der zugrundeliegende Treiber in allen vier Quadranten ist derselbe: Je mehr Trainingsdaten für eine bestimmte Sprache und einen bestimmten Aufgabentyp vorliegen, desto zuverlässiger kann KI einen Beitrag leisten. Die Popularität einer Sprache ist daher nicht nur eine Frage persönlicher Vorlieben, sondern ein direkter Indikator für den produktiveren Einsatz von LLM-gestützter Softwareentwicklung.
Chart III: Himmel oder Hölle
Beim dritten Diagramm kombiniere ich hemdsärmlig die Mittelwerte der Produktivitätsgewinne aus den beiden vorherigen 2x2-Diagrammen zu einer dritten Perspektive. Diese zeigt die Produktivitätsgewinne aufgeteilt nach Popularität der Programmiersprache und Reife des Projekts. Mich interessiert diese Perspektive besonders, weil ich einen konkreten Anlass dafür habe: Ich bin teils in Projekten unterwegs, in denen Programmiersprachen eingesetzt werden, die es nicht einmal in die Top 50 der populärsten Programmiersprachen des TIOBE Index (https://www.tiobe.com/tiobe-index/) schaffen, sowie Programmiersprachen, die dort auch nie und nimmer auftauchen werden, da es sie nur innerhalb eines Unternehmens gibt. Unerwähnt darf hier natürlich nicht bleiben, dass es sich um jahrzehntealte, riesige Softwaresysteme handelt, die nun doch langsam modernisiert werden wollen.
Hinweis: Diese kombinierte Ansicht ist kein formal validiertes Modell, sondern ein pragmatisches Gedankenexperiment, das zwei unabhängige Datenquellen durch einfache Mittelwertbildung verbindet. Sie soll Orientierung geben, nicht als präzise Vorhersage dienen.
Meine Interpretation
Werden beide Dimensionen, Projektreife (Greenfield vs. Brownfield) und Popularität der Programmiersprache, kombiniert, ergeben sich vier interessante Quadranten. Das beste Szenario, “AI Heaven”, tritt auf, wenn in einer verbreiteten Sprache an einem Greenfield-Projekt gearbeitet wird: Dort sind die höchsten Produktivitätsgewinne zu erwarten. Dies ist der Idealzustand: Umfangreiche Trainingsdaten treffen auf eine saubere, unbelastete Codebasis. KI kann ihr volles Potenzial entfalten. Deshalb funktioniert auch Vibe Coding bzw. Prototyping mit Sprachen wie TypeScript und Co. so hervorragend.
Bei Brownfield-Projekten in verbreiteten Sprachen sinken die Gewinne spürbar. Man zahlt nun die Zeche für das Schleifen-Lassen von Best Practices bezüglich der Codehygiene (hierzu gibt es auch einen hervorragenden weiteren Talk von Yegor Denisov-Blanch: “Can you prove AI ROI in Software Eng?”). Ein Large Language Model versteht die bekanntgemachte Programmiersprache nach wie vor gut, doch die Komplexität und die technischen Schulden der bestehenden Codebasis begrenzen seinen Beitrag.
Interessanterweise erzielen Nischensprachen bei Greenfield-Projekten immer noch merkliche Gewinne, was nur geringfügig schlechter ist als im Legacy-Code-Szenario mit verbreiteten Sprachen. Dies deutet darauf hin, dass eine saubere Codebasis schwächere Trainingsdaten teilweise kompensieren kann, die Sprachbarriere aber dennoch eine bedeutsame Obergrenze setzt. Mein Vorurteil hierzu ist, dass es eben immer einfacher ist, auf einer grünen Wiese zu starten, egal welche Programmiersprache zum Einsatz kommt (ich erinnere mich noch an die Zeit, als immer gesagt wurde “mit Scala / F# sind wir einfach schneller”, was mich damals schon kalt gelassen hatte. Interessant wird es, wenn man einen Berg an Code hat, der über eine Todo-Liste hinausgeht).
Das schlechteste Szenario ist “AI Hell”: Eine Nischensprache kombiniert mit einer Brownfield-Codebasis ergibt lediglich minimale Produktivitätsgewinne. Hier verstärken sich beide Hindernisse gegenseitig. Die KI verfügt weder über ausreichende Trainingsdaten für die Sprache noch ist sie in der Lage, eine verworrene Legacy-Codebasis sinnvoll zu durchdringen – das Ergebnis sind unzuverlässige Ausgaben und ein hohes Risiko, mehr Schaden als Nutzen anzurichten.
Die zentrale Erkenntnis lautet: Sprachpopularität und Projektreife sind beide eigenständig bedeutsam. Und: ihre negativen Effekte addieren sich. Bedeutet: Jede Dimension reduziert die KI-Produktivität für sich genommen bereits. Beide Dimensionen zusammen drücken die Produktivitätsgewinne durch den Einsatz von KI auf das unterste Niveau. Teams, die mit Nischensprachen in Legacy-Systemen arbeiten, sollten besonders vorsichtig sein, wenn es darum geht, sich zu stark rein auf KI-Werkzeuge zu verlassen (siehe hier z. B. meinen Artikel "Software Analytics going crAIzy! ").
PS: Hatte ich schon erwähnt, dass ich Anhänger des Boring Software Manifests bin und seit Jahren predige, sich diesem Manifest anzuschließen? Ich glaube, im Zeitalter agentischer Softwaremodernisierung wird das Manifest relevanter denn je zuvor. 😉
Wer sich für die Diagramme interessiert: Das zugehörige Jupyter Notebook, das die Bilder auf Basis der Daten aus dem Vortrag erstellt hat, ist hier verfügbar.
Header-Bild stamm von Wikipedia, Creative Commons CC0 1.0 Universal Public Domain Dedication.
.jpg){kind=link}