Die Auswirkungen von Gen AI auf hochqualifizierte Arbeit: Ein Experiment mit Softwareentwicklern

Zusammenfassung

• Studienüberblick
  • Diese Studie bewertet die Auswirkungen generativer KI auf die Produktivität von Softwareentwicklern anhand von drei randomisierten kontrollierten Experimenten, die bei Microsoft, Accenture und einem anonymen Elektronikhersteller aus den Fortune 100 durchgeführt wurden.
  • Die Experimente wurden als Teil der täglichen Arbeit in den jeweiligen Unternehmen durchgeführt, wobei zufällig ausgewählten Entwicklern der KI-gestützte Coding-Assistent GitHub Copilot zur Verfügung gestellt wurde.
  • Die Studie mit insgesamt 4.867 Softwareentwicklern ergab, dass die Zahl der abgeschlossenen Aufgaben bei Entwicklern, die KI-Tools nutzten, um 26,08 % anstieg (Standardfehler: 10,3 %).
  • Insbesondere weniger erfahrene Entwickler zeigten höhere Nutzungsraten und Produktivitätssteigerungen.

GN⁺-Zusammenfassung

• Diese Studie zeigt, dass generative KI die Produktivität von Softwareentwicklern deutlich steigern kann.
• Besonders nützlich ist sie für weniger erfahrene Entwickler, was darauf hindeutet, dass KI-Tools helfen können, die Lernkurve abzuflachen.
• KI-Tools wie GitHub Copilot können eine wichtige Rolle dabei spielen, die Effizienz der Softwareentwicklung zu erhöhen.
• Andere Projekte mit ähnlichen Funktionen sind unter anderem TabNine und Kite.

[GN⁺]

Hacker-News-Kommentare

