Ein von JetBrains durchgeführtes Experiment zeigte, dass der direkte Zugriff von KI-Agenten auf die Refactoring-Engine in Rider die Ausführung von C#-Aufgaben grundlegend verändern kann, anstatt den Agenten dazu zu bringen, Text zu bearbeiten und anschließend den Compiler auszuführen, um festzustellen, was die Änderungen beschädigt haben. In einem Test mit 15 Aufgaben sank die mediane Aufgabendauer von 157,9 Sekunden auf 26,6 Sekunden, was einer Verbesserung von 83 % entspricht. Gleichzeitig ging die Zahl der Tool-Aufrufe von 17 auf 6,2 pro Aufgabe zurück.
Diese Möglichkeit ist Bestandteil einer integrierten Fähigkeit namens refactoring-code, die in Rider ab Version 2026.2.1 verfügbar ist. Laut JetBrains muss der Benutzer sie nicht manuell aktivieren; der Agent ruft sie automatisch auf, wenn er zur Umstrukturierung von C#-Code aufgefordert wird. Die Engine nutzt ReSharper-Technologien und die Analyseinfrastruktur von Rider, um die Beziehungen zwischen Symbolen und Verweisen innerhalb des Projekts zu verstehen.
Das Problem beim Ansatz „Ändern und dann bauen“
Vor der Bereitstellung der Fähigkeit beobachtete JetBrains ein fortgeschrittenes Modell bei der Ausführung derselben Aufgaben. Bei 2.513 Aufrufen verschiedener Tools führte der Agent keine direkte strukturelle Refactoring-Operation aus, da ihm dafür kein spezielles Tool zur Verfügung stand. Stattdessen verwendete er interaktive Befehle zur Texteingabe 468-mal, rief git 422-mal und sed 392-mal auf und führte dotnet build 163-mal aus.
Das bedeutet nicht, dass der Agent Refactoring-Operationen vermied. Er versuchte vielmehr, sie durch Suchen und textuelle Änderungen anzunähern und anschließend die Build-Ergebnisse zur Bewertung der Auswirkungen zu verwenden. JetBrains erläutert, dass beispielsweise die Umbenennung eines Symbols die Unterscheidung zwischen Verweisen auf eine bestimmte Definition, Aufrufen polymorpher Methoden, partiellen Klassen, expliziten Schnittstellenimplementierungen und Dokumentationsverweisen erfordert. Diese Beziehungen lassen sich nicht durch einfache reguläre Ausdrücke zuverlässig gewährleisten.
Im Gegensatz dazu arbeitet die Rider-Engine mit einem aufgelösten Syntaxbaum, der bestimmt, mit welcher Definition jeder Bezeichner verbunden ist, welche Version jeder Aufruf verwendet und an welchen Stellen im gesamten Softwareprojekt Verweise vorkommen. Dadurch wird der strukturelle Teil der Aufgabe an die Engine übertragen, anstatt dass der Agent diese Beziehungen schrittweise durch wiederholte Zyklen aus Ändern, Bauen und Lesen von Fehlermeldungen neu ermitteln muss.
Was hat JetBrains gemessen?
Die Bewertung konzentrierte sich auf acht Operationen mit eindeutig überprüfbaren Ergebnissen:
- Ein Symbol und alle seine Verweise umbenennen.
- Eine Gruppe von Anweisungen in eine neue Funktion extrahieren.
- Eine Schnittstelle aus einem vorhandenen Typ extrahieren.
- Eine Basisklasse extrahieren und Mitglieder in diese verschieben.
- Die Signatur einer Programmierschnittstelle ändern und die Aufrufstellen aktualisieren.
- Einen Typ in einen anderen Namespace verschieben und using-Anweisungen korrigieren.
- Namespaces so neu organisieren, dass sie der Ordnerstruktur entsprechen.
- Ein Symbol sicher löschen, wenn kein anderer Teil davon abhängt.
Die Aufgaben umfassten einfache Fälle und komplexere Szenarien mit einer größeren Anzahl von Aufrufstellen oder miteinander verflochtenen Abhängigkeiten. Beide Seiten führten über Codex CLI dasselbe Modell, gpt-5.5, für jede Aufgabe ungefähr zehnmal aus. Der einzige Unterschied bestand darin, ob die Fähigkeit refactoring-code verfügbar war. Die Vergleiche basierten auf aufgezeichneten Spuren und einem gepaarten Permutationstest.
Praktische Ergebnisse und Kosten
Bei aktivierter Fähigkeit sank die Zahl der dotnet-build-Vorgänge von 163 auf nur drei, und die Gesamtzahl der Tool-Aufrufe in der Bewertung ging von 2.513 auf 926 zurück. Die textuellen Änderungen verschwanden nicht; sed blieb das am häufigsten verwendete Tool. Die Aufgabenverteilung änderte sich jedoch: Gewöhnliche Änderungen blieben den Textbearbeitungswerkzeugen überlassen, während die Engine strukturelle Änderungen übernahm, deren Auswirkungen sich auf Teile erstrecken konnten, die der Agent nicht unmittelbar sehen konnte.
Das 95. Perzentil der Ausführungszeit sank von 346,4 auf 56,9 Sekunden. Diese Verbesserung hängt insbesondere mit dem Wegfall festgefahrener Fälle in der Schleife aus Ändern, Bauen und Fehlerbehebung zusammen. Die medianen Kosten pro Aufgabe gingen von 0,33 US-Dollar auf 0,12 US-Dollar zurück, und die Kosten pro erfolgreicher Aufgabe sanken von 0,52 US-Dollar auf 0,19 US-Dollar. Außerdem verringerte sich die Zahl der eingegebenen Tokens von 436.745 auf 208.524 pro Aufgabe, die Lesezugriffe auf den Zwischenspeicher von 2.973.158 auf 1.257.600 und die Ausgaben von 32.532 auf 15.538.
Was bedeutet das für Benutzer?
Das Experiment zeigt, dass der Nutzen von Agentenwerkzeugen nicht allein von der Fähigkeit des Modells abhängt, Code zu erzeugen, sondern auch von der Art der Werkzeuge, die es aufrufen kann. Bei acht von 15 Aufgaben war die mit der Fähigkeit ausgestattete Variante schneller und kostengünstiger und verwendete nicht mehr Tools, während beide Varianten die Tests bestanden. Die sechs Aufgaben, deren Ausführung im Basismodus länger als zwei Minuten dauerte, verbesserten sich um 82 % bis 94 %.
Die Ergebnisse stellen jedoch keinen umfassenden Vorteil für jeden Fall dar. Beide Varianten scheiterten bei zwei Aufgaben, der Basismodus war bei einer Aufgabe erfolgreich, bei der die mit der Fähigkeit ausgestattete Variante scheiterte, und vier Aufgaben waren bereits so schnell, dass sich der Aufruf der Rider-Engine wirtschaftlich nicht lohnte. Die Zahlen liefern daher Belege für den Nutzen der Fähigkeit innerhalb einer bestimmten Gruppe von Refactoring-Operationen, aber keine Garantie dafür, dass sich jede Aufgabe im gleichen Maß verbessert.
Um den Unterschied zu veranschaulichen, präsentierte JetBrains die Aufgabe, eine Basisklasse aus dem Typ ReportExporter zu extrahieren. Ohne die Fähigkeit dauerte die Ausführung 336,7 Sekunden, umfasste 24 Aufrufe und kostete 1,15 US-Dollar. Dabei wurden mehrere Zyklen aus Dateibearbeitung und Build-Ausführung durchlaufen, um Fehler bei Vererbung, Konstruktoren und Zugriffsrechten zu beheben. Mit der Fähigkeit dauerte die Ausführung 19,8 Sekunden, umfasste drei Aufrufe und kostete 0,09 US-Dollar. Der Agent führte die Operation extract_base_class aus, erstellte ExporterBase, aktualisierte vier Dateien und schrieb 11 Verweise neu.
Die Funktion kann ausprobiert werden, indem Rider auf Version 2026.2.1 aktualisiert, anschließend eine C#-Lösung geöffnet und der Agent zum Umbenennen eines Elements, Extrahieren einer Schnittstelle oder Verschieben eines Typs aufgefordert wird. Der Artikel empfiehlt, Anfragen mit dem Namen der Operation konkret zu formulieren, etwa mit der Aufforderung, eine Schnittstelle aus OrderProcessor zu extrahieren, statt eine allgemeine Formulierung wie „Bereinige diese Klasse“ zu verwenden.