Technisches Resümee: REFINE – Ein Multi-Agenten-LLM-Ansatz für evidenzgestützte Code-Refaktorisierung

Problemstellung

Obwohl Large Language Models (LLMs) starke Fähigkeiten in der Codegenerierung und -transformation aufweisen, steht ihre Anwendung auf die Software-Refaktorisierung vor erheblichen Herausforderungen. Effektive Refaktorisierung erfordert nicht nur die Modifizierung von Code zur Reduzierung von Qualitätsmängeln (Code Smells), sondern auch die Sicherstellung, dass Änderungen keine neuen Defekte einführen, das externe Verhalten nicht verändern oder kritische strukturelle Elemente (z. B. öffentliche APIs, Assertions) entfernen.

Aktuelle LLM-gestützte Refaktorisierungsansätze lassen oft eine rigorose Verifizierung vermissen, was zu Risiken wie hallucinierten Vorschlägen, inkonsistenten Transformationen und der Entfernung verhaltensrelevanter Codestrukturen führt. Es besteht ein Bedarf an einem systematischen Ansatz, der:

1. LLMs mit Evidenz aus der statischen Analyse leitet.
2. Einen Multi-Agenten-Workflow zur Planung, Generierung und Verifizierung von Änderungen orchestriert.
3. Rückverfolgbare Evidenz darüber liefert, was geändert wurde, welche Risiken bestehen bleiben und ob die Ausgabe ein lebensfähiger Refaktorisierungskandidat oder lediglich eine automatisch akzeptierte Lösung ist.

Methodik: Der REFINE-Workflow

Die Autoren stellen REFINE vor (Refactoring with Evidence-aware Flow for Integrated ageNtic Execution), einen modellunabhängigen, evidenzbewussten Multi-Agenten-Framework, der für die Java-Dateiebene-Refaktorisierung konzipiert ist. Das System ist als Forschungsprototyp implementiert, bestehend aus einer Next.js-Benutzeroberfläche, einem Java Spring Boot Backend (für die statische Analyse via PMD 7.x) und einem Python-Agenten-Service (unter Verwendung von LangGraph v1.1) zur Orchestrierung.

Der Workflow operiert durch drei primäre Phasen:

1. Aufgabencharakterisierung

• Input: Eine einzelne Java-Datei aus einem Open-Source-Projekt.
• Evidenzgewinnung: Statische Analyse (PMD) identifiziert Code-Smells auf Dateiebene und regelbasierte Evidenz.
• Kontextualisierung: Das System extrahiert Signaturen öffentlicher APIs, den Workspace-Kontext und priorisiert die erkannten Smells, um eine begrenzte Refaktorisierungsaufgabe zu bilden.

2. Refaktorisierungs-Orchestrierung

Der Workflow koordiniert elf verschiedene Rollen (Agenten), um den Prozess zu steuern:

• Planning Agent: Kombiniert deterministische, regelbasierte Anleitung mit optionaler LLM-Verfeinerung, um einen Smell-orientierten Refaktorisierungsplan zu erstellen.
• Refactoring Agent: Ruft ein LLM auf, um eine Kandidatentransformation basierend auf dem Plan, dem Originalquellcode und den Constraints (z. B. Erhalt öffentlicher APIs) zu generieren.
• Verification Agent: Analysiert den generierten Kandidaten gegen konfigurierte Evidenzprüfungen, bevor dieser beibehalten wird.

3. Verifizierungs-Trace & Analyse

REFINE behandelt den LLM-Output nicht als final. Stattdessen wird die transformierte Datei erneut analysiert, um zu berechnen:

• Smell-Reduktion: Absolute ($\Delta_{smell} = B - A$) und relative Verbesserungen der erkannten Code-Smells.
• Proxys für die strukturelle Erhaltung: Prüfungen auf Erhalt öffentlicher API-Signaturen, Exception-Handling, Framework-Kontrakte, konditionale Logik und kritische Assert/Fail-Aufrufe.
• Fehlerdiagnose: Protokollierung spezifischer Gründe für eine Ablehnung (z. B. Entfernung einer öffentlichen Methode).
• Rückverfolgbarkeit: Speicherung des Originalquellcodes, des generierten Kandidaten, der Agentenschritte, der Metriken und der Verifizierungsergebnisse, um jede Entscheidung mit ihrer Evidenz zu verknüpfen.

Experimentelles Design

• Datensatz: 450 Java-Dateien aus 15 Open-Source-Systemen (z. B. JHotDraw, Apache Ant, Guava, JabRef), ausgewählt mittels geschichteter Zufallsstichprobe basierend auf der Anzahl der Code-Smells und der Zeilenanzahl (LOC).
• LLM-Konfigurationen: Drei Frontier-Modelle wurden evaluiert: OpenAI GPT-5.5, Google Gemini 3.1 Pro Preview und Anthropic Claude Opus 4.8.
• Skalierung: Dies resultierte in 1.350 Modell-Pass-Outputs.
• Baseline: Eine gematchte Direct-Prompting-Baseline wurde auf einem Subset von 150 Dateien durchgeführt, um den Multi-Agenten-Workflow gegen einfaches Prompting zu vergleichen.
• Metriken: Reduktion der Code-Smells, Qualitätsindikatoren (Zyklomatische Komplexität, Maintainability Index, etc.), strukturelle Änderungen und Erhaltungsrisiken.

