Warum AI-Code-Review kein tragfähiges Gegenargument sein kann

• Die Lösung, dass Menschen die häufigen Fehler von LLM-Coding-Tools einfach vollständig prüfen, kann wegen der Verarbeitungsgrenzen von Code Reviews Qualität und Produktivität kaum zugleich garantieren
• Empirische Studien zeigen, dass wirksame Reviews pro Durchgang bei etwa 1 Stunde und 400 LOC gedeckelt sind; darüber sinkt die Fehlererkennung durch Ermüdung und nachlassende Konzentration schnell
• Legt man diesen Maßstab an, braucht man pro 400 von einem LLM geschriebenen LOC 1 Stunde konzentrierte Prüfung durch erfahrene Entwickler, sodass die realistische tägliche Durchsatzmenge bei unter 1.000 LOC liegen kann
• Es gibt erste Hinweise darauf, dass Menschen in von LLMs erzeugtem Code weniger Fehler finden, dabei aber stärkeres Vertrauen in ihre Beurteilung zeigen; deshalb ist kaum anzunehmen, dass Review allein Fehler zuverlässig herausfiltert
• Um die tatsächliche Wirksamkeit solcher Tools nicht nach Anekdoten, sondern anhand von Belegen zu bewerten, braucht es empirische Studien, die Fehlererkennungsrate, Review-Geschwindigkeit und nachhaltige Tagesleistung bei LLM-Code direkt messen und reproduzieren

---

Warum ich LLM-Coding-Tools skeptisch sehe

• Im Mittelpunkt des Problems stehen weder Urheberrecht, ökologische Kosten, Ressourcenverbrauch noch die Behauptung, dass alle LLM-Ergebnisse grundsätzlich schlecht seien
• Auf Basis der aktuellen wissenschaftlichen Evidenz ist schwer zu erkennen, wie LLM-Coding-Tools Entwicklern dabei helfen, Code besser oder schneller zu schreiben
• Die Befürworterseite geht auf die relevanten Probleme und Belege nicht direkt ein; manche Erwiderungen auf Skepsis verstärken das Problem sogar noch
• Der Text wurde vor etwa einem Jahr geschrieben und verwendet deshalb den heute weitgehend abgelösten Ausdruck Coding Assistants, weil sich kein anderer Begriff fand, der die verschiedenen Coding-Anwendungsfälle generativer AI vollständig abdeckt

Die „Praktikant“-Analogie und die Lösung per Vollprüfung

• LLM-Coding-Tools haben aus Gründen wie ihrer Funktionsweise und ihrer Interaktionsoberfläche ein vergleichsweise hohes Fehlerrisiko
  • Sie können Halluzinationen oder Tippfehler erzeugen
  • Sie können Ergebnisse liefern, die nichts mit der Anfrage zu tun haben, oder die Aufgabe auf einem anderen Weg bearbeiten
• Nutzer vergleichen solche Tools oft mit einem Praktikanten
  • Man müsse damit rechnen, dass das Ergebnis in gewissem Maß falsch ist
  • Man müsse davon ausgehen, dass die Arbeit erfolgt, ohne wirklich zu verstehen, was getan wird
• Eine verbreitete Reaktion ist, das Ergebnis wie den Code eines Praktikanten oder Junior-Entwicklers vollständig reviewen zu lassen
  • Das beruht auf der Annahme, dass der Mensch mehr weiß und letztlich die Verantwortung trägt
  • Hinzu kommt oft das Argument, dass jeder Code, der in die Codebasis gelangt, ohnehin reviewed werden sollte

Welches Review-Niveau für die Aufsicht über LLMs nötig ist

• In Industrie und Forschungsliteratur umfasst Review mehrere unterschiedliche Praktiken
• Leichte, auf mehrere Personen verteilte Reviews sind nützlich, um Wissen über Änderungen zu teilen und oberflächliche Regeln anzuwenden, reichen aber als Maßstab für die Aufsicht über LLM-Code nicht aus
• Es ist nicht nötig, wie bei früheren Komiteeprüfungen stundenlang jede Zeile qualvoll zu kontrollieren, aber es braucht ein deutlich tieferes und vollständigeres Code Review
• Weil LLMs komplexen Code schreiben können und sich Fehler in den Details von Software verbergen, reicht eine oberflächliche Prüfung nicht aus