• Manchmal frage ich mich, ob die Qualität der IT-Belegschaft deshalb sinkt, weil Unternehmen immer mehr Rollen auf eine Person abwälzen, um Personal abzubauen.
  Früher waren Entwicklung, Betrieb und Security jeweils eigene, dedizierte Rollen. Als DevOps aufkam, verstanden manche Unternehmen das nicht als Zusammenführung von Teams, sondern als „wir brauchen nur noch zwei Drittel der Leute“. Als DevSecOps aufkam, hieß es dann: Ein Drittel der ursprünglichen Rollen reicht, und Entwickler sollen Betrieb und Anwendungssicherheit gleich mit übernehmen.
  Ich kritisiere nicht shift-left oder integrierte Betriebsmodelle an sich; ich meine, dass dies die logische Folge solcher Modelle ist, wenn Führungskräfte glauben, sie bekämen höhere Boni, wenn sie durch Personalabbau Kosten senken.
  Heute kommt ein Junior-Entwickler in eine absurd komplexe Umgebung mit n Microservices, muss eine bestehende Codebasis, fünf CI/CD-Pipelines und sogar DBA-Aufgaben lernen und gleichzeitig einen stetigen Release-Zyklus einhalten.
  Ist es da wirklich überraschend, dass man ChatGPT nutzt, um Schritt zu halten? Und das wird so weitergehen, bis IT-Unternehmen aufhören, Personal abzubauen, nur um statt einer guten Geschäftsstrategie die „Linie nach oben“ zu bekommen.

  • In Startups kann eine Person die Arbeit von drei Leuten übernehmen, und das passiert auch oft.
    Was MBAs meiner Meinung nach übersehen, ist das Phänomen der übermäßigen Constraints. Wenn man die allgemeine Rolle „Entwickler“ in „Entwicklung, Betrieb, Security“ aufspaltet, entstehen unzählige Details dazu, wie jede Rolle auszuführen ist. Selbst wenn man sie später wieder zu DevSecOps zusammenführt, bleiben diese Details bestehen; eine Person arbeitet dann nicht dreimal effizienter, sondern bekommt dreimal so viel Arbeit aufgeladen.
    Um das wirklich rückgängig zu machen, muss man die Constraints lockern und dieser einen Person erlauben, selbst zu beurteilen, wie sie die Arbeit erledigt.
    Die daraus folgende Schlussfolgerung ist, dass Organisationen nicht kleiner werden können, sondern nur größer. Je mehr Mitarbeiter es gibt, desto spezialisierter werden die Aufgaben; schafft man sie ab, wird diese Funktion einfach nicht mehr ausgeführt. Denn auf diesem Spezialisierungsniveau ist es für die verbleibenden Mitarbeiter schwer, mit einer leicht geänderten Stellenbeschreibung neue Verantwortlichkeiten zu übernehmen.
    Am Ende muss man die alte Organisation aufgeben und mit einer neuen, kleineren Organisation neu anfangen; genau deshalb existieren Private-Equity-, Venture-Capital- und Startup-Ökosysteme. Galls Gesetz geht in dieselbe Richtung: https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law
  • Ich denke, der Qualitätsrückgang bei IT-Fachkräften hat vollständig mit der Generation zu tun, die in die Softwarebranche gegangen ist, weil man dort viel Geld verdienen kann. Das ist nachvollziehbar, aber oft ist die Vergütung die Motivation, nicht die Leidenschaft für Software; im Allgemeinen sind es technisch durchschnittliche Leute, die wiederum dazu neigen, andere durchschnittliche Techniker einzustellen.
    Wenn man sich dagegen die neu entstehenden Startups ansieht, gibt es dort immer mehr wirklich talentierte Leute. In einem Umfeld mit knapperem Kapital braucht man echte Könner, um ein Unternehmen zu gründen, und diese Leute stellen wiederum hervorragende Leute ein.
    Die heutige Tech-Branche fühlt sich viel stärker wie die Zeit um 2004–2008 an, als fast alle, die sich für Startups interessierten, einstiegen, weil sie es mochten, technische Probleme zu hacken.
    Nach meiner Erfahrung mit Cursor ist es großartig für Dinge, die ein durchschnittlicher Engineer erledigen kann, aber miserabel bei anspruchsvolleren Aufgaben; außerdem braucht man die Fähigkeit, fremden Code sehr schnell zu verstehen.
    Wahrscheinlich wird es dazu führen, dass fortgeschrittene technische Engineers, die sich nicht auf Frontend- oder Web-App-Entwicklung konzentrieren, nicht mehr so viele Junior-Webentwickler einstellen müssen wie früher. Ähnlich wie Webmaster verschwanden, als Frameworks und Tools aufkamen, mit denen sich grundlegendes HTML/CSS für Webseiten schnell erstellen ließ.
  • Dieses Phänomen betrifft nicht nur IT-Arbeitende, sondern passiert insgesamt, und ich sehe darin einen Hauptgrund, warum die von der Technologie versprochenen Produktivitätssteigerungen nicht Realität geworden sind.
    Nehmen wir an, „DevSecOps“-Leute machen das Dreifache dessen, was sie eigentlich tun sollten; dann muss man auch betrachten, was sie sonst noch machen. Sie buchen vielleicht Reisen, rechnen Ausgaben ab und erstellen Berichte, ordnen ihre Arbeitszeit nach Geschäftskategorien zu, verwalten Urlaub, organisieren Meetings, bauen Präsentationen mit selbst erstellten Grafiken und erledigen bis zu 80 % der Vorbereitung für den Einkauf bei externen Dienstleistern.
    Diese Dinge stehen nicht in der Stellenbeschreibung, stören die eigentliche Arbeit und zehren überproportional an der Fähigkeit, den Kernjob zu erledigen. Früher gab es für jede dieser Aufgaben dedizierte Fachkräfte, die sie viel günstiger und mit zehnfacher Effizienz erledigen konnten.
    Spezialisten wie Sekretariate, interne Grafikabteilungen oder Finanzmitarbeiter tauchten in der Bilanz auf. Wenn man diese Rollen abschafft, verschwindet die Arbeit nicht; sie wird nur unter dem Vorwand, Self-Service-Bürosoftware verbessere die „Produktivität“, stückweise auf alle verteilt.
    Das Ergebnis ist, dass alle unverhältnismäßig langsamer werden, aber Menschen, die nur auf Zahlen schauen, sehen nur das eingesparte Gehalt der abgeschafften Rollen. Die Verlangsamung zeigt sich nur als vages, allgemeines Gefühl sinkender Produktivität, wie eine mysteriöse Kostenkrankheit, die alle betrifft.
    Ich halte das nicht für mysteriös: Es gibt keine Produktivitätssteigerung, sondern im Gegenteil Verluste. Nur weil klare, sichtbare Kosten in verteilte und schwer zu berechnende Kosten umgewandelt werden, ist es leicht, sich einzubilden, man spare Geld.
  • Unternehmen erkennen zwar, dass es 10x-Entwickler gibt, glauben aber, sie könnten sie zum Gehalt eines 1x-Entwicklers einstellen.
    Die entscheidende fehlende Fähigkeit ist das Verständnis für das Geschäft, in dem das Unternehmen tätig ist. Selbst moderate Entwicklungsfähigkeiten können in Kombination mit einem guten Verständnis der Geschäftsziele weiterhin wertvoll sein, während einige reine Entwickler durch KI ersetzt werden.
  • Das wird nicht aufhören. Die typischen Topmanager mit echter Macht haben keinerlei Ahnung von IT-Komplexität und sehen uns eher als teure Hausmeister. Das ist ihr Fehler, aber wenn dieser Fehler vollständig sichtbar wird, sind sie meistens wahrscheinlich schon weg.
    In 13 Jahren bei einem Unternehmen im Bankensektor habe ich gesehen, wie die Komplexität massiv zunahm und zugleich die absurde Bürokratie wuchs. Ich kann die notwendigen Arbeiten immer noch erledigen, habe aber keinen Zugriff. Und ich kann ihn auch nicht bekommen.
    Eine einfache Aufgabe ist inzwischen zu einer zehnschrittigen Verhandlung mit irgendeinem Pune-Team geworden; man muss zehnmal nachfassen und eskalieren, bis sie überhaupt erkennen, dass sie tatsächlich etwas zu tun haben.
    Die Prozesse sind lächerlich geworden: Wenn man etwas startet, weiß man nicht, ob es zwei Tage oder drei Monate dauert. Jede App geht ziemlich schnell kaputt, wenn sie nicht kontinuierlich gewartet wird – wegen neuer Netzwerkaufgaben, ungeprüfter Unix-Updates oder einer von zahllosen Dingen, die zwangsläufig passieren.
    Am Ende haben sich Papierprozessoren und Leute, die auch in ihrem eigentlichen Job nur durchschnittlich sind, tief in den Prozess eingegraben und gewonnen; die Fachbereiche bekommen minderwertige IT, Projekte verzögern sich und überschreiten das Budget. Das verfestigt nur noch stärker das Bild von IT als „schlechtem, aber notwendigem Übel“.
    Inzwischen ist es mir egal; Arbeit reicht als Mittel zum Leben. Mein Fokus und meine Erfüllung liegen auf dieser „Leben“-Seite.

