Zwölf Arten, bei AI-gestütztem Coding falschzuliegen

 (third-bit.com)
9 Punkte von GN⁺ 2 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Der Wert von AI-gestütztem Coding lässt sich nur schwer auf einfache Zahlen wie Codezeilen, Ticketzahlen oder Zufriedenheit reduzieren, und je nach Bewertungsmethode können die Schlussfolgerungen verzerrt werden
  • Codezeilen sowie Commits, Pull Requests und Ticketzahlen messen nur Aktivität; sobald sie zum Ziel werden, lassen sie sich leicht manipulieren und sagen nichts über Qualität aus
  • Akzeptanzrate und Einführungsquote sind nur Signale dafür, dass Vorschläge plausibel wirkten oder ein Tool ausgerollt wurde; sie garantieren weder Korrektheit noch Sicherheit oder Wartbarkeit
  • Spielzeugaufgaben, Vorher-Nachher-Vergleiche ohne Kontrollgruppe, Vergleiche freiwilliger Nutzer und schwache Baselines machen es schwer, LLM-Effekte von Auswahlverzerrungen zu trennen
  • Für die Beurteilung von Produktivität braucht es Metriken auf Systemebene, die Reviews, Debugging, Sicherheit, technische Schulden, Team-Engpässe und langfristige Veränderungen einbeziehen

Bewertungsgegenstand und Annahmen

  • Wenn man den Gegenwert der Abokosten von AI-gestützten Coding-Tools belegen will, können erzeugte Codezeilen, abgeschlossene Tickets und Umfragen zur Entwicklerzufriedenheit jeweils auf unterschiedliche Weise zu falschen Schlussfolgerungen führen
  • Der Kernpunkt ist nicht der Wert von LLM-gestütztem Coding an sich, sondern wie leicht man bei der Bewertung seiner Wirkung danebenliegen kann
  • Dieselbe Kritik lässt sich mit nur kleinen Anpassungen auch auf Behauptungen über agile Entwicklung, testgetriebene Entwicklung und andere Praktiken der Softwareentwicklung anwenden
  • Daraus ergibt sich die Schlussfolgerung, dass Software Engineering bei der Erforschung solcher Phänomene viel weiter wäre, wenn es Forschungsmethoden aus den Humanwissenschaften ernsthaft übernommen hätte

Falsche Produktivitätsmetriken

  • Erzeugte Codezeilen zählen

    • Codezeilen werden seit Langem als Stellvertreterkennzahl für Produktivität verwendet, weil sich diese nur schwer direkt messen lässt
    • LLMs können mehr Code erzeugen, garantieren aber keine besseren Ergebnisse
    • Ein Team, bei dem nach der Einführung von LLMs die Codezeilen pro Entwickler um 40 % steigen, hat möglicherweise nicht Produktivität gemessen, sondern Geschwätzigkeit
    • Eine Verbesserung, bei der 2.000 Zeilen verschachtelter Logik durch saubere 200 Zeilen ersetzt werden, wirkt in einer Codezeilen-Metrik wie ein Verlust
    • Mehr Code bedeutet auch mehr zu lesen, zu warten und zu debuggen; die künftige Last, die AI hinterlässt, erscheint in der Zeilenzahl nicht

  • Commits, Pull Requests und Tickets zählen

    • McKinsey schlug 2023 vor, die Produktivität einzelner Entwickler über Aktivitätszahlen wie Commits, Pull Requests und Code Reviews zu messen
    • Wie bei Goodharts Gesetz gilt: Sobald ein Messwert zum Ziel wird, taugt er nicht mehr als guter Messwert
    • Wenn die Zahl der Commits verfolgt wird, erzeugen Entwickler kleinere und mehr Commits; wenn die Zahl der Tickets verfolgt wird, werden Tickets aufgespalten
    • Die Zahlen können besser aussehen, ohne dass sich die zugrunde liegende Arbeit verbessert
    • Aktivität ist kein Output, und selbst Output wird nicht automatisch zu Wert

  • Vorschlagsakzeptanz als Qualitätssignal betrachten

    • Eine hohe Akzeptanzrate von LLM-Coding-Assistenten wird oft als Beleg für den Nutzen des Tools angeführt
    • Die Akzeptanzrate misst nur, ob erzeugter Code plausibel genug wirkte, dass ein Entwickler Tab drückt; sie misst nicht Korrektheit, Sicherheit oder Wartbarkeit
    • Entwickler unter Zeitdruck akzeptieren mehr Vorschläge, darunter auch unsichere
    • Eine Unternehmensstudie mit 400 Entwicklern bestätigte eine durchschnittliche Akzeptanzrate von 33 % und hohe Entwicklerzufriedenheit, verfolgte aber weder die Korrektheit noch die Sicherheit des akzeptierten Codes
    • Eine Metrik, die belohnt, was plausibel aussieht, ist nicht dasselbe wie eine Metrik, die belohnt, was tatsächlich gut ist

  • Einführungsquote als Erfolgsmetrik betrachten

    • Die Aussage „Wir haben eine Einführungsquote von 90 % für AI-Tools in der gesamten Engineering-Organisation erreicht“ ist ein Beschaffungs- und Rollout-Erfolg, kein Produktivitätserfolg
    • Die Einführungsquote misst nur, ob das Tool installiert und geöffnet wurde; sie sagt nichts darüber aus, ob Vorschläge nützlich sind, ob Entwickler sie unkritisch akzeptieren oder ob angenommene Vorschläge korrekt sind
    • Wenn hohe Einführungsquote und geringe Vorschlagsqualität zusammenkommen, verbringen Entwickler womöglich eher Zeit mit dem Verwalten des Tools als mit realen Vorteilen
    • In einer IBM-Studie zu AI-Coding-Assistenten für Unternehmen erzeugte das Tool häufig eine Netto-Produktivitätssteigerung, doch diese Gewinne waren nicht gleichmäßig über alle Nutzer verteilt
    • Die Einführungsquote ist leichter zu messen als der Nutzen, und genau deshalb wird sie so häufig berichtet

