CodeTaste: Can LLMs Generate Human-Level Code Refactorings?

Die Arbeit stellt mit CodeTaste einen Benchmark vor, der zeigt, dass zwar große Sprachmodelle bei detaillierten Anweisungen zuverlässig refaktorisieren können, jedoch oft scheitern, menschliche Entscheidungen für Code-Verbesserungen eigenständig zu erkennen, wobei eine „Vorschlag-dann-Implementierung"-Strategie die Ausrichtung auf menschliche Präferenzen verbessert.

Das Wesentliche

Titel: CODETASTE – Können KI-Programmierer wirklich „sauberen" Code schreiben?

Stellen Sie sich vor, Sie haben einen riesigen, chaotischen Schrank voller Kleidung. Ein neuer, sehr intelligenter Roboter (die KI) kommt herein und sortiert die Sachen. Er findet alles, was Sie brauchen, und legt es in den Schrank. Das Problem: Der Roboter ist so schnell, dass er die Kleidung einfach in den Schramm wirft, ohne sie zu falten. Es funktioniert zwar (Sie finden Ihre Hose), aber der Schrank ist jetzt ein riesiges Durcheinander, das schwer zu durchsuchen ist und bald zusammenfällt.

Das ist das aktuelle Problem mit KI-Agenten beim Programmieren: Sie können funktionierenden Code produzieren, aber dieser Code wird oft unübersichtlich, voller Doppelungen und „technischer Schulden".

Was ist CODETASTE?

Die Autoren dieses Papers haben sich gefragt: „Können diese KIs nicht nur funktionieren, sondern auch wie ein erfahrener menschlicher Entwickler den Code refaktorisieren?"

Refaktorisieren ist wie das Aufräumen und Umgestalten des Schranks, ohne die Kleidung zu verändern. Man ordnet sie neu, falte sie schön und macht den Schrank übersichtlicher, damit er in Zukunft leichter zu nutzen ist.

Um das zu testen, haben die Forscher CODETASTE entwickelt. Das ist wie ein riesiger, automatischer Testkeller für KIs.

1. Die Quelle: Sie haben 100 echte, große Aufräum-Aktionen von menschlichen Entwicklern auf GitHub gesammelt (z. B. eine ganze Bibliothek neu strukturiert).
2. Der Test: Sie geben der KI eine Aufgabe. Entweder sagen sie ihr genau, was zu tun ist (wie ein detaillierter Putzplan) oder sie sagen nur: „Mach den Schrank ordentlicher" (ein offener Auftrag).
3. Die Bewertung: Die KI darf den Code ändern. Dann prüfen zwei Dinge:
   • Funktioniert der Schrank noch? (Alle Tests bestehen).
   • Wurde wirklich aufgeräumt? (Spezielle Regeln prüfen, ob alte, schlechte Muster verschwunden und neue, gute Muster entstanden sind).

Was haben sie herausgefunden?

Die Ergebnisse sind wie eine Mischung aus „Toll!" und „Oh nein".

