- Seit der Einführung von LLM-basierten Coding-Assistenten sind etwa 2 Jahre vergangen
- Einige Entwickler berichten, dass ihre Produktivität um bis zu das 5- bis 10-Fache gestiegen sei
- Es gibt jedoch keine klaren Belege dafür, dass die Produktivität der gesamten Softwarebranche um das 5- bis 10-Fache gestiegen ist
- Tatsächlich arbeiten LLM-Tools bei Aufgaben, die über das Hinzufügen einfacher Boilerplate-Funktionen zu einer Codebasis hinausgehen, oft heikel
- Die meisten Programmierer wissen nicht, wie man LLM-Tools effektiv einsetzt, oder haben kein Interesse daran
Warum Produktivitätssteigerungen auf bestimmte Nutzer konzentriert sind
- Wenn die Produktivität tatsächlich um das 5- bis 10-Fache gestiegen ist, dann wahrscheinlich beschränkt auf eine kleine Gruppe fortgeschrittener Nutzer oder erfahrener Entwickler, die gut mit LLMs umgehen können
- Es gibt keine Anzeichen dafür, dass die gesamte Softwarebranche plötzlich deutlich mehr nützliche Funktionen liefert oder dass sich die Qualität sichtbar verbessert hat
- Der Autor hat den Einfluss von LLMs in den vergangenen 1–2 Jahren selbst kaum gespürt
Welche Projekte wurden durch LLMs tatsächlich möglich?
- Es ist nicht klar erkennbar, welche Projekte erst durch die Leistungsfähigkeit von LLMs ermöglicht wurden
- Auch in Forschungsergebnissen finden sich kaum konkrete Beispiele (COBOL-Refactoring ist nahezu das einzige Beispiel)
- Selbst LLM-basierte Produkte aus AGI-Laboren zeigen keine besonders beeindruckenden Ergebnisse
- Sie bieten eher grundlegende Funktionen wie das Hochladen von PDFs in einem Dialogfenster
- Es fehlt an Funktionen, mit denen LLMs reibungslos mit verschiedenster Software und Datentypen interagieren können
Frage: Gibt es Bereiche, in denen die Produktivität real gestiegen ist?
- Es gibt keine klaren Belege dafür, welche Projekte dank LLMs schneller veröffentlicht wurden
- Im Software-Ökosystem sind keine Spuren eines 10-fachen Wachstums in bestimmten Bereichen zu erkennen
Gewünscht sind klare, praktische Belege
- Informationen der folgenden Art sind nicht hilfreich
- Vage Behauptungen über eine 10-fache Produktivitätssteigerung
- Hinweise auf abstrakte Wirtschaftsindikatoren oder eine gestiegene Codeproduktion
- Einfache Beispiele für LLM-basierte Tools oder Funktionsgenerierung
- Belanglose Demos wie „einen Snake-Klon mit ChatGPT bauen“
Theorie: Vielleicht steigern LLMs die tatsächliche Produktivität gar nicht
- Stattdessen geht Zeit für das Korrigieren und Beheben von Problemen in LLM-generiertem Code verloren
- Wenn von LLMs erzeugte große Codebasen eine gewisse Komplexität überschreiten, werden sie unter Umständen unwartbar und müssen am Ende komplett neu geschrieben werden
- Selbst wenn LLMs neue Software erzeugen, bleibt es oft wahrscheinlich bei Einmal-Tools oder ungenutztem Proof-of-Concept-Code
- Auch wenn in tatsächlich nützlicher Software die Code-Menge steigt, besteht das Risiko, dass unnötige Funktionen oder Bloatware zunehmen
- Es besteht die Möglichkeit, dass Programmierer durch das „magische“ Erlebnis unmittelbarer Ergebnisse mit LLMs getäuscht werden
Realistische Größenordnung von Produktivitätssteigerungen
- Nach der Erfahrung des Autors sind LLMs nur in bestimmten Fällen nützlich
- Schreiben kleiner, trivialer Funktionen
- Unterstützung beim Erlernen bestimmter Bibliotheken oder Codebasen
- Durchführung einfacher Refactoring-Arbeiten
- Die Produktivitätssteigerung liegt wahrscheinlich eher bei etwa 10–30 %
- Eine maximale Produktivitätssteigerung dürfte schwer erreichbar sein, bevor AGI (allgemeine künstliche Intelligenz) erscheint
[Kommentar von Richard Horvath]
Fälle, in denen LLMs in bestimmten Situationen eine 10-fache Beschleunigung liefern können
- Schreiben kleiner, eigenständiger Skripte
- Bei einfachen Aufgaben (z. B. bash-Skripte zur Dateiverarbeitung oder Excel-VBA-Code) zeigen sie große Wirkung
- Mit einer kurzen Beschreibung lassen sie sich leicht erstellen und ebenso leicht überprüfen
- Auch ohne tiefes Wissen über die Sprache sind solche Skripte möglich
- Wartbarkeit, Modularisierung oder Unit-Tests müssen dabei oft nicht berücksichtigt werden
- Besonders bei Aufgaben mit regulären Ausdrücken (regex) sind sie sehr effektiv
- Schnelleres Lernen bei Arbeit mit unbekannten Stacks
- Klassen und Methoden neuer Bibliotheken lassen sich schnell erfassen
- Selbst wenn der erzeugte Code nicht vollständig funktioniert, liefert er Ansätze zur Problemlösung
- Das spart viel Zeit, die früher für Dokumentation oder Tutorials draufging
- Der generierte Code muss jedoch weiterhin manuell angepasst und refaktoriert werden
Personen, die von einer 10-fachen Produktivitätssteigerung berichten, dürften oft in eine der folgenden Gruppen fallen
- Geringes Entwicklungswissen
- Wenn grundlegende Coding-Fähigkeiten fehlen, kann mit LLM-Hilfe geschriebener Code im Vergleich zu früher deutlich besser wirken
- In solchen Fällen ist aber auch wahrscheinlich, dass LLM-Code langfristig negative Folgen hat
- Viele kleine, isolierte Lösungen müssen geschrieben werden
- Etwa bei Excel-Automatisierung oder Shell-Skripten im DevOps-Bereich sind LLMs besonders nützlich
- Häufiges Experimentieren mit verschiedenen Stacks und Bibliotheken
- Das gilt eher für experimentgetriebene Arbeit als für langfristige Arbeit in einem bestimmten Stack
- Anchoring Effect
- Wenn ein LLM bei einer bestimmten Aufgabe sofort starke Ergebnisse liefert, wird dies leicht als langfristige Produktivitätssteigerung überschätzt
[Kommentar von Davidmanheim]
- Aus Sicht von Entwicklern und Management in typischen Unternehmen kann die Produktivitätssteigerung durch LLMs in der Praxis nur begrenzt sein
- Das lässt sich aus der Perspektive der Theory of Constraints erklären:
- Angenommen, die Arbeit wurde bisher durch einen Prozess wie diesen abgeschlossen:
- Business Analyst → 1 Tag
- QA-Tester → 1 Tag
- Programmierer → 1 Tag
- Selbst wenn sich die Produktivität des Programmierers um das 2- oder 5-Fache erhöht, verkürzt sich die Gesamtdauer nicht
- Denn andere Phasen (Business-Analyse und QA) werden zum Engpass, sodass die Prozessgeschwindigkeit insgesamt gleich bleibt
- Unternehmensprozesse müssen neu gestaltet werden
- Um Produktivitätsgewinne durch LLMs maximal auszuschöpfen, muss der gesamte Unternehmensprozess umgebaut werden
- Derzeit beginnt eine solche Umgestaltung jedoch erst in einigen wenigen Unternehmen
[Kommentar von faul_sname]
- Mit LLMs wurden insbesondere bei der Erstellung von UI-Mockups folgende Effekte erlebt:
- Früher machte die Erstellung von UI-Mockups etwa 10 % der gesamten Arbeitszeit aus
- Dank LLMs wurde die Erstellung von UI-Mockups etwa 5-mal schneller
- Die gesamte Arbeitszeit selbst wurde dadurch jedoch nicht verkürzt
- Stattdessen haben sich Detailgrad und Interaktivität der UI-Mockups stark verbessert
- Mehr Iterationen wurden möglich, was letztlich die Produktqualität verbessert hat
- „Wegwerf-Code“ bedeutet nicht zwangsläufig, dass er nutzlos ist
- Auch Prototypen oder Proof-of-Concept-Code können zur Entwicklung eines besseren Endprodukts beitragen
- Außerdem liefern LLMs Antworten auf bestimmte Fehler, die sich über Suchmaschinen schwer finden lassen
- Beispiel: „Wie behebt man einen Fehler in einem laufenden Task auf dem xyz-Stack?“
- Sie helfen beim Debugging in konkreten Stack- und Kubernetes-Konfigurationen
- Die gesamte Produktivitätssteigerung wird auf etwa 10–30 % geschätzt
- Allerdings steigt die Produktivität nicht bei allen Aufgaben gleichmäßig
- Dramatische Geschwindigkeitsgewinne bei bestimmten Aufgaben (z. B. UI-Mockups, Debugging)
- Kaum nennenswerte Erfolge bei komplexem oder Legacy-Code
- Produktivitätsgewinne sind zu Beginn eines Projekts besonders deutlich, in komplexen Wartungsphasen nimmt der Effekt ab
- Die Grenze liegt hier daher nicht bei mangelnder Agency, sondern beim Context Management
[Kommentar von Noosphere89]
- Unter Berufung auf die Ansicht von Ajeya Cotra werden folgende Punkte zur Wirkung von LLMs auf die Produktivität von Programmierern genannt:
- Die Produktivität von AI bei Coding-Aufgaben ist höher als erwartet
- AI erzielt bei Coding-Aufgaben erhebliche Resultate
- Bei Aufgaben außerhalb des Codings fällt die Leistung jedoch stark ab
- Deshalb ist der gesamte industrielle Einfluss von AI bislang noch begrenzt
- Links zu relevanten Aussagen von Ajeya Cotra
- Zur Behauptung „Für langfristige Ergebnisse braucht es AGI“ heißt es außerdem
- Auf dem aktuellen Entwicklungspfad von AI gibt es weniger allgemeine Fähigkeiten (Generality) als erwartet
- Die Leistung von AI verbessert sich bei bestimmten Aufgaben sprunghaft oder zeigt in bestimmten Bereichen Schwächen
- Wegen dieser Ungleichverteilung der Fähigkeiten könnte das Konzept AGI (allgemeine künstliche Intelligenz) weniger nützlich sein als gedacht
[Kommentar von yo-cuddles]
- Ein Beispiel aus meinem Büro betrifft eine Person, die Robotic Process Automation (RPA) betreibt
- Er behauptet nachdrücklich, viel produktiver zu sein
- Tatsächlich arbeitet er jedoch ineffizient und unzuverlässig, sodass andere Zeit damit verlieren, seine Arbeit zu korrigieren
- Kollegen versuchen, ihn aus dem Workflow herauszuhalten
- Menschen messen ihre eigene Produktivität nicht gut und nehmen nur bestimmte Gewinne oder Verluste deutlich wahr:
- Fokus auf sichtbare Erfolge
- Wenn eine Aufgabe durch Automatisierung schnell erledigt wird, ist das unmittelbare Erfolgsgefühl groß
- Schnelle Ergebnisse sind sofort sichtbar und werden daher als positiver Effekt wahrgenommen
- Langfristige Kosten sind schwer zu erkennen
- Zeitkosten, die nach der eigentlichen Arbeit entstehen, lassen sich schwer nachverfolgen
- Besonders wenn andere die Probleme beheben, bleiben diese Kosten unsichtbar
- Selbst wenn Fehler aus automatisierten Abläufen korrigiert werden, ist der dadurch verursachte Zeitverlust schwer spürbar
- Probleme, die LLM-Code verursacht, sind aus folgenden Gründen schwer zu erkennen:
- Bei Bugs ist es schwer, die Ursache eindeutig auf LLM-Code zurückzuführen
- Beim Beheben von Problemen können andere zusätzlich Zeit verlieren
- Die eigentliche Ursache des Problems wird oft nicht erkannt, und man merkt nicht, dass der Einsatz des Automatisierungstools der Auslöser war
- Das Gefühl „Dank Automatisierung war ich schnell fertig“ ist stark, aber „Wegen Automatisierung ging Zeit verloren“ ist schwer zu spüren
- Obwohl die Nutzung von LLMs weit verbreitet ist, zeigt sich kein klarer Produktivitätsanstieg in der gesamten Branche
- Menschen behaupten, „doppelt so produktiv“ zu sein, doch tatsächlich könnte die Produktivität durch versteckte Probleme sogar gesunken sein
- Mit anderen Worten: Da die für Problemlösung verbrauchte Zeit und die Ressourcen unsichtbar bleiben, entsteht eine übertriebene Wahrnehmung des Erfolgs
6 Kommentare
Das entspricht ziemlich genau meiner eigenen Erfahrung.
In solchen Fällen habe ich ziemlich viel Zeit gespart. Mit der Kombination aus Google + Stack Overflow findet man vieles oft nicht gut, und besonders bei Stack Overflow gab es häufig nervige Situationen, in denen es zwar eine Antwort gab, aber in den Kommentaren ständig Einwände erhoben wurden oder gesagt wurde, dass es eine Implementierung aus einer alten Version sei und man sie nicht verwenden solle ...
Ich glaube, dass eine 10-fache Produktivität vor allem beim Prototyping zum Tragen kommt.
Für mich ist das ganz süß.
> Die meisten Programmierer wissen nicht, wie man LLM-Tools effektiv nutzt, oder interessieren sich nicht dafür
Überraschend viele Entwickler in meinem Umfeld interessieren sich eigentlich nicht besonders für Technik. Sie verbringen den Großteil ihrer Zeit damit, neue oder sich wiederholende YouTube Shorts mechanisch zu konsumieren.
Hacker-News-Meinungen
Arbeitet bei einem beliebten Tech-Unternehmen in Seattle, wo die Nutzung von AI forciert wird. Die Führungsebene verfolgt, wie stark Entwickler AI nutzen, und hat auch persönlich gefragt, warum man AI nicht häufiger verwendet. Es sei wichtig, für die richtige Aufgabe das richtige Werkzeug einzusetzen, und AI sei nicht immer geeignet.
Es gibt das alte Sprichwort, dass die letzten 10 % eines Softwareprojekts 90 % der Zeit kosten. AI ist in den ersten 90 % nützlich, bei den letzten 10 % hilft sie jedoch nicht.
Bei FAANG werden LLMs integriert in der IDE verwendet, mit leicht positiven Effekten.
Als Beispiel für einen Entwickler, der tatsächlich eine 10-fache Verbesserung erlebt hat, wird Pieter Levels genannt, der in wenigen Tagen einen 3D-Multiplayer-Flugsimulator programmiert hat.
Es wurde versucht, mit LLMs Code zu generieren, aber anfangs sank die Produktivität.
Mitglied eines Teams bei GitHub, das Copilot Autofix entwickelt und auf Basis von CodeQL-Warnungen Korrekturvorschläge liefert.
Die Qualität der Antworten von LLM-Coding-Assistenten hängt stark von der Kommunikationsfähigkeit des Programmierers ab.
Die Annahme, dass sich die Produktivität in der Softwareentwicklung nicht um das 5- bis 10-Fache verbessert habe, könnte falsch sein.
Die letzte Aussage in der übersetzten Zusammenfassung der Hacker-News-Meinungen, „Die Annahme, dass sich die Produktivität in der Softwareentwicklung nicht um das 5- bis 10-Fache verbessert hat, könnte falsch sein“, scheint eine Fehlübersetzung zu sein. Wenn man den Originaltext betrachtet, wäre eine neutralere Zusammenfassung etwa: „Die Behauptung, dass sich die Produktivität in der Softwareentwicklung um das 5- bis 10-Fache verbessert habe, beruht auf einer falschen Annahme über Produktivitätssteigerung.“