• Entscheidend ist, was man misst. Diese Studie hat nur die Copilot-Nutzung betrachtet.
  Ich bin ein erfahrener Engineer, und Copilot ist für mich nicht nur nutzlos, sondern sogar hinderlich. Die meiste Zeit verbringe ich damit, die Problemdomäne zu verstehen, die Einschränkungen und Möglichkeiten der Umgebung zu erfassen, in der ich arbeite, und über den Code nachzudenken, den ich schreiben will.
  Wenn ich tatsächlich anfange, Code zu tippen, weiß ich bereits, was ich schreiben will; die „hilfreichen“ Autocompletions von Copilot lenken dann nur ab. Sie machen meinen Workflow deutlich schlechter.
  Umgekehrt ist AI in den Phasen vor dem eigentlichen Coden enorm nützlich. Manchmal kann man allein mit einem gut formulierten Prompt auf Basis der vorherigen Überlegungen einen Entwurf bekommen, und danach ist es sehr hilfreich, mit einem LLM zusammenzuarbeiten, um schnell Antworten auf kleinere unerwartete Probleme zu erhalten.
  Daher glaube ich — anders als dieser Bericht —, dass erfahrene Entwickler, wenn sie AI gut einsetzen, sogar größere Vorteile haben können als unerfahrene Entwickler.

  • Copilot ist nicht besonders nützlich. Im besten Fall liefert es kleine Code-Schnipsel, die richtig oder falsch sein können, und größere Codeblöcke funktionieren selten von Anfang an.
    Mit Claude Sonnet 3.5 zusammen mit Cursor oder Continue.dev wird es aber dramatisch besser. Man kann den Kontext explizit steuern, zum Beispiel 6 bis 7 Dateien auswählen und einspeisen, und zusammen mit Claudes starken Fähigkeiten verändert das die Lage komplett.
    Je nach Aufgabe wird man leicht 2- bis 5-mal schneller. Dinge, die sonst einen halben Tag dauern könnten, lassen sich in unter einer Stunde als 100 Zeilen produktionsreifer Code inklusive Tests umsetzen.
    Das sage ich mit 26 Jahren Erfahrung und seit 2012 in Principal-/Staff-/Lead-Rollen. Bei Erfahrung unterhalb von Senior-Level würde ich dieselbe Verbesserung allerdings nicht erwarten. Denn man muss ziemlich detailliert erklären, was man will, und nimmt meist eine zunächst funktionierende Lösung, um sie etwa ein halbes Dutzend Mal zu verfeinern, bis sie ideal und sauber zerlegt ist.
  • Für mich fühlt sich AI wie ein Werkzeug an, das Dokumentation und Suche beschleunigt. Es gibt viele kleine Dinge, bei denen ich genau weiß, was ich tun will, mich aber nicht an die Syntax oder Verwendung erinnere.
    Wenn ich zum Beispiel IaC für AWS schreibe, gibt es viel nachzuschlagen. Frage ich AI, bekomme ich sehr schnell Antworten und Beispiele. Wenn ich IaC für einen neuen Service lerne, würde ich die AWS-Dokumentation lesen; brauche ich aber nur eine schnelle Antwort oder eine Auffrischung, ist AI deutlich schneller.
  • Eine Gegenposition wäre: Copilot belohnt meiner Ansicht nach Pattern-Schreiben, bei dem es später anhand der Methodensignatur ganze Funktionen schreiben kann.
    Je stärker man sich auf funktionale Patterns stützt, Monaden entwirft, Ein- und Ausgabe nur an den Grenzen macht und fluent programming nutzt, desto größer ist der Effekt.
    Zur Einordnung: Das ist meine Erfahrung mit Java. Ich nutze Java seit 3,5 Jahren und verlasse mich stark auf Java-8+-Features. Wenn man in Bibliothekscode viele Generics verwendet, hat ein LLM mehr Spielraum, konsistent die richtige Wahl zu treffen.
    Bei schnellerem, groberem Design sieht man diese Vorteile nicht im selben Maß. Ich würde gern mehr von Nutzern echter funktionaler Programmiersprachen wie Haskell, OCaml, F# oder Scala hören.
  • Ich habe die Testversion von Copilot ausprobiert, musste aber warten und analysieren, was herauskommt, dann das meiste verwerfen und es mit meiner eigenen Implementierung neu bauen. Mir wurde schnell klar, dass es Zeitverschwendung ist.
    Für Boilerplate bei Unit-Tests, insbesondere tabellengetriebenen Tests, war es nützlich, aber nicht genug, um ein kostenpflichtiges Abo zu behalten.
  • Meine Erfahrung ist ähnlich. Bei der Arbeit habe ich Zugriff darauf, habe es aber zuletzt ausgeschaltet, weil es beim Konzentrieren zu viel Lärm gemacht hat.
    Sehr wertvoll war es, wenn ich in einer Sprache gearbeitet habe, mit der ich nicht vertraut bin, oder bei repetitiven Aufgaben, bei denen ich leicht beurteilen konnte, ob der generierte Code in Ordnung ist.
    Schwächer wird es dagegen, wenn mir sehr klar ist, was ich tun will, und es einer Standardimplementierung ähnelt, aber etwas Neueres ist. Bei „reduce“ oder vageren Abläufen passiert das häufig.
    Als Platform Engineer wechsle ich zwischen vielen Bereichen wie Bash, Python, Browser, purem JS, TS, Node, GitHub Actions, Jenkins-Java-Workflows und Docker; beim Wechsel zwischen diesen Domänen hilft es, das Gehirn zu entlasten und warm zu werden.