Die empirischen Grenzen von Code Review

• Empirische Forschung zeigt unter anderem diese wesentlichen Grenzen wirksamer Reviews
  • Eine einzelne Review-Sitzung wird jenseits von 1 Stunde zu lang
  • In dieser Zeit lassen sich höchstens etwa 400 LOC wirksam prüfen
• Reviews von mehr als 1 Stunde verlieren unabhängig von der Codegröße schnell an Wirkung
  • Nicht nur deshalb, weil der Großteil schon geprüft wurde
  • Wer 1 Stunde lang hohe Konzentration hält, ermüdet und langweilt sich, sodass Pausen nötig werden
• Eine Studie zur nötigen Erholungszeit zwischen 1-stündigen Sitzungen konnte ich nicht finden
  • Als extremes Maximum ließen sich mehrere Sitzungen pro Tag annehmen
  • Als durchschnittlich mögliche Zahl werden etwa 2 Sitzungen pro Tag vorgeschlagen, gesichert ist das aber nicht
• Wie viele Codezeilen pro Stunde geprüft werden können, hängt stark von Kontext und Art des Codes sowie von Erfahrung und Wissen der prüfenden Person ab
• Es ist kein absoluter Maßstab, aber in den empirischen Daten gibt es kaum Fälle, in denen Reviews schneller als 400 LOC/H Fehler wirksam fanden und markierten; das lässt sich daher als praktisch wirksame Maximalgeschwindigkeit ansehen

Durchsatzrechnung für LLM-Code

• Wenn man die Probleme von LLM-Code durch Review lösen will, braucht man selbst im besten Fall pro erzeugten 400 LOC 1 Stunde eines erfahrenen Entwicklers
• Für Entwickler sind pro Woche etwa 10 bis 40 Review-Sitzungen vertretbar; zwischen den Sitzungen ist jeweils eine Erholungszeit unbekannter Länge nötig
  • Diese Erholungszeit könnte mindestens 1 bis 2 Stunden betragen, dafür gibt es aber keine direkte Studie
• Diese konzentrierte Zeit wird auch für Meetings, Design, Incident Response und das Nachdenken über selbst geschriebenen Code benötigt
• Im besten Fall kann ein Entwickler mit LLM täglich einige tausend LOC schreiben, prüfen und committen
• In realistischen Szenarien kann der Tagesdurchsatz unter 1.000 LOC liegen
  • Darin sind Boilerplate, Tests, Migrationen und Konfigurationsdateien enthalten
  • Schon eine einzelne Testdatei kann mehr als 400 LOC umfassen
• Selbst unter besten Bedingungen, in denen der meiste Code simpel und leicht zu prüfen ist, wirkt Review als Obergrenze für Produktivitätsgewinne

Unterschiede zwischen Review von menschlichem und LLM-Code

• Die bisherige Evidenz stammt aus Situationen, in denen menschliche Reviewer Fehler in von Menschen geschriebenem Code finden; es gibt keinen Beleg dafür, dass dieselbe Effizienz auch für LLM-Code gilt
• Erste Hinweise zeigen, dass Personen beim Review von LLM-generiertem Code weniger Fehler entdecken, dabei aber stärker überzeugt sind, alle Fehler gefunden zu haben
• Im Vergleich zur Kombination aus menschlichem Autor und menschlichem Reviewer könnte die Kombination aus LLM-Coding-Tool und menschlichem Reviewer zu Ergebnissen geringerer Qualität führen, während der Reviewer seine eigene Leistung höher einschätzt
• Vollständiges Review begrenzt also nicht nur den Produktivitätsvorteil von LLMs, sondern es fehlt auch an klarer Evidenz dafür, dass damit die häufigen Fehler tatsächlich gelöst werden

Kosten schon vor der Fehlerbehebung

