KI-Refactorings: Charakterisierungstests als Schiedsrichter gegen funktionale Fehler

Drei-Schritte-Workflow: Charakterisierungstests als Schiedsrichter

Ein Blog-Artikel beschreibt einen dreistufigen Workflow, der KI-generierte Refactorings einer testbasierten Sicherheitsprüfung unterzieht. Im ersten Schritt wird das Verhalten des bestehenden Legacy-Codes durch Charakterisierungstests eingefroren. Diese Tests zeichnen Eingaben und Ausgaben auf, ohne über richtig oder falsch zu urteilen – sie fixieren lediglich den aktuellen Vertrag der Funktion. Anschließend schlägt ein generatives Modell einen Refactor vor, also eine Codeänderung, die die Struktur verbessern soll, ohne das Verhalten zu verändern. Im dritten Schritt werden dieselben Charakterisierungstests sowohl gegen die alte als auch gegen die neue Version ausgeführt. Das Ergebnis ist binär: 'safe', wenn beide Versionen identische Ausgaben liefern, oder 'not safe', wenn Abweichungen auftreten. Als konkretes Beispiel dient eine Versandkosten-Funktion mit verschachtelten Bedingungen und magischen Zahlen, für die es keine Tests gibt. Ein Probe-Skript ruft die Funktion mit realistischen Fällen auf – etwa unterschiedliche Artikelgewichte, Mengen und Regionen wie US, EU oder JP – und speichert die realen Ein- und Ausgaben als JSON. Diese gespeicherten Paare bilden die Grundlage für die Charakterisierungstests. Der Artikel betont, dass Legacy-Code keine Spezifikation besitzt; das einzige verlässliche Spezifikationsobjekt ist das aktuelle Verhalten, selbst wenn es sich um Bugs handelt. Nur durch das Einfrieren dieses Verhaltens wird jede Abweichung sichtbar, die ein KI-Refactoring verursacht.

Copilot & Co.: Refactoring ohne Sicherheits-Verdict

Bestehende KI-Assistenten liefern zwar Refactoring-Vorschläge, verzichten jedoch auf einen testbasierten Verdict-Mechanismus. GitHub Copilot in VS Code bietet KI-gestützte Inline-Vorschläge in Form von Ghost Text und Next Edit Suggestions, die Code, Kommentare und Tests vervollständigen. Diese Vorschläge berücksichtigen den bestehenden Code und den Programmierstil, prüfen aber nicht automatisiert, ob eine vorgeschlagene Änderung das Verhalten des Programms unverändert lässt. In IDEs kann Copilot zum Refactoring genutzt werden, etwa über den Befehl /explain, der Codeabschnitte erläutert, oder über Optimierungsvorschläge, die ineffizienten Code verbessern sollen. Visual Studio beschreibt KI-gestützte Entwicklung mit Code-Refactoring durch kontextbezogene Empfehlungen von GitHub Copilot und IntelliCode. Diese Werkzeuge schlagen Codeänderungen vor, ohne deren Verhaltensgleichheit automatisiert zu verifizieren. Der Nutzer erhält einen Diff oder eine Inline-Ergänzung, muss aber selbst beurteilen, ob die Änderung semantisch äquivalent ist. Ein expliziter Schritt, der alte und neue Version gegen dieselben Tests laufen lässt und ein eindeutiges 'safe' oder 'not safe' ausgibt, fehlt in diesen Assistenten.

Studienlage: KI-Refactorings oft funktional falsch