Fehler im Versuchsdesign

  • Künstliche Aufgaben auf Zeit

    • In der viel zitierten GitHub-Copilot-Studie erledigten Nutzer Aufgaben 55 % schneller als Nichtnutzer
    • Die Aufgabe bestand darin, in JavaScript einen HTTP-Server von Grund auf zu implementieren, das Zeitlimit lag bei 90 Minuten, und die Entwickler hatten an diesem Tag keine anderen Verpflichtungen
    • Reale Softwareentwicklung umfasst das Navigieren in großen Codebasen, die man nicht selbst geschrieben hat, das Verstehen unklarer Ticketanforderungen, Abstimmung mit Kollegen und Meetings
    • Die Geschwindigkeit bei grünen Spielzeugaufgaben sagt die Geschwindigkeit in solcher realer Arbeit nicht voraus
    • In einer randomisierten kontrollierten Studie mit erfahrenen Open-Source-Entwicklern erhöhte der Zugang zu AI-Tools entgegen den Erwartungen der Teilnehmer die Bearbeitungszeit um 19 %

  • Vorher-Nachher-Vergleiche ohne Kontrollgruppe

    • Wenn man im Januar mit LLMs beginnt und im Juni Pull Requests schneller ausgeliefert werden, kann es so aussehen, als habe das Tool gewirkt
    • Wenn im selben Zeitraum 12 Ingenieure eingestellt, die CI-Pipeline refaktoriert und der Cloud-Anbieter gewechselt wurden, lässt sich die Ursache nicht trennen
    • Ohne eine Gruppe, die das Tool nicht eingeführt hat, ist es schwer, den Effekt von LLMs von anderen gleichzeitig eingetretenen Veränderungen zu unterscheiden
    • Interne Validität braucht ein verlässliches kontrafaktisches Szenario darüber, was ohne das Tool passiert wäre

  • Nutzer und Nichtnutzer vergleichen

    • Vergleicht man Entwickler, die sich für LLM-Nutzung entschieden haben, mit denen, die das nicht getan haben, vergleicht man nicht zwei Bedingungen, sondern zwei unterschiedliche Gruppen
    • Frühadopter sind eher experimentierfreudig, mit neuen Tools vertraut und oft schon leistungsstärker als Spätadopter oder Nichtnutzer
    • Wegen Auswahlverzerrung können beobachtete Unterschiede Eigenschaften der Menschen statt Eigenschaften des Tools widerspiegeln
    • Weil diese Methode am billigsten umzusetzen ist, ist sie ein häufiger Designfehler in industriellen Berichten zur AI-Produktivität
    • Eine Längsschnittstudie, die den Copilot-Einsatz in einer großen IT-Organisation über zwei Jahre verfolgte, zeigte, dass Nutzer schon vor der Einführung des Tools dauerhaft aktiver waren als Nichtnutzer

  • AI mit „gar nichts“ vergleichen

    • Vergleicht man AI-unterstützte Entwickler mit einer Kontrollgruppe, die gar keine Tools nutzt, wählt man eine Baseline, die in der realen Arbeit nicht existiert
    • Auch Entwickler ohne LLM-Assistent nutzen Dokumentation, Kollegen und ihre eigene Zeit zum Nachdenken über Probleme
    • Die entscheidende Frage ist, ob LLM-Tools besser sind als die Alternativen, die Entwickler bereits haben, und genau solche Vergleiche werden selten durchgeführt
    • Wählt man eine schwache Baseline, sieht jedes Tool gut aus, ohne dass das etwas über den tatsächlichen Nutzen aussagt