• Ich frage mich, ob die Studie auch die technischen Schulden berücksichtigt hat, die weniger erfahrene Entwickler mit AI-Beiträgen erzeugt haben und die anschließend von erfahreneren Entwicklern bereinigt werden mussten. Denn genau so etwas habe ich persönlich bei einem der in der Studie genannten Unternehmen häufig erlebt.
  Außerdem habe ich selbst gesehen, dass Entwickler, die sich weniger für die Technik selbst interessieren, aber stark für die Lieferung von Ergebnissen, deutlich mehr Interesse an AI zeigen. PMs mögen solche Leute zwar, aber

  • Das frage ich mich auch. Ich musste inzwischen mehrere PRs reviewen, in denen Methoden ganz offensichtlich von AI ohne irgendeinen guten Grund komplett umgeschrieben wurden. Wenn man fragt, warum sie geändert wurden, herrscht buchstäblich Schweigen; stattdessen wird die Frage ignoriert und nur erklärt, was wir ursprünglich angefordert hatten. Es war klar, dass sie nicht wussten, was tatsächlich im PR enthalten war.
    Angefordert hatten wir eine kleine Änderung von etwa fünf Zeilen plus Tests. Stattdessen haben wir nun nicht nur neue Schulden, sondern auch Code, bei dem niemand erklären kann, warum er komplett verändert wurde; teils Code, der nur um der Änderung willen geändert wurde, und außerdem Code, der denjenigen, die ihn pflegen, völlig fremd vorkommt.
    Das sehe ich immer wieder bei Nutzern solcher Tools, die keine Senior Engineers sind. Am Ende lehnt man solche PRs ab und sagt, sie sollen es noch einmal machen, und der vermeintliche Zeitgewinn vom Anfang ist weg.
    Das heißt nicht, dass diese Tools nutzlos sind, aber die Leute verwenden sie, ohne zu verstehen, was der Output ist, und ohne die langfristigen Auswirkungen auf die Codebase zu verstehen.
  • Die Formulierung „Entwickler, die sich nicht besonders für Technik interessieren, aber stark für Lieferung, interessieren sich mehr für AI“ beschreibt genau das, was ich schon länger zu erklären versuche.
    Der Tag, an dem ich einen Teil meiner Seele verlor, war, als ich einen Entwickler fragte, ob ich ihm Feedback zum DB-Schema geben dürfe, er zustimmte und mich dann nach ein paar Minuten mit „Ja, X interessiert mich nicht besonders“ abwürgte.
    Nicht interessiert? Ich erkläre dir als Fachexperte, was verbessert werden kann, wie es verbessert werden sollte und warum, und du bist nicht interessiert?
    Cloud war ein Fehler. Sie hat den Leuten die Vorstellung vermittelt, dass man jederzeit scale up/out machen kann und deshalb Effizienz und Optimierung nicht anstreben muss. Ich rede nicht von Microbenchmarks, sondern von ganz einfachen Dingen wie „Wäre es nicht besser, diese Datenstruktur statt jener zu verwenden?“
  • Vorab: Ich arbeite bei einem Unternehmen, das Coding-AI verkauft.
    Wir nutzen sie auch intern, und ich halte technische Schulden für eine riesige, nicht richtig eingeschätzte Bedrohung.
    Sie ist sehr nützlich, um massenhaft ungewohnte APIs und Patterns auf Code anzuwenden, aber wenn man nicht vorsichtig ist, führt das zu enormer Code-Duplizierung und schwer handhabbarer Boilerplate.
    Der Grund sind zwei große Verzerrungen. Erstens bestehen die Trainingsdaten der Modelle aus StackOverflow-artigen Beispielen und berücksichtigen weder Kontext noch Einschränkungen. Zweitens tendieren sie dazu, eine bestehende Codebase anzuschauen und dann zu kopieren und zu wiederholen, statt Refactorings vorzuschlagen.
    Das Erste lässt sich abmildern, indem man letztlich seinen Job macht und das, was das LLM ausgibt, reviewt und editiert.
    Das Zweite ließe sich nur abmildern, wenn Diffs und Commit-Historien in die Trainingsdaten einfließen, aber dieser Datensatz ist viel schwieriger zu verarbeiten und zu taggen. Manche Änderungen sind gute Refactorings, andere können Bugs sein, die in späteren Commits behoben werden, und Commit-Messages sind praktisch Lügen, sodass es keine klare Abgrenzung gibt. Niemand schreibt „Bug eingeführt“.
    Außerdem verändern oder entfernen Merge, Rebase und Squash die Bedeutung der Historie oder fügen Rauschen hinzu, wodurch alles noch unschärfer wird.
  • Fast alle Entwickler, die AI mögen und die ich kenne, waren schon vor AI Leute, die ich technisch nicht besonders respektiert habe. Sie haben die Arbeit irgendwie erledigt, aber es fehlte an Handwerkskunst oder Qualität.
  • So habe ich es auch empfunden, aber ich habe auch das Gegenteil gesehen. Auch hier auf HN gibt es Leute mit technischem Interesse, die dem Einsatz von AI fast ablehnend gegenüberstehen.
    Ich mag Technik und schreibe auch zum Spaß Software, aber mit AI zu arbeiten ist objektiv unterhaltsamer. Die Produktivität steigt viel stärker, und vor allem verschwindet das Aufschieben.
    Wenn ich feststecke oder keine Lust habe, mit einer Aufgabe anzufangen, beginne ich ein Gespräch mit Aider, und ehe ich mich versehe, ist eine Aufgabe erledigt, die ich an diesem Tag ohne AI nicht gemacht hätte.
    Dadurch veröffentliche ich öffentliche und private Projekte, die früher Monate bis Jahre gedauert hätten, inzwischen alle zwei Wochen. Es ist, als hätte man ein schnelles, erfahrenes Entwicklerteam neben sich sitzen, zu Kosten von höchstens ein paar Dollar pro Tag.