Empirische Studien zeigen, dass KI-generierte Refactorings ohne Absicherung ein erhebliches Risiko darstellen. Die Studie 'Refactoring vs Refuctoring' kommt zu dem Ergebnis, dass bestehende KI-Lösungen nur in 37 Prozent der Fälle funktional korrekte Refactorings liefern. Das bedeutet, dass fast zwei Drittel der Vorschläge das Verhalten des Codes verändern – ein klarer Verstoß gegen die Definition von Refactoring. Erst durch einen Faktencheck und die Ablehnung falscher Lösungen verbessern 98 Prozent der verbleibenden KI-generierten Refactorings den Code bei erhaltenem Verhalten. Der SWE-Refactor-Benchmark, der 1.099 verhaltenserhaltende Refactorings aus 18 Java-Projekten umfasst, bestätigt die Schwierigkeiten: Ein OpenAI Codex Agent erreicht bei zusammengesetzten Refactorings nur eine Erfolgsquote von 39,4 Prozent. Komplexe und zusammengesetzte Refactorings sind demnach die Hauptfehlerquelle. Die Diff-XYZ-Studie ergänzt, dass die Wahl des Diff-Formats je nach Anwendungsfall und Modellgröße entscheidend ist: Das Search-Replace-Format eignet sich für große Modelle bei der Diff-Generierung, nicht jedoch für die Diff-Analyse und kleine Modelle. Diese Befunde verdeutlichen, dass KI-generierte Refactorings ohne eine automatisierte Verifikation der Verhaltensgleichheit riskant sind und in vielen Fällen zu funktionalen Fehlern führen.

Industrie-Tools: Von MetaMateCR bis Trae Agent

Aktuelle Industrieansätze versuchen, die Qualität KI-generierter Codeänderungen zu verbessern, bieten aber ebenfalls keine vollständige Sicherheit. MetaMateCR von Meta erreicht mit einem internen LargeLSFT-Modell eine Exact-Match-Patch-Rate von 68 Prozent und übertrifft GPT-4o um 9 Prozentpunkte. In einem Sicherheitsversuch brauchten Reviewer zunächst über 5 Prozent länger, nach einer UX-Änderung, bei der nur Autoren die Patches sehen, trat keine Regression mehr auf. Die Produktions-ActionableToApplied-Rate liegt bei 19,7 Prozent. Trae Agent, ein agentenbasierter Ensemble-Ansatz für Repository-Level-Issue-Resolution, führt die SWE-bench Verified Rangliste an und erzielt eine durchschnittliche Verbesserung von 10,22 Prozent bei Pass@1. AutoPatchBench ist ein Benchmark für die automatisierte Reparatur von durch Fuzzing gefundenen Schwachstellen und umfasst 136 C/C++-Schwachstellen; er ist Teil von CyberSecEval 4. Metas Engineering Agent behebt Quellcode auf Basis von Testfehlern, wobei ein spezialisiertes 70B-Modell konkurrenzfähig zu Llama-405B ist und das Search-Replace-Format das Unified-Diff-Format übertrifft. Trotz dieser Fortschritte bleibt die Verhaltensgleichheit nicht garantiert: Die Systeme optimieren auf Metriken wie Patch-Rate oder Benchmark-Erfolg, nicht auf eine testbasierte Verifikation der Semantik. Ein expliziter Verdict-Mechanismus, der alte und neue Version gegeneinander testet, könnte diese Lücke schließen.

Tests als Schiedsrichter: Ein pragmatischer Ansatz gegen hohe Fehlerraten

Angesichts der hohen Fehlerraten von KI-Refactorings – nur 37 Prozent funktional korrekt laut 'Refactoring vs Refuctoring' – und der fehlenden Verifikation in gängigen Assistenten wie GitHub Copilot bietet der vorgestellte Workflow eine konkrete Absicherung. Indem er Charakterisierungstests als Entscheidungsinstanz nutzt, verwandelt er die Unsicherheit eines KI-Vorschlags in ein binäres Urteil: 'safe' oder 'not safe'. Dies ist besonders relevant vor dem Hintergrund früherer Berichterstattung über KI-generierten Code, der zwar weniger Bugs aufweist, aber höhere Wartungskosten verursacht. Wenn Refactorings das Verhalten ungewollt ändern, steigen diese Kosten weiter. Der Workflow ist pragmatisch: Er erfordert lediglich ein Probe-Skript, das reale Ein- und Ausgaben als JSON speichert, und die Ausführung derselben Tests gegen beide Versionen. Er ersetzt keine gründliche Code-Review, reduziert aber das Risiko, dass ein scheinbar sauberer Diff stille Regressionen einführt. Für Teams, die KI-gestütztes Refactoring einsetzen wollen, ohne die Verhaltensgarantie aufzugeben, ist dieser Ansatz eine sinnvolle Ergänzung zu bestehenden Werkzeugen.