Auslassungen im Messumfang

  • Nur die einfache Hälfte messen

    • LLMs beschleunigen die Codeerzeugung, und dieser Teil ist leicht zu messen
    • Die schwierigere Hälfte umfasst die Zeit für die Prüfung von LLM-generiertem Code, verlorene Debugging-Zeit durch selbstbewusst falsche Vorschläge, Sicherheitslücken durch plausibel wirkenden, aber unsicheren Code und technische Schulden durch ad hoc entstandene Lösungen, die das umgebende Design ignorieren
    • Studien zu von GitHub Copilot erzeugtem Code zeigten, dass ein erheblicher Teil Sicherheitslücken enthielt und dass Entwickler unter Zeitdruck unsichere Vorschläge häufiger akzeptierten
    • In einer Bewertung von fünf führenden LLMs im Jahr 2025 konnte keines der Modelle Webanwendungscode erzeugen, der industriellen Sicherheitsstandards genügte
    • Eine groß angelegte Analyse von mehr als 300.000 AI-geschriebenen Commits ergab, dass über 15 % mindestens ein Qualitätsproblem einführten, von denen fast ein Viertel langfristig in der Codebasis verblieb
    • Wenn man nur den gestiegenen Input misst und die gleichzeitig gestiegenen Kosten ignoriert, ist das keine Messung, sondern Marketing

  • Nicht das Individuum, sondern das System messen

    • Die individuelle Coding-Geschwindigkeit wird oft gemessen, weil sie am einfachsten zu erfassen ist
    • Selbst wenn AI-Tools Entwickler 30 % schneller Code schreiben lassen, war das Schreiben von Code nicht der Engpass, falls sich die Lead Time vom Ticket bis zur Produktion im Team nicht verändert
    • Wenn mehr generierter Code entsteht, muss auch mehr Code reviewt werden; erhöht AI nur die Code-Menge, nicht aber die Review-Kapazität, kann sich die Cycle Time verschlechtern
    • Empirische Forschung mit professionellen Entwicklern zeigte, dass AI-Tools den Output weniger erfahrener Beitragender steigerten, während bei Senior-Entwicklern durch AI-generierten Code die Review-Last um 6,5 % stieg und ihre eigene Produktivität um 19 % sank
    • Optimiert man nur eine Stufe der Pipeline und ignoriert den Rest, ist das kein Produktivitätsforschungsprogramm, sondern ein Versagen systemischen Denkens