• Diese Rechnung enthält nicht die Kosten der Behebung entdeckter Fehler
• Sie behandelt nur die Fähigkeit und die Kosten, mit denen professionelle Entwickler in ihrer Arbeitsumgebung Code prüfen und Probleme markieren
• Unabhängig von Anzahl und Schwere der von LLMs erzeugten Fehler entstehen Kosten allein durch das Prüfen des generierten Codes
• Selbst wenn LLM-Coding-Tools sehr hochwertigen Code erzeugen würden, blieben unter der Bedingung, dass alle Ergebnisse geprüft werden müssen, dieselben Kosten und Produktivitätsgrenzen bestehen

Der Widerspruch, schwer prüfbaren Code zu delegieren

• Befürworter von LLMs nennen es als Vorteil, dass solche Tools Code erzeugen können, den Menschen nur ungern selbst schreiben
• Ein Beispiel schlägt vor, künftig 100 % des benötigten Bash-Codes von einem LLM schreiben zu lassen
• Shell-Skripte haben lockeres Parsing und überlappende Bedeutungsebenen; ein Tippfehler in einem einzelnen Satzzeichen kann harmlos sein oder den gesamten Computer löschen
• Solcher Code ist fehleranfällig, schwer zu verstehen und schwer zu prüfen, und selbst fatale Fehler lassen sich nur schwer erkennen
• Dem Tool, das zufällig Fehler produziert, gerade den am schwersten prüfbaren Code zu überlassen und dann auf menschliche Kontrolle zu verweisen, belegt noch nicht, dass LLM-Ausgaben überhaupt wirksam reviewt werden können
• Problematisch ist, dass am schwersten zu prüfender Code als repräsentativer Anwendungsfall dient, ohne zu beantworten, ob Review Fehler tatsächlich löst und ob dann noch genug Produktivitätsgewinn übrig bleibt

Empirische Fragen, die überprüft werden müssen

• Die erste Aufgabe besteht darin zu messen, wie gut menschliche Reviewer Fehler in LLM-generiertem Code finden
  • Fähigkeit zur Fehlererkennung
  • Review-Geschwindigkeit
  • nachhaltig leistbare Review-Menge pro Tag
• Wie bei Studien zu menschlich geschriebenem Code braucht es Daten darüber, wie Menschen LLM-Code reviewen
• Bestehende Experimente und empirische Daten sind in Umfang und Kontext begrenzt; es braucht daher mehr Replikationsstudien
• Die aktuelle wissenschaftliche Datenlage deutet eher darauf hin, dass Menschen LLM-Ergebnisse nicht gut prüfen können oder Probleme darin schwer erkennen
  • Das könnte zu der Eigenschaft passen, dass LLMs darauf trainiert werden, Erkennung zu umgehen
  • Es muss aber auch geprüft werden, ob frühere Ergebnisse Zufall waren
• Die zweite Aufgabe besteht darin zu klären, ob das Review von LLM-Erzeugnissen qualitativ ein anderes Problem ist als das Review menschlicher Arbeit
  • Falls die Unterschiede so groß sind, dass bisherige Forschung zu Code Review nicht anwendbar ist, könnte die aktuelle Kritik in sich zusammenfallen
  • Erste Hinweise deuten jedoch eher darauf hin, dass das Review von LLM-generiertem Code schwieriger statt leichter ist; in diesem Fall würde die Kritik eher noch verstärkt

Empirische Bewertung professioneller Tools statt Anekdoten

• Wenn man berücksichtigt, was über Code Review bekannt ist, lässt sich schwer erkennen, welchen Nutzen LLM-Tools mit ihren aktuellen Interfaces und Abläufen professionellen Entwicklern bringen
• Größeren Unmut als die wiederholte Bereitstellung von Tools und Verfahren, die der Evidenz widersprechen, erzeugt die Haltung mancher Anbieter, Skeptiker als abnormal zu behandeln, statt sich mit dem Problem auseinanderzusetzen
• Bei TDD, Typsystemen, der Trennung von Test- und Entwicklungsorganisation, CI/CD und DevOps hat sich ebenfalls wiederholt gezeigt, dass Anekdoten stärker wiegen als empirische Belege
• Statt sich auf Aussagen wie „Diesmal hat es für mich funktioniert“ zu stützen, sollte man echte Forschung betreiben, nach dem Vorbild dessen, wie die empirische Basis für Code Review entstanden ist
• Wenn LLM-Coding-Tools als professionelle Entwicklungswerkzeuge gelten sollen, müssen ihre Wirkung und ihre Grenzen mit Fokus auf Ergonomie und empirische Evidenz überprüft werden