• Bevor man Schlussfolgerungen zieht, muss man sich das Paper etwas genauer ansehen. Die Studie selbst hätte ihre Ergebnisse wohl besser zusammenfassen können.
  Abstract und Fazit nennen als Ergebnis nur eine einzige Quote: 26,08 % Produktivitätssteigerung; das wirkt mit zu vielen Nachkommastellen. Schaut man etwas genauer hin, findet man Werte von 27–39 % für Juniors und 8–13 % für Seniors.
  Noch genauer betrachtet gibt es nicht nur nach Berufserfahrung, sondern auch je nach Unternehmen große Abweichungen. Bei Microsoft scheinen neben Pull Requests andere Ergebniskennzahlen wie Commits, Builds und Build-Erfolgsquote statistisch nicht signifikant zu sein. Der PR-Anstieg wirkt bei Microsoft signifikant, bei Accenture aber offenbar nicht, und selbst dort möglicherweise nur bei Juniors.
  Abstract und Fazit müssen zwar zusammenfassen, aber die Ergebnisse unterscheiden sich je nach Variable so stark, dass ich nicht weiß, ob es sinnvoll ist, eine einzelne Gesamtzahl als Zusammenfassung anzugeben. Vor allem, weil die statistische Signifikanz ziemlich uneinheitlich zu sein scheint.

  • Um besser zu verstehen, wie dieses Ergebnis zustande kam, sollte man es so betrachten: Microsoft hat eine Studie zur Nutzung des eigenen internen Produkts durchgeführt und wollte dessen Wirksamkeit zeigen. Die Ergebnisse waren nicht so breit erfolgreich wie erhofft.
    Accenture ist ein Unternehmen, das mit großen Organisationen wie Microsoft zusammenarbeitet und gemeinsames Marketing betreibt. Der Pool von etwa 300 Entwicklern bewegt die Gesamtstichprobe kaum, und da das Unternehmen Marketing-/Consulting-Abteilungen rund um AI-Workflows aufbaut, ist es schwer, Objektivität anzunehmen.
    Das dritte, anonyme Unternehmen war tatsächlich kein randomisiertes kontrolliertes Experiment, daher ist schwer zu sagen, wie man dessen Ergebnisse mit den RCTs zusammenführen sollte. Außerdem dürfte es unter den großen Tech-Unternehmen weitere gegeben haben, die ähnliche Experimente durchgeführt und die Wirksamkeit kennenlernen wollten; man kann also annehmen, dass es außer den in den Ergebnissen enthaltenen Daten noch weitere Daten gibt.
    Warum wurden aus einer größeren Stichprobengesamtheit gerade diese Unternehmen ausgewählt? Vermutlich, weil Microsoft und Accenture einen Anreiz zur Einführung haben und das dritte Unternehmen wegen p-hacking ausgewählt wurde.
    Besonders der Satz im Abstract „each individual experiment is noisy, but pooled across three experiments“ ist ein sehr schlechtes Signal. Das ist faktisch das Eingeständnis, dass die einzelnen Unternehmen für sich genommen keine statistisch signifikanten Ergebnisse liefern, es aber signifikant wird, wenn man diese drei Gruppen zusammenlegt. Das ist keine Wissenschaft.
  • Bei einer Zahl wie 26,08 % werde ich sofort misstrauisch, wenn in einer Studie außerhalb von Bereichen wie der Physik Werte bis auf die zweite Nachkommastelle angegeben werden.
  • Persönlich habe ich den Eindruck, dass ein Teil des Unterschieds daher kommt, dass Senior-Entwickler ihre Erfahrung mit Code Reviews und Tests auf generierten Code anwenden. Deshalb verlangen sie Änderungen, lehnen schlechte Generierungen ab und verbringen mehr Zeit damit, Tests zu implementieren, um sicherzustellen, dass neuer Code oder Refactorings wie erwartet funktionieren.
    Junior-Entwickler bearbeiten möglicherweise Aufgaben, die für LLMs leicht zu treffen sind, oder machen den Fehler, den ersten Entwurf zu akzeptieren, nur weil er wie LGTM aussieht, wodurch ihr Durchsatz höher erscheinen kann.
    Auch der Einsatz von Codegenerierungsmodellen erfordert Können, und dieses Können ist dasselbe, das man braucht, wenn man Arbeit an andere delegiert und Lösungen mehrerer Autoren zu einem kohärenten System integriert.

