Un experimento realizado por JetBrains demostró que proporcionar a los agentes de inteligencia artificial acceso directo al motor de refactorización de Rider puede cambiar radicalmente la forma de ejecutar tareas de C#, en lugar de obligar al agente a modificar texto y después ejecutar el compilador para descubrir qué han estropeado los cambios. En una prueba que incluyó 15 tareas, el tiempo mediano por tarea disminuyó de 157,9 segundos a 26,6 segundos, lo que representa una mejora del 83 %, mientras que el número de llamadas a herramientas se redujo de 17 a 6,2 por tarea.
Esta capacidad se incluye en una capacidad integrada denominada refactoring-code, disponible en Rider a partir de la versión 2026.2.1. Según JetBrains, el usuario no necesita activarla manualmente, ya que el agente la invoca automáticamente cuando se le solicita realizar una refactorización de código C#. El motor se basa en las tecnologías de ReSharper y en la arquitectura analítica de Rider para comprender las relaciones entre símbolos y referencias dentro del proyecto.
El problema del enfoque de modificar y después compilar
Antes de habilitar la capacidad, JetBrains observó un modelo avanzado mientras ejecutaba las mismas tareas. Durante 2.513 llamadas a distintas herramientas, el agente no realizó ninguna operación de refactorización estructural directa, porque no disponía de una herramienta específica para ello. En su lugar, utilizó comandos interactivos para introducir texto 468 veces, invocó git 422 veces y sed 392 veces, y también ejecutó dotnet build 163 veces.
Esto no significa que el agente evitara las operaciones de refactorización, sino que intentaba aproximarse a ellas mediante búsquedas y modificaciones de texto, y después utilizaba los resultados de la compilación para evaluar lo ocurrido. JetBrains explica que renombrar un símbolo, por ejemplo, requiere distinguir entre las referencias vinculadas a una definición concreta, las llamadas a métodos polimórficos, las clases parciales, las implementaciones explícitas de interfaces y las referencias de documentación. Estas relaciones no pueden garantizarse mediante una expresión regular.
En cambio, el motor de Rider trabaja sobre un árbol de sintaxis resuelto que determina la definición asociada a cada identificador, la versión que invoca cada llamada y las ubicaciones de las referencias en toda la solución. De este modo, la parte estructural de la tarea pasa al motor, en lugar de que el agente tenga que redescubrir gradualmente estas relaciones mediante ciclos repetidos de modificación, compilación y lectura de errores.
¿Qué midió JetBrains?
La evaluación se centró en ocho operaciones con resultados claramente verificables:
- Renombrar un símbolo y todas sus referencias.
- Extraer un conjunto de instrucciones a una nueva función.
- Extraer una interfaz de un tipo existente.
- Extraer una clase base y trasladar los miembros a ella.
- Cambiar la firma de una interfaz de programación y actualizar los lugares de llamada.
- Mover un tipo a otro espacio de nombres y corregir las instrucciones using.
- Reorganizar los espacios de nombres para que coincidan con la estructura de carpetas.
- Eliminar un símbolo de forma segura cuando ninguna otra parte depende de él.
Las tareas incluyeron casos directos y otros más complejos, con un mayor número de lugares de llamada o dependencias entrelazadas. Ambos grupos ejecutaron el mismo modelo, gpt-5.5, mediante Codex CLI, aproximadamente diez veces por tarea. La única diferencia fue la disponibilidad de la capacidad refactoring-code. Las comparaciones se basaron en los registros de actividad y en una prueba de permutación pareada.
Resultados prácticos y coste
Con la capacidad activada, el número de operaciones dotnet build disminuyó de 163 a solo tres, y el total de llamadas a herramientas en la evaluación se redujo de 2.513 a 926. Las modificaciones de texto no desaparecieron: sed siguió siendo la herramienta más utilizada, pero la distribución de funciones cambió. Las modificaciones normales permanecieron en las herramientas de edición de texto, mientras que el motor asumió los cambios estructurales cuyos efectos podían extenderse a partes que el agente no veía directamente.
El tiempo en el percentil 95 disminuyó de 346,4 a 56,9 segundos, una mejora relacionada especialmente con la desaparición de los casos atascados en el ciclo de modificación, compilación y corrección de errores. El coste mediano por tarea pasó de 0,33 dólares a 0,12 dólares, y el coste por tarea completada con éxito disminuyó de 0,52 dólares a 0,19 dólares. También se redujo el número de tokens introducidos, de 436.745 a 208.524 por tarea; las lecturas de memoria temporal, de 2.973.158 a 1.257.600; y las salidas, de 32.532 a 15.538.
¿Qué significa esto para los usuarios?
El experimento muestra que la utilidad de las herramientas de los agentes no depende únicamente de la capacidad del modelo para producir código, sino también del tipo de herramientas que puede invocar. En ocho de las 15 tareas, el grupo con la capacidad fue más rápido y menos costoso, y no utilizó un número mayor de herramientas, mientras ambos grupos superaron las pruebas. Las seis tareas cuya ejecución tardaba más de dos minutos en el modo básico mejoraron entre un 82 % y un 94 %.
Sin embargo, los resultados no representan una ventaja general para todos los casos. Ambos grupos fallaron en dos tareas, el modo básico tuvo éxito en una tarea en la que no lo tuvo el modo con la capacidad, y cuatro tareas ya eran lo bastante rápidas como para que invocar el motor de Rider no resultara económicamente útil. Por ello, las cifras demuestran la utilidad de la capacidad dentro de un conjunto concreto de operaciones de refactorización, pero no garantizan que todas las tareas mejoren en la misma medida.
Para ilustrar la diferencia, JetBrains presentó una tarea de extracción de una clase base del tipo ReportExporter. Sin la capacidad, la ejecución tardó 336,7 segundos y requirió 24 llamadas, con un coste de 1,15 dólares, e incluyó varios ciclos de modificación de archivos y ejecución de la compilación para corregir errores de herencia, constructores y permisos de acceso. Con la capacidad, tardó 19,8 segundos y requirió tres llamadas, con un coste de 0,09 dólares, ya que el agente ejecutó la operación extract_base_class, creó ExporterBase, actualizó cuatro archivos y reescribió 11 referencias.
La función puede probarse actualizando Rider a la versión 2026.2.1, abriendo una solución de C# y solicitando al agente que renombre un elemento, extraiga una interfaz o mueva un tipo. El artículo recomienda que las solicitudes especifiquen el nombre de la operación, como pedir extraer una interfaz de OrderProcessor, en lugar de utilizar una formulación general como «limpia esta clase».