[GN⁺]

Kommentare auf Lobste.rs

• Geschwindigkeit muss nicht das einzige Ziel sein. Bugfixes lassen sich als separate vorbereitende Commits auslagern und unabhängig reviewen; Typstrukturen, die ungültige Zustände ausdrücken können, lassen sich korrigieren; und wenn das Vertrauen in Tests fehlt, kann man mit property-basierten Tests, Fuzzing und formalen Methoden experimentieren.
  Früher hat man solche Arbeiten in einen einzigen Commit gepackt oder als Technical-Debt-TODO liegen lassen, doch inzwischen sind die Grenzkosten, es richtig umzusetzen, erstaunlich niedrig geworden. Ein LLM ist ein offenes Werkzeug und liefert Nutzen in dem Maß zurück, wie der Nutzer bestimmte Werte priorisiert.
  Allerdings besteht auch das Risiko, dass mehr Prototypen entstehen, die nie fertig werden und nie in den Betrieb gelangen; insgesamt ist es aber eine große Hilfe für Engineering, das Wert auf Strenge legt.

  • Ich stimme dieser Einschätzung stark zu, habe aber das Gefühl, dass in den meisten Unternehmen in der Praxis etwas anderes passiert. Obwohl LLMs die Strenge erhöhen können, werden sie häufig für einen Wettlauf um MVPs mit Minimalqualität eingesetzt.
    Das mag ein Problem der Unternehmenskultur sein, ist aber enttäuschend; ich hoffe, dass die Branche zur Besinnung kommt und Software mit höherer Qualität baut.

• Wenn man einen Agenten mit einem einzigen Prompt auf frühere Projekte loslässt, findet er ohne großen Aufwand immer wieder echte Bugs. Menschen sind ebenfalls nachlässig, und auch ich mache Fehler; LLMs sind jedoch schnell und in vielerlei Hinsicht dümmer, sodass das Problem nur früher sichtbar wird.
  Fehler kumulieren sich, daher geht es schnell schief, wenn man einen Agenten blind Code ändern lässt. Aber daraus, dass eine naive Nutzung instabil ist, zu schließen, das Werkzeug selbst sei nutzlos, ist ebenfalls ein bequemes Urteil.
  Derzeit lasse ich bei jeder Änderung automatisch fünf Expert Reviews durchführen, die Architektur, Wartbarkeit, Zuverlässigkeit, Sicherheit und anderes abdecken, und strukturiere das Ganze in einem System von Designdokumenten, was die Entscheidungen des Agenten deutlich verbessert. Perfekt ist das nicht, aber besser als der naive Ansatz; und dass es noch weiter verbessert werden kann, gehört zum Reiz neuer Werkzeuge.

  • Hier ging es nur um Code-Generierung und Review, nicht um die Nutzung probabilistischer Textanalyse, um Bugmuster zu finden.

• Selbst wenn man per Prompt schneller erzeugt, kostet das Prüfen und Verstehen mehr Zeit, sodass man sich fragt, ob es nicht schneller gewesen wäre, es von Anfang an selbst zu schreiben. Schon die Entscheidung, welcher Weg besser ist, kostet Zeit und Energie, und diese Ressourcen würde ich lieber anderswo einsetzen.
  Wenn der PR-Einreicher jedoch Ownership und Verantwortung übernimmt, ist es unerheblich, ob ein LLM verwendet wurde. Wenn Qualitäts-, Korrektheits- und Konsistenzstandards erfüllt sind, kann man den schnelleren Weg wählen; die Verantwortung bleibt unverändert beim menschlichen Autor.
  Persönlich finde ich AI gut zum Lernen und um das Verständnis breiter und tiefer zu machen, aber wenn man nicht nur die Eingabezeit, sondern den gesamten Prozess betrachtet, bin ich mit selbst geschriebenem Code derzeit noch produktiver.