• Es ist nur mein Bauchgefühl, aber ich halte LLM-gestütztes Coding für schädlich für die Entwicklung als Entwickler. Es kann die Produktivität vermutlich nur bis zu einem gewissen Niveau steigern; dieses Niveau mag für Seniors langweilige Wiederholung sein, für Juniors ist es aber Teil der Ausbildung.
  Meiner Erfahrung nach werden LLMs nicht nur für einfachen Boilerplate-Code genutzt, sondern auch dann aufgerufen, wenn Junior-Entwickler vor ziemlich alltäglichen Aufgaben stehen, die sie noch nicht ausreichend verstehen. Der Prozess des Experimentierens, Lernens und Verstehens wird weitgehend durch das LLM ersetzt, und die eigentliche Fähigkeit wird dann, Prompts so lange anzupassen, bis etwas so aussieht, als würde es funktionieren.

  • Für mich ist es ein unglaublich gutes Lernwerkzeug. Mit Chat-Tools lerne ich breiter und tiefer. Sie sind hervorragende Gesprächspartner, um Themen zu erkunden und zusätzliche Materialien zu finden.
    Gestern Abend habe ich zum ersten Mal Linux RAID eingerichtet. Es ist nicht extrem schwierig, aber man braucht mehrere Tools wie mount, umount, fstab, blkid, mdadm, fdisk, lsblk, mkfs usw., und unterwegs kann der Ablauf von den exakten Schritten eines Guides abweichen, sodass nur Tutorials oder Dokumentation zu lesen nicht besonders hilfreich ist.
    Ich habe zu jedem Tool und jedem Schritt Dutzende Fragen gestellt; früher hätte ich es wahrscheinlich einfach kopiert, eingefügt und gebetet.
    Vor zwei Tagen habe ich außerdem mithilfe von ChatGPT gelernt und geschafft, alle Daten von einer defekten SSD wiederherzustellen. Selbst wenn 20 % falsch sein können, war es wirklich gut, sich mit einer völlig neuen Technik zu beschäftigen und dabei einen „Guide“ zu haben, der deutlich besser ist als der Durchschnitt des offenen Internets.
    Für Menschen, die gern lernen, fühlt es sich im Vergleich zum endlosen Durchwühlen von Internetmüll wie Siebenmeilenstiefel an. Natürlich muss man, wie bei allem anderen im Internet, auch das anzweifeln, was AI sagt, aber es reduziert den Aufwand enorm.
  • Ich hatte wirklich gehofft, dass diese Studie solche Aspekte behandelt. Tatsächlich betrachtet sie nur kurzfristige Produktivitätsgewinne, ignoriert langfristige technische Schulden und blendet den Einfluss auf die Entwicklung von Softwareentwicklern vollständig aus.
    Ich habe dasselbe Bauchgefühl, und ich würde es sogar eine starke, begründete Meinung nennen. Ich denke, die Branche wird in ein paar Jahren den Preis dafür zahlen.
    Die Pipeline für „Junior-Softwareentwickler mit Gespür“ wird stark austrocknen und durch eine Flut von „AI-abhängigen Junior-Softwareentwicklern“ ersetzt werden. Zwischen diesen beiden Kategorien liegt eine tiefe Schlucht.
    Natürlich hat das auch Kaskadeneffekte auf die Zahl der Middle- und Senior-Entwickler mit Gespür.
  • Ich denke, es hängt wirklich stark vom Nutzer ab. Menschen, die früher schon StackOverflow-Code eingefügt haben, bis er so aussah, als würde er funktionieren, werden auch LLMs missbrauchen.
    Wer dagegen den gesamten Code verstehen will, den er verwendet, wird wahrscheinlich die unbekannten Teile dessen recherchieren, was das LLM ausspuckt.
    Zumindest nutze ich es so. Und als Gegenbeispiel zu der Hypothese: LLMs verwenden manchmal Funktionen oder Bibliothekskomponenten, die ich nicht kannte, und sparen mir dadurch viel Zeit, wenn ich eine neue Sprache oder ein neues Toolkit lerne. Für mich beschleunigt es das Lernen eher, als es zu verlangsamen.
  • Wie alles andere kann es missbraucht werden. Es ist wie das Kopieren und Einfügen von StackOverflow, bis es funktioniert, und dann ist man fertig.
    Aber für diejenigen, die ohnehin erfolgreich sein würden, ist es ein riesiges Geschenk: als würde man eine StackOverflow-Frage stellen und eine sofortige, nicht vorwurfsvolle Antwort bekommen.
    Es wird nicht immer richtig sein, aber das war StackOverflow auch nicht. Am Ende hängt es, wie immer, vom Einzelnen ab.
  • Wenn man die Fortschritte sieht, die LLMs in den letzten zwei Jahren gezeigt haben, frage ich mich, ob die Entscheidung, wirklich tief einsteigen zu wollen, nicht eine schlechte Wette ist.
    Wie viele heutige Entwickler können noch Maschinensprache schreiben, die vor 50 Jahren praktisch unverzichtbar war, wenn man etwas bauen wollte?
    Vielleicht wird das LLM von einer weiteren Abstraktionskrücke zu einer stabilen Abstraktionssäule.