• Wenn die KI genau weiß, was sie tun soll (Der „Instructed"-Track):
  Hier sind die besten KIs (wie GPT-5) ziemlich gut. Wenn man ihnen sagt: „Nimm alle roten Hemden aus der linken Ecke und lege sie in die rechte", machen sie das zu 70 % richtig. Sie können komplexe Aufgaben ausführen. Aber: Sie sind teuer und brauchen viel Zeit, um das perfekt zu machen.

• Wenn die KI selbst entscheiden muss (Der „Open"-Track):
  Hier wird es kritisch. Wenn man der KI nur sagt: „Der Schrank ist unordentlich, mach was!", dann scheitern sie fast komplett.

  • Die besten KIs erreichen hier nur eine Erfolgsrate von unter 8 %.
  • Statt den ganzen Schrank neu zu ordnen, machen sie oft nur kleine, oberflächliche Dinge: Sie ändern vielleicht einen Buchstaben im Namen eines Fachs oder fügen ein kleines Etikett hinzu, aber das große Chaos bleibt bestehen.
  • Manchmal machen sie sogar Dinge, die gar nicht nötig waren, oder brechen den Schrank versehentlich.

Die Lösung: Erst planen, dann handeln

Die Forscher haben einen cleveren Trick entdeckt. Wenn man der KI sagt: „Denk erst nach und schreib einen Plan, wie du aufräumen willst, bevor du anfängst", wird sie deutlich besser.

• Es ist, als würde man dem Roboter sagen: „Mach erst eine Skizze, wie der Schrank aussehen soll, und erst dann greif zu."
• Durch dieses „Planen" verbessern sich die Ergebnisse der KIs fast verdoppelt. Sie erkennen dann eher die großen Zusammenhänge, die ein Mensch auch sehen würde.

Fazit für den Alltag

Die Botschaft ist klar: KI-Agenten sind heute schon super darin, Anweisungen zu befolgen und Code zu schreiben. Aber sie sind noch keine echten Architekten, die von sich aus wissen, wie man ein Gebäude (oder einen Code) langfristig schön und stabil hält.

Wenn wir wollen, dass KIs uns wirklich helfen, Software zu warten und zu verbessern, müssen wir ihnen helfen, zu planen und zu verstehen, warum etwas geändert werden soll, nicht nur was geändert werden soll. CODETASTE ist der erste Schritt, um KIs so zu trainieren, dass sie nicht nur funktionieren, sondern auch langfristig gute Nachbarn im Code-Schrank sind.

Technische Zusammenfassung

Hier ist eine detaillierte technische Zusammenfassung des Papers „CODETASTE: Can LLMs Generate Human-Level Code Refactorings?" auf Deutsch:

1. Problemstellung

Große Sprachmodelle (LLMs) und Coding-Agenten haben zwar Fortschritte beim Generieren funktionierenden Codes für neue Aufgaben gezeigt, neigen jedoch dazu, bei iterativen Änderungen technische Schulden, Duplizierung und architektonische Komplexität anzusammeln. Menschliche Entwickler lösen dieses Problem durch Refactoring: verhaltenserhaltende Programmtransformationen, die die Struktur und Wartbarkeit verbessern.

Das zentrale Problem ist, dass es bisher keine skalierbaren Benchmarks gibt, die bewerten können, ob Agenten:

1. Refactorings zuverlässig ausführen können.
2. Die richtigen Refactoring-Entscheidungen treffen, die menschliche Entwickler in realen Codebasen treffen würden (insbesondere wenn keine detaillierte Anleitung gegeben ist).

Bestehende Benchmarks (wie RefactorBench oder SWE-Refactor) sind oft auf kleine, einzelne Dateien beschränkt oder testen nur syntaktische Tests, nicht aber semantische Korrektheit in komplexen, mehrdateigen Umgebungen.

2. Methodik: Der CODETASTE-Benchmark

Die Autoren stellen CODETASTE vor, einen Benchmark, der aus 100 realen, komplexen Refactoring-Aufgaben besteht, die aus großen Open-Source-Repositories (GitHub) extrahiert wurden.

Datenpipeline und Datenerstellung:

• Mining: Es werden Commits aus GitHub-Archiven (2023–2025) gefiltert, die große, mehrdateige Änderungen (durchschnittlich 91,5 Dateien pro Aufgabe) beinhalten.
• Filterung: Ein dreistufiger Prozess (Keyword-Filterung, manuelle Vorprüfung, LLM-bewertete Scoring) identifiziert echte Refactorings (verhaltenserhaltend) und schließt Bugfixes oder neue Features aus.
• Aufgabengenerierung: Für jede Aufgabe werden zwei Arten von Beschreibungen generiert:
  • Instructed Track: Eine detaillierte Beschreibung des Refactorings (ähnlich einem GitHub-Issue).
  • Open Track: Eine vage, hochlevelige Anweisung, die nur den Problembereich nennt, ohne die Lösung vorzugeben.

Ausführungs- und Evaluierungsumgebung:

• Containerisierung: Jede Aufgabe wird in einem isolierten, containerisierten Environment (Ubuntu-basiert) ausgeführt, das die Test-Suite des Original-Repositories enthält.
• Statische Analyse (OpenGrep): Um die Qualität des Refactorings zu messen, werden dynamische Tests mit statischen Regeln kombiniert. Ein LLM-Agent generiert Regeln, die gewünschte (additive) und unerwünschte (reduktive) Code-Muster beschreiben. Diese Regeln nutzen symbolische Datenfluss-Reasoning, um Muster auch bei Aliasen oder komplexen Referenzen zu erkennen.
• Metriken:
  • Functional Correctness (PASS): Bestehen der Repository-Test-Suite.
  • Instruction Following Rate (IFR): Maß dafür, wie viele unerwünschte Muster entfernt und gewünschte Muster eingeführt wurden.
  • Alignment Score (A): Das Produkt aus PASS und IFR. Ein Refactoring zählt nur als erfolgreich, wenn es sowohl funktional korrekt ist als auch die intendierten strukturellen Änderungen vornimmt.

3. Wichtige Beiträge

1. CODETASTE Benchmark: Der erste Benchmark, der sich auf komplexe, mehrdateige Refactorings in realen Codebasen konzentriert und sowohl detaillierte als auch vage Anweisungen testet.
2. Hybride Evaluierung: Kombination von Test-Suites mit semantischen, datenflussbasierten statischen Analyse-Regeln, um strukturelle Korrektheit über reine Syntaxprüfung hinaus zu garantieren.
3. Zwei Evaluierungs-Tracks: Unterscheidung zwischen der Fähigkeit, Anweisungen zu befolgen (Instructed), und der Fähigkeit, autonome Refactoring-Entscheidungen zu treffen (Open).
4. Öffentliche Verfügbarkeit: Der Benchmark, die Daten, der Code und ein Leaderboard sind öffentlich zugänglich.

4. Experimentelle Ergebnisse

Die Studie evaluierte vier führende Agenten (GPT-5.2, GPT-5.1 CODEX MINI, Claude 4.5 Sonnet, Qwen3 Coder).

Instructed Track (Detaillierte Anleitung):

• Die Modelle können detaillierte Refactorings weitgehend korrekt implementieren.
• GPT-5.2 führt mit einem Alignment-Score von 69,6 %.
• Andere Modelle (Sonnet 4.5, GPT-5.1 M) liegen bei ca. 32–34 %.
• Der Hauptunterschied liegt in der Functional Correctness: GPT-5.2 erzielt 76 % Test-Pass-Rate, während andere nur ca. 43–47 % erreichen. GPT-5.2 nutzt gezielte Patches, während andere oft unsichere „Search-and-Replace"-Befehle verwenden, die Tests brechen.

Open Track (Vage Anweisung):

• Hier zeigt sich eine massive Lücke zwischen menschlicher und maschineller Leistung.
• Ohne konkrete Anleitung erreichen die Modelle kaum 8 % Alignment (GPT-5.2 im Direct-Modus: 7,7 %).
• Die Agenten neigen dazu, oberflächliche Änderungen vorzunehmen (z. B. Tippfehler korrigieren) oder „Hack"-Workarounds zu erstellen, anstatt die tiefgreifende Architektur zu verbessern.
• Plan-Strategien: Ein „Propose-then-Implement"-Ansatz (zuerst einen Plan erstellen, dann ausführen) verbessert die Ergebnisse signifikant. GPT-5.2 erreicht im Plan-Modus 14,1 % und im Oracle Multiplan-Modus (Auswahl des besten Plans durch ein Oracle) sogar 19,4 %.
• Dennoch bleiben diese Werte weit hinter menschlichen Entscheidungen zurück.

Kosten:

• GPT-5.2 ist deutlich teurer (durchschnittlich 5,17 USD pro Aufgabe im Instructed-Track), da es mehr Tests durchführt und komplexere Patches erstellt, während günstigere Modelle oft auf einfache Textersetzung setzen.

5. Bedeutung und Fazit

Das Paper zeigt, dass Coding-Agenten zwar gut darin sind, Anweisungen zu befolgen, aber noch nicht in der Lage sind, autonome Refactoring-Entscheidungen auf menschlichem Niveau zu treffen.

• Bottleneck: Die autonome Identifikation von Refactoring-Möglichkeiten und die Wahl der richtigen Transformationsstrategie ist der kritische Engpass.
• Risiko: Ohne explizite Anleitung neigen Agenten zu minimalen, unzureichenden Änderungen oder zerstören die Codebasis durch ungenaue globale Ersetzungen.
• Zukunft: CODETASTE dient als Zielgröße für das Training von Agenten, um langfristige Codequalität zu erhalten. Zukünftige Arbeiten sollten sich auf bessere Planungsmechanismen und die Integration von menschlichen Präferenzen in den Trainingsprozess konzentrieren.

Zusammenfassend beweist CODETASTE, dass wir von autonomen Software-Ingenieuren, die Code nicht nur schreiben, sondern auch qualitativ hochwertig warten und refaktorieren können, noch weit entfernt sind.