Verzerrte Effekte über die Zeit

  • Entwickler fragen, ob ihre Produktivität gestiegen ist

    • Umfrageergebnisse wie „87 % der Entwickler haben das Gefühl, mit AI-Tools produktiver zu sein“ werden oft als Beleg dafür zitiert, dass das Tool funktioniert
    • Selbstberichte können aus drei Gründen systematisch in die Irre führen
    • Durch den Hawthorne-Effekt arbeiten Menschen anders, wenn sie wissen, dass sie beobachtet oder bewertet werden
    • Neue Tools erzeugen wegen ihrer Neuheit einen Neuheitseffekt, durch den man sich schneller fühlt; dieses Gefühl verschwindet meist innerhalb weniger Wochen
    • Wegen sozial erwünschter Antworttendenzen neigen Befragte dazu, Antworten zu geben, von denen sie glauben, dass die Umfrage sie hören will, besonders wenn das Management das Tool ausgewählt hat

  • Nur während des Neuheitseffekts messen

    • Wenn eine vierwöchige Studie eine Produktivitätssteigerung findet, dann hat sie auch nur eine vierwöchige Produktivitätssteigerung gefunden
    • Entwickler beschäftigen sich in der Anfangsphase stärker mit einem neuen Tool, weshalb beobachtete Ergebnisse gegenüber der langfristigen Baseline überhöht sein können
    • Die wirklich wichtigen Effekte zeigen sich nicht über Wochen, sondern über Monate
    • Kompetenzabbau bei an AI delegierter Arbeit, technische Schulden durch falsche Vorschläge und Veränderungen in der Teamzusammenarbeit erfordern langfristige Beobachtung
    • Studien, die auf das Erkennen kurzfristiger Gewinne ausgelegt sind, sagen nichts darüber aus, was nach Ende der Studie passiert
    • Eine Analyse von 807 Open-Source-Repositories nach Einführung von Cursor zeigte einen deutlichen, aber vorübergehenden Anstieg der Entwicklungsgeschwindigkeit, während Codekomplexität und Warnungen aus der statischen Analyse deutlich und dauerhaft zunahmen

Fazit für eine bessere Einordnung

  • Produktivitätsmessung lässt sich schwer auf eine einzelne Zahl oder eine leicht erfassbare Stellvertreterkennzahl reduzieren
  • Um die Wirkung von LLM-gestütztem Coding zu beurteilen, muss man neben der Geschwindigkeit beim Schreiben von Code auch Reviews, Debugging, Sicherheit, Wartbarkeit, technische Schulden, Team-Engpässe und langfristige Veränderungen betrachten
  • Ohne Kontrollgruppen, realistische Baselines, Kontrolle von Auswahlverzerrungen, langfristige Beobachtung und Metriken auf Systemebene ist es schwer, die Wirkung von AI-Tools von anderen Veränderungen zu trennen
  • Leicht messbare Werte lassen sich leicht berichten, aber sie ersetzen keine wichtigen Werte
  • Um Praktiken der Softwareentwicklung zu bewerten, muss man Forschungsmethoden aus den Humanwissenschaften ernster nehmen