• Das Interessanteste an dieser Studie ist für mich: Wenn man nach Karrierestufe aufschlüsselt, zeigen Entwickler mit einer Betriebszugehörigkeit über dem Median keinen statistisch signifikanten Anstieg bei der schlechten Proxy-Metrik „Produktivität“. Die 95-%-Konfidenzintervalle reichen bei allen Metriken weit in den negativen Bereich und neigen nur leicht ins Positive.
  Das deckt sich mit meiner Erfahrung. Copilot ist gut darin, manche langweiligen Aufgaben zu reduzieren und das Gehirn für tiefere Fragen freizuhalten, aber es ist nicht weltverändernd in dem Sinne, wie Junior-Entwickler es beschreiben.
  Außerdem liegt es oft subtil daneben, und zwar auf eine Weise, die weniger erfahrene Entwickler leicht übersehen. Ich muss bei dem meisten, was es generiert, anhalten und nachjustieren, und weniger erfahrene Entwickler wissen wahrscheinlich nicht, wie sie solche Anpassungen vornehmen sollen.
  Nach einigen Jahren Nutzung habe ich inzwischen ein ziemlich gutes Gefühl dafür, wann ich Copilot einsetzen sollte und wann nicht; deshalb dürfte der Nettoeffekt positiv sein, aber das war nicht immer so.
  Außerdem frage ich mich, ob ein Teil des scheinbaren Rückgangs der „Produktivität“ von Senior-Entwicklern daran liegt, dass die Produktivität der Junioren im Unternehmen steigt. Wenn Junioren mehr PRs erstellen und darin mehr Fehler stecken, sodass die Review-Zeit zunimmt, kann der Produktivitätsgewinn der Seniors entsprechend schrumpfen.

• 26 % Produktivitätssteigerung passt grob zu meiner Erfahrung. Eine weitere Dimension, die man betrachten sollte, ist, ob es um neue Technologien geht oder um Technologien, mit denen man bereits vertraut ist. AI ist bei Sprachen oder Frameworks, die ich gerade lernen möchte, deutlich hilfreicher.

  • Ich würde das gern auf „Sprachen/Frameworks, die ich nicht richtig lernen will“ ausweiten.
    Ich merke mir die Eigenheiten und Fallstricke von Hilfssprachen schlecht, etwa welchen exakten Anführungszeichen-Zauber man für Bedingungen in Bash braucht. Deshalb habe ich früher kaum Bash-Skripte zur Automatisierung geschrieben und mir nur bei ausreichend häufig wiederkehrenden Aufgaben die Mühe gemacht. Dasselbe galt für JSON-Verarbeitung mit jq oder Parsing mit AWK.
    Dank LLMs schreibe ich jetzt viel mehr Bash-Skripte, und weil es so einfach geworden ist, nutze ich sie auch häufiger zur Prozessdokumentation. Was früher ein statisches Schritt-für-Schritt-README war, wird jetzt mit einem interaktiven Bash-Skript ausgeliefert, das Nutzereingaben entgegennimmt.
  • Copilot ist ziemlich gut darin, Langeweile zu reduzieren. Docstrings schreibt es zum Beispiel meist ordentlich. Aber die eigentliche geistige Arbeit des Software Engineering nimmt es einem nicht ab.
  • Kann sein. Es könnte auch daran liegen, wie flexibel Menschen je nach Karrierestufe sind.
    Im Großen und Ganzen sehe ich viele Senior-Programmierer darüber diskutieren, warum AI-Tools nicht funktionieren. Junioren benutzen sie einfach unvoreingenommen.
  • Bei der Entwicklung unseres Hauptprodukts war es nicht besonders nützlich. Es basiert zwar auf Python, nutzt aber ein eigenes Framework, daher hat CoPilot kaum Referenzcode und schlägt nicht existierende Methoden und Argumente vor, was eher zusätzliche Arbeit verursacht.
    Nützlich war es in vier Bereichen. Erstens bei Fragen zu Frameworks/Sprachen, die ich nicht oft nutze, zu denen es aber viele Beispielinhalte gibt, wie Qt oder CSS.
    Zweitens bei sehr konkreten Fragen, die ich früher über Google Search oder StackOverflow recherchiert hätte. Bei Fragen wie „Wie ermittelt man in Python unter Windows CPU- und RAM-Auslastung am effizientesten?“ verweist es eher auf Libraries oder Beispiele, statt direkt Code zum Kopieren zu erzeugen.
    Drittens bei Boilerplate-Code, den ich zwar selbst schreiben kann, der aber etwas Zeit spart und Tippfehler reduziert. Mit dem CoPilot-Plugin für PyCharm schreibe ich meine Absicht als Kommentar in die Datei, und es vervollständigt die nächsten paar Zeilen. Auch hier sind die Ergebnisse am besten, wenn es sehr kurz und konkret bleibt. Wenn es länger wird, muss man zu viel mit CoPilot iterieren, und dann lohnt es sich nicht mehr.
    Viertens als schneller Weg, Dokumentation zu durchsuchen.
    Manche sagen, es sei gut zum Schreiben von Unit-Tests, aber für mich war das nicht so. Zumindest nicht für die Art von Unit-Tests, die ich haben möchte.
    Wenn ich es beziffern müsste, würde ich sagen, dass die Produktivität um etwa 5–10 % steigt. Das ist deutlich weniger als der Unterschied zwischen Notepad und einer vollwertigen IDE wie PyCharm oder zwischen direkten git-Befehlen in der CLI und einem guten git-Client. Es ist also nur eines von vielen Produktivitätstools; „revolutionär“ würde ich es nicht nennen.
  • Ich habe einen ähnlichen Eindruck.
    Ich habe Cursor etwa 10 Tage lang in einem riesigen Ruby-on-Rails-Projekt genutzt, und diesen Stack nutze ich seit über 13 Jahren.
    Über den Produktivitätsgewinn hinaus, den GitHub Copilot bereits lieferte, habe ich nichts gewonnen. Copilots Verbesserung schätze ich auf ungefähr 25 %.
    Wenn man jedoch in einem leeren Ordner ein neues Projekt etwa mit Node.js zum ersten Mal aufsetzt, ist es geradezu unheimlich mächtig. Allein mit Prompts kann man in etwa 5 Minuten aus einem OpenAPI-Schema eine API erstellen, die Requests verarbeitet und das OpenAPI-Schema per swagger bereitstellt.
    Allerdings starte ich selten neue Projekte von Grund auf, daher werde ich wohl zu Copilot und dem normalen VSCode zurückkehren.