Kernergebnisse

1. Reduktion der Code-Smells (RQ1)

REFINE erreichte substanzielle Reduktionen der erkannten Code-Smells über alle drei LLM-Konfigurationen hinweg:

• Gesamtreduktion: 68,26 % (GPT-5.5), 72,79 % (Gemini 3.1) und 68,49 % (Opus 4.8).
• Major Smells: Die signifikantesten Verbesserungen wurden bei Major Code Smells erzielt (86,51 % bis 91,60 % Reduktion).
• Qualitätsindikatoren: Verbesserungen in breiteren Qualitätsmetriken waren nicht einheitlich. Während Gemini 3.1 signifikante Reduktionen in der zyklomatischen Komplexität und LCOM zeigte, wiesen andere Metriken (Maintainability, Testability, Halstead Effort) je nach Modell gemischte oder adverse Veränderungen auf.

2. Erhaltung und Risiken (RQ2)

• Hohe Erfolgsraten: Die meisten statischen Erhaltungsindikatoren (öffentliche Methodensignaturen, Exception-Handling, Framework-Kontrakte) bestanden mit hohen Raten (81,8 % bis 94,2 %).
• Kritische Risiken:
  • Assert/Fail-Aufrufe: Nur 57,1 % der Outputs bewahrten kritische Assert/Fail-Aufrufe über alle Modelle hinweg, was auf ein systemisches Risiko hindeutet.
  • Entfernung öffentlicher Methoden: Dies war das konkretste diagnostische Versagen. Gemini 3.1 wies die höchste Rate an öffentlichen Methoden-Entfernungen auf (71 Fälle), gefolgt von GPT-5.5 (41) und Opus 4.8 (34).

3. Refaktorisierungsverhalten (RQ3)

Verschiedene Modelle erreichten die Reduktion der Smells durch unterschiedliche Edit-Profile:

• GPT-5.5: Erzeugte die kompaktesten Edits.
• Gemini 3.1: Zeigte ein „löschungsintensives“ Profil und entfernte die meisten Zeilen und Methoden.
• Opus 4.8: Zeigte ein „extraktionsintensives“ Profil mit der höchsten Anzahl an Methoden-Extraktionen.
• Korrelation: Größere Edit-Volumina korrelierten mit einer höheren absoluten Smell-Reduktion, aber nicht zwangsläufig mit einer höheren relativen Reduktion.

4. Vergleich mit Direct Prompting

Im gematchten 150-Datei-Subset übertraf REFINE das Direct Prompting in folgenden Punkten:

• Smell-Reduktion: Median der Gesamtreduktion von 100,0 % (REFINE) gegenüber 20,8 % (Direct Prompt).
• Edit-Footprint: Geringerer medianer Churn (14 LOC gegenüber 65 LOC).
• API-Sicherheit: Weniger Entfernungen öffentlicher Methoden (46 Fälle gegenüber 112 Fällen).
• Trade-off: Direct Prompting bewahrte kritische Assert/Fail-Konstrukte häufiger (100 % gegenüber 58 %).

Bedeutung und Ansprüche

Das Paper positioniert REFINE nicht als Ersatz für verhaltensbewahrende Refaktorisierungswerkzeuge, sondern als rückverfolgbaren, evidenzbewussten Mechanismus zur Generierung und Evaluierung von Refaktorisierungskandidaten.

• Evidenzbewusstheit: Der primäre Beitrag liegt in der Verknüpfung des generierten Codes mit der spezifischen statischen Evidenz (Smells), die die Änderung motiviert hat, sowie den Verifizierungsprüfungen, die sie bestanden oder nicht bestanden hat.
• Kontrollierte Generierung: Der Multi-Agenten-Workflow bietet eine kontrolliertere Kandidatengenerierung als Direct Prompting, was zu kleineren Edits und weniger versehentlichen API-Entfernungen führt, wenngleich dies alle Verhaltensrisiken nicht eliminiert.
• Limitierungen: Die Autoren geben explizit an, dass die generierten Outputs Kandidaten sind, keine produktionsreifen Refaktorisierungen. Die statischen Erhaltungsprüfungen sind Proxys und beweisen keine Verhaltensäquivalenz.
• Praktische Implikation: Generierte Kandidaten erfordern Kompilierung, Tests, Abhängigkeitsanalysen und menschliche Überprüfung vor der Übernahme, insbesondere in abhängigkeitsreichen oder systemnahen Umgebungen.

Die Studie kommt zu dem Schluss, dass, obwohl evidenzbewusste Multi-Agenten-Workflows vielversprechend für die gezielte Minderung von Code-Smells auf Dateiebene sind, weder Direct Prompting noch der Multi-Agenten-Ansatz derzeit ausreichende Beweise für die vollständige Wahrung des Verhaltens liefern, um autonom in komplexen Software-Ökosystemen agieren zu können.