Beeinflusst Code-Sauberkeit Coding-Agenten? Eine kontrollierte Minimalpaar-Studie

 (arxiv.org)
1 Punkte von GN⁺ 3 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Die Bewertung autonomer Coding-Agenten betrachtete bislang vor allem die Erfolgsquote bei Aufgaben in festen Codebasen, doch diese Studie misst isoliert, ob die Sauberkeit des Codes selbst die Kosten für Exploration und Änderungen verändert
  • Es wurden 6 Minimalpaar-Repositories und 33 auf versteckten Tests basierende Aufgaben aufgebaut, bei denen Architektur, Abhängigkeiten und externes Verhalten gleich sind und sich nur SonarQube-Regelverstöße und kognitive Komplexität unterscheiden
  • Mit Claude Code und Claude Sonnet 4.6 wurde jede Aufgabe auf beiden Seiten jedes Repository-Paars jeweils 10-mal ausgeführt, also insgesamt 660 Experimente; der Agent wusste nicht, auf welcher Code-Variante er arbeitete
  • Die Code-Sauberkeit veränderte die Bestehensquote nicht, aber in saubererem Code sanken tokenäquivalente Metriken um 7–8 % und Datei-Wiederbesuche um 34 %
  • Nicht nur Modell oder Prompt, sondern auch der Zustand der Codebasis bleibt in der Praxis eine Variable, die Rechenkosten und Explorationseffizienz von Agenten bestimmt

Forschungsfrage und Problemstellung

  • Autonome Coding-Agenten verbreiten sich schnell
    • In einer Untersuchung von 128.018 GitHub-Projekten im Jahr 2026 wurden bereits weniger als ein Jahr nach dem ersten praxistauglichen Agent-Launch in 22–29 % der Projekte Spuren von Agentenaktivität gefunden
  • Auch die Ausführungskosten von Agenten sind nicht gering
    • In SWE-bench Verified verbraucht eine einzelne Aufgabe nach Frontier-LLM-Maßstäben im Schnitt rund 4 Millionen Tokens
    • Im Gesamtverbrauch machen Eingabe-Tokens den Großteil aus
  • Frühere Bewertungen konzentrierten sich in Benchmarks wie SWE-bench darauf, ob eine Aufgabe gelöst wurde, und neuere Arbeiten begannen zusätzlich zum Pass-Rate-Wert auch den Ressourcenverbrauch zu messen
  • Übliche Vergleiche hielten die Codebasis fest und variierten stattdessen den Agenten oder das Scaffolding
  • Diese Studie geht umgekehrt vor: Agent und Aufgabe bleiben konstant, und nur die Sauberkeit der Codebasis wird variiert

Code-Sauberkeit und Aufbau der Minimalpaare

  • Code-Sauberkeit wird als Bündel von Eigenschaften verstanden, die mit wartbarem Code zusammenhängen
    • gute Lesbarkeit
    • geringe kognitive Komplexität
    • sauber getrennte Helper
    • klare Benennungen
    • wenig toter Code, doppelte Logik und versehentliche Kopplung
  • Die Studie fixiert Code-Sauberkeit nicht über eine strenge formale Definition, sondern verwendet die Anzahl der Verstöße gegen statische Analyse-Regeln von SonarQube als lockeren Proxy
    • Verwendetes Tool ist SonarQube Cloud Enterprise Edition
    • Das Regelset ist das „default quality gate“
  • Die Minimalpaar-Repositories unterscheiden sich nur in der internen Sauberkeit und wurden so aufgebaut, dass Folgendes übereinstimmt
    • dieselbe Sprache und dasselbe Framework
    • dieselben Abhängigkeiten
    • dieselben Tests oder eine äquivalente Testabdeckung
    • dasselbe externe Verhalten
  • Verhaltensäquivalenz liegt vor, wenn bei denselben Eingaben dieselben extern beobachtbaren Ausgaben und Zustandsübergänge entstehen
    • Praktisch wurde dies verifiziert, indem dieselbe Testsuite mit derselben Abdeckung bestand oder bei nicht beobachtbaren Änderungen wie Refactorings passende Testpaare verwendet wurden