• Schon problematisch ist, dass der Artikel vor fast einem Jahr geschrieben wurde. In den letzten sechs Monaten, besonders in den letzten drei, ist der Nutzen der neuesten kostenpflichtigen Cloud-Modelle deutlich gestiegen.
  Wie bei den in Audit-Arbeit entwickelten MFIC-Prinzipien muss man prüfen, ob es Kontrollmechanismen gibt, die ganze Fehlerkategorien verhindern: https://gist.github.com/pmarreck/b30aa3ca69cb70a5526f8a63ab8c8d7e
  Außerdem braucht man Werkzeuge wie https://github.com/pmarreck/dirtree und https://github.com/pmarreck/codescan, die bestehenden Code und Projektstruktur im Kontext halten; das ist auch für menschliche Entwickler nützlich, die eine Codebase vergessen haben oder mit ihr nicht vertraut sind.
  Am Ende kann man das richtig nutzen und Vorteile daraus ziehen – oder weiter maßgeschneiderten Code von Hand schreiben, dabei Bugs und Sicherheitslücken produzieren und von schnelleren Wettbewerbern überholt werden. Aus der Erfahrung von zwei Personenjahren mit der eingestellten Ruby-on-Rails-Codebase von Desk.com im Umfang von einer Million Zeilen: Enterprise-Code ist vergänglich und passt daher gut zu LLM-generiertem Code.
  Bei der internen Implementierung von Erlang würde ich dem schwer vertrauen, aber man kann es funktionsweise schreiben lassen und dann reviewen; manchmal ist es besser als erwartet. Statt zwischen Stricknadeln und Webstuhl wählen zu müssen, ist es ideal, je nach Situation beides zu verwenden.

  • Auch ich arbeite nicht an internen Implementierungen, sondern an Enterprise-Code, und bin die Person, die den Code aufräumt, den LLM-Nutzer hinterlassen. Was du gerade gesagt hast, widerlegt keinen einzigen Satz des Originals, sondern stützt ihn eher.
  • Die Behauptung, in den letzten sechs oder drei Monaten habe es große Verbesserungen gegeben, wird seit mindestens zwei Jahren wiederholt.

• Nach meiner persönlichen Erfahrung und der von verlässlichen erfahrenen Entwicklern in meinem Umfeld haben LLMs wiederholt besseres und schnelleres Coden ermöglicht; daher fällt es mir schwer, einen Text ernst zu nehmen, der auf Grundlage wissenschaftlicher Evidenz behauptet, sie könnten nicht helfen.
  Auch ohne Peer-Review-Papers habe ich schon genug gesehen, und nur weil eine METR-Studie den geschätzten Produktivitätsgewinn von Entwicklern infrage stellt, werde ich mein bisheriges Urteil nicht ändern.

  • Für jemanden, der sich Forscher nennt, ist persönliche Erfahrung reicht mir ein verblüffend niedriger Evidenzstandard.
  • Persönliche Erfahrung wurde auch von Ärzten angeführt, die sich weigerten, die Hände zu waschen, oder Aderlass verteidigten. Die Wissenschaft entstand auf Grundlage einer Geschichte, in der man solchen Erfahrungen vertraute und dadurch Menschen tötete.
    Wenn man mir stringent und methodisch sauber zeigt, worin sich das hier von der bestehenden robusten empirischen Forschung unterscheidet, bin ich bereit, meine Meinung zu ändern. Aber persönliche Erfahrung oder ein Dutzend unerklärter Anekdoten reichen nicht.
    Wissenschaft und Engineering haben das Leben von Milliarden Menschen verbessert; das kann man nicht verwerfen, nur weil jemand glaubt, es besser zu wissen.
  • Du hast nach Belegen gefragt, die andere überzeugen könnten, antwortest aber, dass du selbst schon überzeugt bist und nichts weiter brauchst; damit ist die Frage nicht beantwortet.
    Ich will die Person nicht als Anhänger einer Sekte bezeichnen, aber eine Haltung, bei der Herausforderungen an den eigenen Glauben persönlich genommen werden, man zugleich aber nicht weiß, wie man andere überzeugen soll, ähnelt der Kommunikationsweise sektenartiger Gruppen.
  • Bei LLMs zur Codegenerierung bin ich noch zurückhaltend, aber ob ein PR-Autor Mensch oder Maschine ist, ist nicht wichtig; es sollten dieselben Qualitätsstandards gelten.
    Auch bei einem überwiegend mit LLM erstellten PR muss der Einreicher Verantwortung übernehmen und ihn in Kontext und Größe so aufteilen, dass andere ihn gut verstehen können. Code bleibt die endgültige Spezifikation von Software, und daran, dass Entwickler ihn besitzen und verstehen müssen, hat sich nichts geändert.