• Es ermöglicht Leuten, mehr PRs zu erstellen. Wow, toll. Wen interessiert das?
  Steigt die Zahl der Dinge, die die QA bestehen? Haben Dinge, die mit AI-Unterstützung erstellt wurden, nach der QA weniger entdeckte Bugs? Sind sie später leichter zu erweitern oder zu ändern, oder ist das Design starr und unflexibel?
  Ein Tool, das Entwickler in Code Monkeys mit unbekannter Qualität verwandelt, ist nicht das, wonach ich suche. Ich will Tools, die Entwicklern helfen, Bugs oder Designfehler in ihrer Arbeit zu finden, oder die ihnen helfen, gut designte Tests zu schreiben.
  Nur PRs zu zählen, sagt überhaupt nichts Nützliches aus. Es triggert eher mein Bauchgefühl, dass mehr Code pro Zeiteinheit die durchschnittliche Qualität senkt.

  • Entwickler: „Copilot, teile diesen Commit in 5 Commits auf.“
    Copilot: „Gerne, erledige ich! Hier sind die neuen Commits!“
    Senior-Entwickler: „Warum? Die Änderung ist atomar. Wenn das Management wieder dumme Metriken wie monatliche Änderungszahlen hervorholt, werde ich ihnen höflich sagen, dass sie sich verziehen sollen.“

• Das war vermutlich GPT-3.5-basierter Copilot.
  Microsoft: September 2022 bis 3. Mai 2023
  Accenture: Juli 2023 bis Dezember 2023
  Anonymes Unternehmen: Oktober 2023 bis ?
  Das GPT-4-Update für Copilot Chat war am 30. November 2023: https://github.blog/changelog/label/copilot/

  • Guter Punkt. Ich wäre sehr neugierig, wie die Ergebnisse mit Dingen wie Cursor oder bei direkter Nutzung von Claude ausgesehen hätten. Ich bin erstaunt, wie leicht man mit Claude inzwischen einfache kleine Skripte starten kann.

• Für mich hat AI die Dokumentation wiederbelebt. Neue Frameworks haben viel zu wenig Dokumentation. Die letzte gute Dokumentation waren für mich DOS-Bücher. Heutige Entwickler haben vermutlich gar kein Gefühl mehr dafür, was gute Dokumentation ist.
  Trotzdem kann AI jedes Mal andere Vorschläge machen, daher muss die Beurteilung weiterhin ein erfahrener Entwickler übernehmen. Letztlich ersetzt AI Dokumentation und Tippen.

  • Ich denke, AI hat den Wert von Dokumentation sogar erhöht.
    Bei einem öffentlichen Projekt ist die Dokumentation Teil der Trainingsdaten von LLMs geworden, daher ist es umso wichtiger, dass sie gründlich und korrekt ist. Denn viele Entwickler werden ihre Antworten aus diesem System bekommen.
    Bei einem nicht öffentlichen Projekt kann man die Dokumentation in einen Fine-Tuning-Datensatz oder ein RAG-System einspeisen und denselben Effekt erzielen.
  • Wenn auf HN gelegentlich Diskussionen wie „Wie verwaltet ihr interne Dokumentation?“ auftauchen, schreiben die meisten sinngemäß: „Dokumentation veraltet schnell, also lohnt sie sich nicht.“ In den letzten Tagen gab es sogar zwei solcher Threads.
    Das könnte erklären, warum überhaupt nichts dokumentiert wird.
  • Genau. AI kann auch beim Schreiben von Dokumentation helfen, und es wird noch besser, wenn man mit der Dokumentation beginnt. Wenn man zum Beispiel zuerst einen Kommentar schreibt, der erklärt, was eine Funktion tut, kann AI beim Schreiben der Funktion um Größenordnungen besser helfen.
    Dadurch hat sie in der Praxis auch den Effekt, Entwickler dazu zu zwingen, ihren Code besser zu dokumentieren.
  • Ich schreibe wirklich gern gute Dokumentation. Natürlich hat man nicht immer die Gelegenheit dazu, aber könntest du ein Beispiel für Dokumentation nennen, die du für hervorragend hältst?
    Es muss nicht unbedingt moderne Live-Dokumentation sein, alles ist in Ordnung. Ich möchte sehen, was früher daran so großartig war, das wir verloren haben, und einiges davon in meine eigene Dokumentation einfließen lassen.