Pipeline zur Erzeugung der Minimalpaare: Slopify und Vibeclean

  • Die Minimalpaare werden in beide Richtungen erzeugt
    • Slopify macht ein sauberes Repository absichtlich unordentlicher
    • Vibeclean räumt ein unordentliches Repository auf

  • Slopify

    • Verwandelt eine saubere Codebasis in eine Version, die wirkt, als sei sie ohne Code-Review oder Linting gewachsen
    • Ziel ist kein absichtlich kaputter Code, sondern eine alternative Historie, wie sie ohne statische Analyse hätte entstehen können
    • Drei Schritte werden jeweils von einem neuen Agenten ausgeführt
      • Build: Repository bauen, Tests zum Laufen bringen und die Befehle in build instructions.md fixieren
      • Explore: Repository durchsuchen und für jedes zu transformierende Verzeichnis eine summary.md schreiben
      • Transform: Im angegebenen Verzeichnis SonarQube-Regelverstöße einführen und nach jedem Durchlauf die Tests erneut ausführen; fehlschlagende Änderungen werden verworfen
    • Um die kognitive Komplexität zu erhöhen, werden Helper inline gezogen, Logik je Pfad dupliziert, toter Code ergänzt oder einzelne Module in einer Datei zusammengeführt

  • Vibeclean

    • Bereinigt eine natürlich gewachsene Codebasis mit vielen Regelverstößen unter Beibehaltung des externen Verhaltens
    • Die Aufgabenliste des Agenten besteht aus den vom Analyzer gefundenen Issues, jeweils mit Verknüpfung zu einem Codebereich
    • Der Änderungsbereich bleibt auf die vom Analyzer markierten Probleme beschränkt; ein komplettes Redesign ist nicht das Ziel
    • Arbeitet in zwei Schritten
      • Build: Build- und Testbefehle verifizieren und in build instructions.md festhalten
      • Clean: Regelverstöße pro Modul mechanisch bereinigen und nach jedem Modul per Tests die Verhaltensäquivalenz prüfen
    • Entfernt doppelte String-Literale, löscht auskommentierten Code, ersetzt Legacy-Collection-Idiome und entfernt tote Verzweigungen
    • Wenn der Analyzer echte Large Structures meldete, wurden etwa Dispatch-Switches mit über 200 Zeilen in benannte Helper zerlegt oder aus einer 2.800-Zeilen-Klasse Persistenz-Helper extrahiert
    • Allerdings kann solches Extrahieren Komplexität eher auf mehr Methoden verteilen als sie zu beseitigen, und einige der größten Strukturen blieben als wontfix bestehen