Wichtige zitierte Quellen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2 시간 전
Lobste.rs-Meinungen

  • Der Autor ist einer der Gründer von Software Carpentry und beschäftigt sich daher schon lange vor dem Aufkommen von LLMs damit, wie man Software-Produktivität besser misst.
    Die zitierte METR-Studie ist aus interessanteren Gründen bemerkenswert, als man gewöhnlich annimmt. Für viele lautete die Schlagzeile: „AI hat Menschen langsamer gemacht“, und man könnte das mit dem Hinweis entkräften, dass LLMs im Stil von 2025 ja weiterhin besser werden.
    Interessanter ist jedoch, dass die nachträglichen Eigenschätzungen der Beteiligten nicht einmal in die gleiche Richtung wie die tatsächlichen Ergebnisse gingen. Darin scheint ein Faktor zu liegen, den die meisten Unternehmen ignorieren und der jede Art von Messung grundlegend erschwert.
    Nicht einmal dem vagen Gefühl, dass ein Tool Menschen produktiver macht, kann man trauen. Menschen wissen es selbst nicht.
    Die anschließende Folgestudie ist wegen Auswahlverzerrung praktisch gescheitert.

    The primary reason is that we have observed a significant increase in developers choosing not to participate in the study because they do not wish to work without AI
    Dass Entwickler sich weigern, ohne AI zu arbeiten, kann bedeuten, dass das Tool gut funktioniert. Es kann aber auch bedeuten, dass sie zunehmend davon abhängig werden und ihre Fähigkeit, schwierigere Aufgaben ohne das Tool zu bewältigen, vollständig verkümmert ist.

    • Meine Hypothese ist, dass Menschen sich bei den Teilen der Arbeit, die sie tatsächlich ungern machen, stärker auf LLMs stützen, und dass sich Zeit bei unangenehmen Aufgaben ohnehin immer viel langsamer anfühlt.

  • Die Aussage „Neue Tools fühlen sich schneller an, weil sie neu sind, und dieses Gefühl verschwindet meist nach ein paar Wochen“ scheint mir eher umgekehrt zu sein.
    Neue Tools bremsen mich immer aus, weil ich nicht an sie gewöhnt bin. Natürlich sehe ich das Potenzial, schneller zu werden, aber ich kann sie noch nicht effektiv einsetzen.

    • Es gibt noch einen verwandten Effekt. Gerade Menschen, die neue Tools freiwillig ausprobieren, sind oft so begeistert, dass sie auch außerhalb der Arbeitszeit mehr arbeiten, um die Schwächen des Tools auszugleichen.
      Das wirkt eine Zeit lang beeindruckend, verschwindet aber von selbst, sobald sie wieder zu ihrem normalen Arbeitsrhythmus zurückkehren.

  • Messen ist schwer. In gewisser Weise kann schon der Versuch, AI-gestütztes Programmieren zu messen, ein Fehler sein.
    Bei manchen Aufgaben ist ziemlich klar, dass es sie beschleunigt, und es gibt fast sicher Wege, es so einzusetzen, dass es wirklich schneller macht.
    Die wichtigere Frage ist, welche Wege das sind und was dabei verloren geht.

    • Produktivität und höhere Arbeitsgeschwindigkeit sind nicht dasselbe. Auch wenn eine Aufgabe schneller erledigt wird, hat das womöglich keinen positiven Effekt auf die Produktivität, wenn diese Aufgabe gar kein Engpass war oder wenn die Beschleunigung einen Preis hat.
      Der Originaltext behandelt das als „nur die einfache Hälfte messen“.

  • Auf die Frage „Wenn dein Manager dich nächste Woche bittet zu zeigen, dass das vom Unternehmen abonnierte AI-Coding-Tool seinen Preis wert ist, würdest du dann erzeugte Codezeilen messen oder geschlossene Tickets?“ gilt: Claude misst bereits in den Zahlungsdaten Codezeilen, Akzeptanzrate und Token-Nutzung.
    Die Zahl geschlossener Tickets wäre eher ein Maß für die Teamgeschwindigkeit, und AI-Output ist dabei nur ein Teilfaktor; Jira misst ohnehin die Sprint-Geschwindigkeit.
    Unabhängig davon lässt sich diese Frage leicht manipulieren, je nachdem, welches Ergebnis der Manager sehen will, und vermutlich geschieht genau das bereits.

  • Mir scheint, der Autor hat eine sehr wichtige Frage ausgelassen: „Welche Schäden verursacht die Nutzung von AI?“
    Ich halte diese Frage für grundlegender als alle anderen, denn Schäden sind viel leichter zu messen. Man muss nur eine Git forge betreiben und zusehen, wie die Crawler wie Haie auf Blutgeruch heranstürmen.
    Dass Scraper das gesamte Internet per DDoS angreifen, ist ein messbares Problem und für alle, die selbst hosten, gelebte Realität.
    Sind die sogenannten Vorteile von AI, die wir nicht einmal ordentlich messen können, es wert, die sehr realen Schäden durch Crawler in Kauf zu nehmen?
    Und was ist mit der Energie für den Betrieb dieser Crawler und die Verarbeitung ihrer Anfragen, den Trainingskosten, den Inferenzkosten und dem Bedarf an immer größeren Rechenzentren?
    Ich halte es für viel wichtiger zu fragen, ob diese sogenannten Vorteile von AI all das wirklich wert sind.

    • Was mich bei solchen „Wir sollten über X reden“-Debatten immer frustriert, ist, dass ich in Texten über ökologische Schäden genau das gegenteilige Argument gesehen habe.
      Dann heißt es etwa: „Selbst wenn diese Systeme keine Energie verbrauchen würden, würden sie immer noch schlechten Code erzeugen, und darüber zu sprechen ist viel wichtiger“, oder: „Warum überhaupt über Coding reden, der eigentliche Schaden liegt im Einsatz zur Überwachung“ — und so verschiebt sich die Diskussion immer weiter.