• Die Aussage, dass AI-Agenten vor einem Jahr viele Fehler gemacht haben, stimmt, aber unklar ist, ob das heute noch so ist; etwa im November letzten Jahres habe ich einen Wendepunkt bei Frontier-Modellen gespürt.
  Es stimmt, dass LLMs die Codemenge erhöhen und damit die Review-Kapazität unter neuen Druck setzen, aber Engineers müssen hier bremsen und sicherstellen, dass die Review-Menge zur tatsächlich verfügbaren Verarbeitungskapazität passt.

  • Sie machen weiterhin gravierende Architekturfehler. Zum Beispiel erkennen sie nicht, wenn man gemeinsames Verhalten extrahieren und wiederverwenden könnte, und fügen stattdessen neuen Code hinzu.
    Noch schlimmer ist, dass dieser neue Code meistens funktioniert und daher wahrscheinlich ohne Aufräumen gemergt wird.

• Ich wundere mich, dass Frontier-Modelle zwar enorme Mengen Code schreiben, aber negative Beiträge – also vorzuschlagen, Code zu entfernen – nicht ernsthaft erforscht werden. Wenn sie wie in „The Best Code is No Code At All“ – Jeff Atwood die Komplexität einer durch Abstraktionsschichten aufgeblähten Codebase entwirren und das Löschen von Zeilen vorschlagen könnten, wäre das neuartig.
  Vielleicht ist es bereits möglich, aber ich habe es selbst noch nicht gesehen.

• Zur Korrektur: Der Abschnitt „The Limits Of Reviews“ nennt als effiziente Maximalgeschwindigkeit 400 Zeilen pro Stunde, nicht 400 Zeilen pro Review, wie ich zunächst dachte.
  Allerdings interessiert mich weiterhin, aus welchem konkreten Paper zu Code Reviews die Zahlen von 1 Stunde und 400 Zeilen stammen. Wenn du den Namen des Papers nicht separat gespeichert hast, musst du nicht viel Zeit damit verbringen, es wiederzufinden.

  • Ich habe die entsprechenden Materialien irgendwo abgelegt und kann nachsehen. Die meisten nennen ein Limit von 100 bis 200 Zeilen pro Stunde, aber viele sind ältere Studien aus einer Zeit, in der Programmiersprachen fehleranfälliger waren als heute.
    Ich bin gerade auf Reisen, erinnere mich also bitte in ein paar Tagen noch einmal daran.
  • Weil mir 400 Zeilen pro Stunde fragwürdig vorkamen, habe ich es anhand meiner Arbeitsaufzeichnungen berechnet. In den letzten sechs Monaten habe ich 173 PRs mit insgesamt 139.000 geänderten Zeilen reviewt.
    Wenn Reviews 25 % einer 40-Stunden-Woche ausmachen, sind das etwa 540 Zeilen pro Stunde; bei 15 % 900 Zeilen; bei 5 % 2.700 Zeilen. Der tatsächliche Durchsatz liegt schätzungsweise bei 500 bis 1.000 Zeilen pro Stunde und damit einigermaßen nahe an der nicht belegten Zahl.

• Ich kann die Logik schwer nachvollziehen, warum AI-generierter Code stärker oder schwächer reviewt werden sollte als von Menschen geschriebener Code. Da die Freigabekriterien dieselben sind, wird er auf demselben Niveau reviewt.