Benchmark-Repositories und Aufgabendesign

  • Der Benchmark wurde auf Harbor framework v0.4.0 aufgebaut
  • Insgesamt wurden 6 Minimalpaar-Repositories verwendet
    • 3 Java-lastige, 3 Python-lastige
    • Einige Repositories enthalten in kleinem Umfang Code in anderen Sprachen
    • Zusammengesetzt aus 3 öffentlichen Open-Source-Repositories und 3 privaten SonarSource-Codebasen
    • Die privaten Paare dienen als Schutz gegen Auswendiglernen, falls die evaluierten LLMs auf öffentlichen Repositories trainiert wurden
  • Wichtige Kennzahlen für saubere und unordentliche Seite je Repository sind wie folgt
    • sonar-sca*: Issues 94 / 2.825, Issue-Dichte 0,73 / 20,66, Dichte kognitiver Komplexität 30,6 / 56,5
    • sonar-caas-poc*: Issues 16 / 855, Issue-Dichte 0,61 / 27,16, Dichte kognitiver Komplexität 179,8 / 218,9
    • sonarcloud-codedatalake*: Issues 199 / 1.319, Issue-Dichte 4,36 / 34,39, Dichte kognitiver Komplexität 34,0 / 216,5
    • commons-bcel: Issues 694 / 2.711, Issue-Dichte 12,60 / 49,46, Dichte kognitiver Komplexität 102,8 / 108,3
    • genie: Issues 152 / 1.262, Issue-Dichte 1,28 / 10,81, Dichte kognitiver Komplexität 22,2 / 23,5
    • ckan: Issues 1.006 / 3.632, Issue-Dichte 7,54 / 27,50, Dichte kognitiver Komplexität 69,3 / 76,5
  • Das Aufgabendesign folgt drei Regeln
    • Über Hotspots führen: Aufgaben werden so platziert, dass sie auf beiden Seiten eines Paars durch Codebereiche mit großen Unterschieden bei Issue-Dichte und kognitiver Komplexität führen
    • Extern beobachtbare Beschreibung: Es werden nur Ein-/Ausgaben und Beispielszenarien geliefert, nicht aber Datei-, Funktions- oder interne Strukturnamen
    • Tests über die öffentliche Oberfläche: Versteckte Tests werden über Schnittstellen ausgeführt, die die Anwendung Aufrufern bereitstellt, etwa CLI, HTTP-Routen oder Bibliotheks-/API-Oberflächen
  • Die Aufgabenerstellung wurde zwischen Agenten und Menschen aufgeteilt
    • Ein Agent vergleicht saubere und unordentliche Variante und erstellt eine Differenzkarte
    • Ein anderer Agent formuliert Aufgabenentwurf und Testbarkeit
    • Ein Mensch wählt plausible und interessante Entwürfe aus, bearbeitet und kuratiert sie
    • Ein dritter Agent erstellt die eigentlichen Anweisungen, versteckte Tests über die öffentliche Oberfläche und eine interne Referenzimplementierung
    • Die Referenzimplementierung muss die versteckten Tests in beiden Repositories bestehen
    • Das Repository vor der Änderung darf die versteckten Tests nicht bestehen
    • Aufgaben, die diese Bedingungen auch nach zwei Iterationen nicht erfüllen, werden von Menschen umgeschrieben oder entfernt
  • Die endgültige Zahl der Aufgaben beträgt 33 und ist in drei Tracks aufgeteilt
    • 13 kognitive Hotspot-Aufgaben: führen durch einen hochkomplexen Einzelmethoden- oder Einzelklassenbereich
    • 14 Multi-Modul-Aufgaben: erfordern Änderungen über mindestens zwei Module hinweg
    • 6 Kalibrierungsaufgaben: beide Seiten führen in demselben Bereich einfache Aufgaben aus, um zu prüfen, ob es Veränderungen unabhängig von der Sauberkeit gibt

