SmellBench: Towards Fine-Grained Evaluation of Code Agents on Refactoring Tasks
Dieses Paper führt SmellBench ein, einen neuen Benchmark, der darauf ausgelegt ist, Code-Agenten bei Refactoring-Aufgaben durch das Injizieren von realen Code Smells zu evaluieren, wobei aufgezeigt wird, dass aktuelle Top-Modelle Schwierigkeiten mit dem dateiübergreifenden Verständnis haben und nur moderaten Erfolg bei der Beseitigung dieser Wartbarkeitsprobleme erzielen.
Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen
Das große Ganze: Das „Unordentliches Zimmer“-Problem
Stellen Sie sich vor, Sie haben einen sehr intelligenten Roboter-Assistenten (einen Code Agent), der Code schreiben, Fehler beheben und Dateien organisieren kann. Sie bitten ihn, ein unordentliches Zimmer aufzuräumen (Code refactoren).
Die meisten Tests für diese Roboter fragen nur: „Hast du den Stuhl so verschoben, dass man durch die Tür gehen kann?“ Wenn der Roboter den Stuhl bewegt und man hindurchgehen kann, sagt der Test: „Bestanden!“
Aber das Papier argumentiert, dass dies nicht ausreicht. Der Roboter hat vielleicht den Stuhl bewegt, aber dabei eine Lampe umgestoßen, einen Haufen Kleidung auf dem Boden liegen lassen und das Fenster blockiert. Das Zimmer funktioniert (man kann hindurchgehen), aber es ist ein Desaster, dort langfristig zu leben. Das ist das, was Entwickler als „Code Smells“ bezeichnen – klobiger, unordentlicher oder schlecht organisierter Code, der heute funktioniert, aber morgen Kopfschmerzen bereiten wird.
SmellBench ist ein neuer Test, der darauf ausgelegt ist, zu sehen, ob diese KI-Roboter tatsächlich in der Lage sind, das Chaos aufzuräumen, ohne es schlimmer zu machen, anstatt nur zu prüfen, ob die Tür noch offen steht.
Wie sie den Test gebaut haben (Die „Kontrollierte Chaos“-Fabrik)
Die Forscher erkannten, dass es schwierig ist, echte Beispiele für unordentlichen Code zu finden – es ist, als versuche man, ein bestimmtes Sandkorn an einem Strand zu finden. Es ist schwer, und das Chaos ist oft mit anderen Dingen vermischt (wie neuen Funktionen oder Fehlerbehebungen).
Also bauten sie eine Fabrik, um perfekt kontrolliertes Chaos zu erzeugen:
- Das saubere Zimmer: Sie begannen mit 7 berühmten, sauberen, gut organisierten Python-Projekten (wie
pandasodernumpy). Denken Sie an diese als makellose, perfekt organisierte Bibliotheken. - Das Einschleusen des „Geruchs“: Anstatt darauf zu warten, dass ein Chaos natürlich entsteht, nutzten sie eine KI, um den Code absichtlich zu ruinieren. Sie injizierten 7 spezifische Arten von „Smells“ (wie eine „God Class“, die versucht, zu viele Dinge gleichzeitig zu tun, oder „Dead Code“, der nie verwendet wird).
- Die Grundwahrheit (Ground Truth): Da sie das Chaos selbst erschaffen haben, wissen sie genau, wie die saubere Version aussah, bevor sie sie kaputt gemacht haben. Dies ist ihr „Lösungsschlüssel“.
Das Ergebnis: Ein Datensatz von 294 spezifischen „unordentlichen“ Szenarien, die von einfach bis sehr schwer reichen und 7 verschiedene Arten von Code-Hässlichkeit abdecken.
Die 7 Arten von „Code Smells“ (Die Szenarien im unordentlichen Zimmer)
Das Papier konzentriert sich auf 7 spezifische Arten, wie Code unordentlich werden kann. Hier ist die Übersetzung in den Alltag:
- Feature Envy (Merkmalsneid): Eine Person (eine Funktion), die ständig Dinge vom Haus ihres Nachbarn ausleiht, anstatt ihre eigenen zu benutzen. Analogie: Du leihst ständig den Hammer deines Nachbarn, weil du keinen eigenen hast, obwohl du eigentlich ein eigenes Werkzeugset besitzt.
- God Classes (Gott-Klassen): Eine einzelne Person, die versucht, jeden Job im Unternehmen zu erledigen (Kochen, Buchhaltung, Sicherheit und Personalwesen). Analogie: Ein einzelner Hausmeister, der gleichzeitig die Rohre repariert, Mathe unterrichtet und Brot backt.
- Data Clumps (Datenklumpen): Man trägt immer dieselbe Gruppe von Gegenständen (Schlüssel, Brieftasche, Telefon) überallhin mit sich, selbst wenn man nur einen davon braucht. Analogie: Einen ganzen Werkzeugkasten tragen, nur um eine Glühbirne zu wechseln.
- Shotgun Surgery (Schrotflinten-Chirurgie): Man möchte eine kleine Sache ändern (wie die Farbe der Wände), muss dafür aber in 10 verschiedene Zimmer gehen. Analogie: Den Preis eines Produkts zu ändern erfordert, dass man gleichzeitig den Beleg, die Website, die Rechnung und das Versandetikett separat aktualisiert.
- Dead Code (Toter Code): Möbel in einem Raum, auf denen niemand sitzt oder die niemand benutzt. Analogie: Ein Bücherregal voller Bücher, die man vor 10 Jahren gelesen hat und die man nie wieder anfasst.
- Interface Segregation (Schnittstellen-Trennung): Eine Fernbedienung mit 50 Tasten, von denen man nur 3 benutzt. Analogie: Eine Speisekarte in einem Restaurant, die einen dazu zwingt, ein Steak, einen Salat und ein Dessert zu bestellen, nur um ein Glas Wasser zu bekommen.
- Deep Inlining (Tiefe Inline-Strukturen): Ein Rezept, das sagt: „Mache Schritt 1, was bedeutet, mache Schritt 2, was bedeutet, mache Schritt 3...“ – alles in einem einzigen riesigen Absatz geschrieben. Analogie: Eine Karte, bei der die Wegbeschreibungen innerhalb der Wegbeschreibungen stehen, was es unmöglich macht, ihnen zu folgen.
Das Experiment: Können die Roboter aufräumen?
Die Forscher gaben diese unordentlichen Code-Schnipsel an 2 populäre KI-Agenten (OpenHands und Qwen Code) weiter, die von 6 verschiedenen „Gehirnen“ (Large Language Models wie Claude, GPT und DeepSeek) gesteuert wurden.
Die Regeln:
- Die KI musste das Chaos finden.
- Die KI musste das Chaos beheben.
- Die KI musste sicherstellen, dass der Code weiterhin funktioniert (die Tests besteht).
Die Ergebnisse (Der schockierende Teil):
Selbst die beste Kombination aus KI (Qswen Code + Claude Sonnet 4.5) erreichte einen Wert von nur 50,34 % bei der Beseitigung der Gerüche.
- Der „Tür“-Test (Funktionale Korrektheit): Die Roboter waren gut darin. Die meisten von ihnen hielten die „Tür offen“ (der Code lief weiterhin). Sie bestanden die Basistests in 80–90 % der Fälle.
- Der „Sauberes Zimmer“-Test (Refactoring-Qualität): Die Roboter scheiterten hier. Sie behoben oft das unmittelbare Problem, ließen das Zimmer aber trotzdem unordentlich zurück. Sie hatten Schwierigkeiten, das große Ganze zu sehen, besonders wenn das Chaos mehrere Dateien betraf (wie beim „Shotgun Surgery“-Geruch).
Wichtigste Erkenntnis: Die KI ist gut darin, den Code funktionieren zu lassen, aber derzeit schlecht darin, den Code schön und wartbar zu machen.
Warum das wichtig ist
Das Papier kommt zu dem Schluss, dass wir die KI nicht einfach nur fragen dürfen: „Läuft der Code?“ Wir müssen fragen: „Ist der Code sauber?“
Sie haben eine neue Methode eingeführt, um die KI mit einer „Judge AI“ zu bewerten, die prüft:
- Hat sie die Tests bestanden? (Ist die Tür offen?)
- Hat sie die richtige Stelle zur Reparatur gefunden? (Hat sie im richtigen Zimmer gesucht?)
- Ist der Code tatsächlich besser? (Ist das Zimmer ordentlich?)
Das Fazte Fazit: Aktuelle KI-Agenten sind wie enthusiastische Praktikanten, die zwar Möbel rücken können, aber oft eine Spur aus Staub hinterlassen. Sie werden besser, aber sie haben noch einen weiten Weg vor sich, bis man ihnen vertrauen kann, komplexe Softwaresysteme professionell zu „refactoren“ (aufzuräumen).
Ertrinken Sie in Arbeiten in Ihrem Fachgebiet?
Erhalten Sie tägliche Digests der neuesten Arbeiten passend zu Ihren Forschungsbegriffen — mit technischen Zusammenfassungen, in Ihrer Sprache.