Experimentaufbau und Messgrößen

  • Alle Experimente wurden mit Claude Code unter Nutzung des Standard-Toolsets durchgeführt
  • Die berichteten Zahlen stammen aus Läufen mit Claude Sonnet 4.6
    • Claude Haiku 4.5 wurde ebenfalls auf derselben Aufgabenmenge ausprobiert, aber wegen zu geringer Bestehensquoten aus den Hauptergebnissen ausgeschlossen, da Unterschiede im Footprint dadurch schwer lesbar waren
  • Der Agent liest nur die Aufgabenbeschreibung
    • Er erhält kein zusätzliches Priming zur Code-Sauberkeit
    • Er weiß nicht, auf welcher Seite des Minimalpaars er arbeitet
  • Jede Aufgabe wurde auf beiden Seiten eines Paars jeweils 10-mal ausgeführt
    • Gesamtzahl der Experimente: 33 × 2 × 10 = 660
  • Jeder Lauf erfolgte in einer containerisierten Sandbox
    • CPU, Speicher, Storage und Wall-Clock-Zeit sind begrenzt
    • Zugriff auf öffentliche Paket-Registries ist möglich
    • Das Basis-Image enthält je Repository Toolchain, Build-Cache und Dienste
    • Innerhalb eines Paars unterscheidet sich nur der unter /app eingehängte Source-Tree
  • Es wurden 10 Metriken aufgezeichnet
    • Bestehensquote: Anteil der Läufe, deren Endzustand die versteckten Tests besteht
    • Eingabe-Tokens: Zahl der Tokens, die das Modell über alle Turns hinweg liest; der Großteil entfällt auf Dateiinhalte und erneut übermittelte frühere Dialoge
    • Ausgabe-Tokens: gesamte Ausgabe von Modell und Unteragenten, einschließlich Prosa, Code, Spuren von Reasoning und Tool-Aufrufen
    • Zahl der Reasoning-Zeichen: Da die Anthropic API Reasoning-Tokens nicht separat ausweist, wird die Zahl der Klartextzeichen in Reasoning-Content-Blöcken gezählt
    • Anzahl Dialog-Turns: Gesamtzahl der Agent-Tool-Wechsel
    • Turns bis zum ersten Edit: Zahl der Turns bis zur ersten Dateimodifikation
    • Zeichen bis zum ersten Edit: Zahl der Dialogzeichen im selben Abschnitt
    • Zahl gelesener Dateien: eindeutige Dateien, die während eines Laufs geöffnet wurden
    • Datei-Wiederbesuche: wie oft eine bereits gelesene und bearbeitete Datei erneut gelesen wurde
    • Geänderte Zeilen: Zahl der Source-Zeilen, die der finale Patch verändert
  • Datei-Wiederbesuche treten in Abläufen wie lesen → editieren → andere Arbeit → erneut lesen auf
    • Die Studie interpretiert dies eher als Signal von Unsicherheit über frühere Edits als bloß als breite Exploration
  • Da Agent-Footprint-Metriken auch bei Wiederholungen derselben Aufgabe mit fixer Temperatur stark schwanken können, wurde ein Ausreißerfilter angewandt
    • Innerhalb jeder (Aufgabe, Seite)-Kombination wurden vor der Mittelung Läufe entfernt, die mehr als 50 % vom Median der 10 Wiederholungen abwichen
    • Tatsächlich wurden 9,7 % aller Läufe entfernt
  • Kennzahlen auf Datensatzebene wurden über die 33 Aufgaben mikro-gemittelt
    • Für jede Metrik wurden die taskweisen Mittelwerte der sauberen und unordentlichen Seite aufsummiert und daraus die relative Differenz berechnet
    • Die Bestehensquote wird ausnahmsweise als absolute Differenz in Prozentpunkten zwischen sauberer und unordentlicher Seite berichtet

Ergebnisse: Einfluss eher auf Explorationskosten als auf Erfolgsquote

  • Code-Sauberkeit erzeugt keine signifikante Veränderung der Bestehensquote des Agenten
  • In saubererem Code sinken tokenäquivalente Metriken um 7–8 %
  • Datei-Wiederbesuche gehen um 34 % zurück, was zeigt, dass sauberer Code selbst bei derselben Aufgabe Kosten des erneuten Nachlesens verringern kann
  • Damit kann Code-Sauberkeit neben Modellwahl, Harness und Prompt als eigene Achse betrachtet werden, die die Ausführungskosten von Agenten bestimmt

Verwandte Beiträge

1 Kommentare

 
GN⁺ 3 시간 전
Meinungen auf Hacker News

  • Eine interessante Forschungsfrage, aber ich bin gegenüber dem Versuchsdesign sehr skeptisch.
    Im Experiment wurden mit Opus 4.6 „verschlechterte“ bzw. „aufgeräumte“ Codebasen synthetisiert und für den relativen Vergleich verwendet.
    Noch schlimmer ist, dass nicht kontrolliert wurde, ob die Tests der Anwendung kaputtgemacht wurden.
    „Die Erfolgsquote bewertet den Endzustand des Agenten anhand von Hidden Tests, die wir für jede Aufgabe geschrieben haben. Wir prüfen nicht, ob der Agent bereits im Repository vorhandene, nicht zusammenhängende Tests kaputtgemacht hat, und selbst wenn die Lösungen auf der sauberen und der unordentlichen Seite beide die Hidden Tests bestehen, können sie sich bei nicht bewerteten Tests unterscheiden.“
    Wenn die Qualität des Endergebnisses nicht kontrolliert wird, wirken Schlussfolgerungen zum Token-Verbrauch nahezu bedeutungslos.

    • Wenn man unordentliche Projekte und gut strukturierte Projekte anhand der Zahl fehlgeschlagener Tests vergleicht, kann die Erfolgsquote von vornherein zugunsten der unordentlichen Codebase verzerrt sein, die wahrscheinlich eine geringere Testabdeckung und Robustheit hat.
      Für einen fairen Vergleich müsste man ein einzelnes Testpaket schreiben, das bei beiden Projekten jedes Paares funktioniert.
      Das heißt nicht, dass die Studie gut ist, aber da das Bestehen von Tests nicht unbedingt mit der Effektivität des Agenten zusammenhängt, kann ich diese Entscheidung nachvollziehen.
    • Selbst wenn die Schlussfolgerung trägt, ist es allenfalls der Best Case für qualitativ verschlechterten Code.
      Sie zeigt im Grunde nur eine Situation, die funktional okay wirkt, aber mehr Token kostet, um die Aufgabe abzuschließen.
    • Wenn man nicht kontrolliert, ob die Tests der Anwendung kaputtgehen, ist die Studie faktisch wertlos.
      AI-Fatigue war schon vor langer Zeit langweilig, inzwischen ist sie einfach nur noch schmerzhaft.

  • Meiner Erfahrung nach ist der Unterschied in der Agentenleistung ziemlich groß, je nachdem ob eine Codebase voller toter Code, dupliziertem Code, unerreichbarer Alternativpfade, leaky Abstractions und unausgereifter Design Patterns ist oder ob Datenflüsse klar sind und Kapselung und Struktur sauber ausfallen.
    Bei schlechtem Code mussten alle Frontier-Modelle mehrere Runden Code Review, Qualitätsprüfung und Korrekturen durchlaufen; bei gutem Code habe ich gesehen, dass es oft schon beim ersten oder zweiten Versuch passte.

    • Die oben genannten Probleme wie Entfernen von totem Code, Codeduplizierung und unerreichbarer Code werden in den meisten Sprachökosystemen schon lange durch deterministische Linter gelöst.
      Man kann LLMs Skripte ausführen lassen, die solche Punkte prüfen, und dieselben Skripte per pre-commit Hook erzwingen.
      Solche Setups konsequent in alle Codebasen einzubauen, an denen ich arbeite, hatte beim agentischen Coding den größten Effekt.
      Einen ausführlicheren Beitrag zu den verschiedenen Lintern, die ich nutze, gibt es hier: https://www.balajeerc.info/Use-Deterministic-Guardrails-for-...
    • Ich arbeite schon recht lange mit solchen Tools, und jedes Mal schien die Leistung besser zu werden, wenn man sie wie Menschen behandelt.
      Agenten können in einer sauberen Codebase gar nicht anders, als besser abzuschneiden als in einer riesigen, chaotischen Codebase.
      Das ist dasselbe wie bei gut ausgearbeiteten Spezifikationen und Zugriff auf Dokumentation.
    • Wenn ich an einer unordentlichen Codebase arbeite, fühlt es sich für mich ähnlich an.
      Irgendwann beginnen die schrecklichen Patterns auch auf mich abzufärben.
    • Ich habe dem beim Lesen zugestimmt, aber als ich darüber nachdachte, warum es sich wie ein schlechter Kommentar anfühlt, wurde mir klar: Solche anekdotischen Aussagen stehen auf der Gegenseite einer wissenschaftlichen Diskussion.
      Hier gibt es ein Paper, das versucht, die Frage zu beantworten, und anekdotische Erfahrungsberichte verzerren nur die Leser, ohne einen Wert für eine objektive Schlussfolgerung zum Problem beizutragen.
      Die nützlichste Diskussion wäre, wenn alle das Paper lesen und Methodik oder Ergebnisse kritisieren würden.
    • Das ist zwar ebenfalls eher ein Gefühl, aber ich bin so besorgt, dass ich häufig Refactoring- und Code-Aufräum-Pässe mache und sie nie auslasse; deshalb kann ich schwer sicher sagen, ob es tatsächlich einen Leistungsunterschied gibt.
      Allerdings wirken Leute, die sich darüber beschweren, dass LLMs nicht besonders gut seien, meist wie der Typ mit einer unordentlichen Codebase.

  • Ein Trick, den ich als wirksam erlebt habe, ist, bei Python zum Refactoring etwa Folgendes anzuweisen:
    „Refactore den Python-Code so, dass er pythonischer wird. Reduziere zum Beispiel Klassen und Singletons, insbesondere wenn das die Geschwindigkeit verbessert. Python-Code muss sich ohne Benchmark-Performance-Regression an den Code-Organisationsstandards orientieren, die man von populären Open-Source-Python-Paketen erwartet.“
    Für Rust-Code habe ich diese Variante ausprobiert:
    „Die Rust-Codebase in /src ist auf mehrere Dateien mit jeweils über 1.000 Zeilen angewachsen. Refactore die Rust-Codebase ohne Benchmark-Performance-Regression so, dass sie den Code-Organisationsstandards entspricht, die man von populärem Open-Source-Rust-Code erwartet.“
    Solche Prompts scheinen die Agentenleistung zu verbessern, weil sie a) den Code logisch neu strukturieren und b) Dateinamen semantische Hinweise darauf geben, wo relevanter Code liegt.
    In einer aufgeblähten Datei mit 5.000 Zeilen muss der Agent mehrere Blöcke lesen, um den relevanten Code zu finden, was ineffizient ist.
    Auch die Benchmark-Performance wird nach dem Refactoring normalerweise besser; besonders bei kompiliertem Rust könnte das Zufall sein, aber beschweren werde ich mich nicht.

    • Stimmt. Schon die Bitte an agentische Coding-Tools, die Codebase aufzuräumen, gezielt zu refactoren und SOLID-Prinzipien sowie gute Praktiken anzuwenden, bringt viele einfache Verbesserungen.
      Grundsätzlich neigen agentische Coding-Tools dazu, Code nur ungern zu löschen. Selbst wenn man sie dazu auffordert, versuchen sie mit allen Mitteln, alten Code stehen zu lassen oder zusätzliche Komplexität einzubauen, damit dieser Code weiterhin aufgerufen werden kann.
      Wenn man nur prototypisiert, ist das wirklich lästig; am Ende sammelt sich viel toter Code an und sorgt später für Verwirrung, wenn man weitere Features hinzufügen will.
      Wenn man das weiß, kann man einfach verlangen, Legacy-Code zu entfernen.
      Eine saubere Codebase motiviert die KI dazu, das Richtige zu tun. Wenn es viele Tests gibt, fügt sie beim Bauen neuer Features weitere hinzu; wenn es Dokumentation gibt, aktualisiert sie sie auch ohne gesonderte Aufforderung.
      Wenn sich Code-Harnesses verbessern, wird immer mehr davon eingebaut sein, und auch Menschen mit wenig Prompting-Erfahrung werden leichter brauchbare Ergebnisse bekommen.
    • Auch die Aufforderung, das YAGNI-Prinzip anzuwenden, scheint gut zu funktionieren, um die Codebase zu verkleinern.
      Üblicherweise lasse ich sie zuerst eine Prüfung durchführen und eine Liste von Prüfpunkten erstellen; dann gehe ich jeden Punkt gemeinsam durch und entscheide mit Ja/Nein oder schlage zusätzliche Änderungen vor.
    • Schrittweise vorzugehen ist völlig nachvollziehbar, aber so etwas auf eine beliebige produktive Codebase als Ganzes auf einmal anzuwenden, wirkt extrem riskant.
      Besonders dann, wenn es keine sorgfältigen End-to-End-Tests für das gesamte System gibt.
    • Einfach „Refactore die Codebase“ zu sagen, funktioniert auch ziemlich gut.
      Die Code-Style-Regeln habe ich ohnehin schon in CLAUDE.md abgelegt.
    • Das Wort, das du suchst, ist idiomatisch.

  • Der Ansatz einer „Agenten-Pipeline, die unordentliche Repositories aufräumt“, wirkt furchtbar und reicht für sich genommen aus, um die gesamte Studie infrage zu stellen.
    Es scheint, als sei in dieser Arbeit die Hälfte der Minimalpaare auf diese Weise erzeugt worden.
    Schlussfolgerungen, die voraussetzen, dass ein von KI „aufgeräumtes“ Repository tatsächlich eine gute Codebasis repräsentiert, würde ich überhaupt nicht vertrauen.

    • Ich bin der Erstautor. Eine Sache möchte ich klarstellen:
      „Sauberkeit“ bedeutet hier nicht, dass wir den Agenten einfach gebeten haben, besseren Code zu schreiben.
      Wir haben ihm eine Liste von 50 bis 100 Verstößen gegen Regeln statischer Analyse sowie die Anzahl der Codezeilen gegeben und ihn gebeten, diese zu beseitigen.
      Anschließend haben wir überprüft, ob die Regelverstöße behoben wurden.
      Code mit einem LLM umzuschreiben, um solche Verstöße zu entfernen, ist eine ziemlich etablierte Praxis.
      Sonars bestehender One-Shot-LLM-basierter Ansatz [1] ist seit über einem Jahr in Betrieb, und ein neuerer agentischer Ansatz [2] erledigt dieselbe Aufgabe ebenfalls ziemlich gut.
      [1] https://www.sonarsource.com/solutions/ai/ai-codefix/
      [2] https://www.sonarsource.com/products/sonarqube/remediation-a...
    • Würdest du einem sauberen Repository vertrauen, das von KI durcheinandergebracht wurde?

  • Natürlich wird es zwangsläufig einen Einfluss haben.
    Kein Modell kann eine echte Codebasis vollständig in den Kontext aufnehmen; es muss Code wie ein Mensch durchsehen.
    Es sucht und liest Dateien.
    Wenn Dateien dort liegen, wo man sie erwartet, und so benannt sind, wie ein Modell oder Mensch beim ersten Suchen danach fragen würde, findet man sie im ersten Anlauf; andernfalls braucht es tiefe Suche und mehrere Versuche.

    • Ein LLM muss nicht die gesamte Codebasis im Kontext haben.
      Es reicht, alle Pfade anzusehen, bereits bearbeitete Bereiche zu ignorieren und zum nächsten Pfad weiterzugehen.
      Das ist ziemlich ähnlich zu dem, was Entwickler tun.

  • In ähnlicher Arbeit, die am NJIT läuft, haben wir vergleichbare Ergebnisse gesehen. Wir nennen das kontextuelle Qualitätsansteckung.
    Interessant sind hier die in der Industrie häufigen realen Situationen: Codebasen mit gemischter Qualität, Codebasen, in denen Legacy-Code-Muster und neuere „gute“ Muster vermischt sind, sodass Agenten Konventionen verwechseln.
    Das Minimalpaar-Design ist tatsächlich eine der Stärken, weil es versucht, Sauberkeit von anderen Faktoren wie Struktur, Abhängigkeiten und Tests zu isolieren, statt Repositories miteinander zu vergleichen.
    Allerdings ist die Verwendung von durch LLMs erzeugtem „verschlechtertem“ Code etwas fragwürdig, weil sie weder mechanisch noch von Menschen angeleitet ist.
    Die größte Kritik ist, wie andere zu Recht angemerkt haben, die Entscheidung, nicht die gesamte Testsuite zu prüfen. Eine Behauptung zur „Verhaltensäquivalenz“ ist nur so gut wie die Tests und die Coverage.
    Die Hypothese ist aus zwei Gründen überzeugend: 1) LLMs imitieren, was sie in einer Codebasis sehen, daher ergibt „Garbage in, garbage out“ Sinn. 2) Sie passt zu dem, was viele Engineers in den letzten ein bis zwei Jahren beim Einsatz dieser Modelle intuitiv gespürt haben.
    Greenfield ist fast immer einfacher, als in eine geschäftige Codebasis einzusteigen; Chaos entsteht bei komplexer Integration und bei Systempflege für Legacy-Zwecke.

  • Selbst wenn Agenten lernen, sich durch ihre eigenen Stubs und WET Code zu schlagen: Wollen wir wirklich Codebasen, bei denen Menschen nicht mehr nachvollziehen können, was tatsächlich passiert?

    • Selbst wenn ein Agent alles übernimmt, beschreibt Englisch nur ungenau, was Code tut.
      Deshalb möchte ich persönlich zumindest, dass der Code im Code erzählt, was er tut.
    • Ich habe eher Fälle gesehen, in denen DRY zu weit getrieben wurde.
      Selbst wenn in zwei kleinen Funktionen Logik steckt, die sich in einen gemeinsamen Helper auslagern ließe, würde ein menschlicher Programmierer das manchmal nicht tun, weil er weiß, dass diese Abstraktion unsauber wäre und schon eine kleine Änderung an einer der beiden Stellen sie kaputtmachen könnte.

  • Es ist interessant, das quantifiziert zu sehen.
    Eine saubere Struktur scheint die kognitive Last sowohl für Menschen als auch für Agenten zu senken, und das erklärt, warum Benennung und Modularisierung wichtiger sind, als man vielleicht denkt.

    • Ich denke, Codequalität sollte letztlich darüber definiert werden, wie leicht Code korrekt geändert werden kann.
      Das ist schwer zu quantifizieren, aber genau das versuchen am Ende alle Codequalitätsmetriken zu erfassen.
      Aus dieser Perspektive ist das Ergebnis wenig überraschend, solange die verwendeten Codequalitätsmetriken nur halbwegs vernünftig sind.
      Wenn eine Qualitätsmetrik im Kontext von Coding-Agents gut ist, ist genau dieses Ergebnis zu erwarten.

  • Viele Tokens werden für die Code-Navigation verbraucht: Code finden, Call Sites verfolgen und genügend Kontext aufbauen, um die Aufgabe zu erledigen.
    Wenn man einem Agenten irgendeine Form von LSP-Zugriff gibt und bei einem Monorepo hierarchische Anleitung über Dateien wie AGENTS.md bereitstellt, kann man den Tokenverbrauch für die Navigation deutlich reduzieren.
    Eine verstreute Codebasis erfordert aber am Ende für jede Aufgabe irgendeine Form von Navigation.
    Und diese Navigation ist nicht nur Tokenverbrauch. Bei jedem Schritt wiederholt sich die Round-Trip-Latenz: LLM-Wartezeit, Prefill, Decoding, Ausgabe, Parsing durch den Agenten, Tool-Aufruf, Tool-Antwort und zurück zum LLM.
    Einiges davon lässt sich parallelisieren, aber in der Praxis ist das meiste sequenziell, wodurch Aufgaben erheblich langsamer werden.
    Um Agenten effizient einzusetzen, sind Lokalität und Struktur entscheidend. Das Kontextfenster ist immer begrenzt, und die Aufmerksamkeit darin ist nicht durchgehend konsistent.

  • Nach meiner Erfahrung wirkt sich alles, was Engineers beeinflusst, auch auf Agenten aus.
    Gute Abstraktionen, Methoden in angemessener Größe, gute Namen, eine prinzipientreue Struktur innerhalb von Services und zwischen Services, Unit-Tests und so weiter gehören alle dazu.
    Historisch waren diese Dinge Aufgabe von Engineers und sollten es anderen erleichtern, zum Code beizutragen.
    Jetzt erleichtern sie nicht nur anderen Menschen, sondern auch anderen Agenten, zum Code beizutragen.