Refactoring eficiente con AI code agents: Resultados prelimimares
Según un artículo en Forbes (1) se ha estimado que un uso intensivo de una suscripción de Claude Code de 200$ podría llegar a suponer hasta 5.000$ de coste en computación para la inferencia.
En definitiva, los usuarios no estaríamos pagando el coste del uso de estas herramientas, sino que las empresas estarían subvencionado los tokens a través de la financiación.
El coste no es solo económico, sino también energético, social y ambiental. Al estar consumiendo energía y materiales a un ritmo cada vez superior sin aumentar al mismo tiempo la velocidad de reposicón, estaríamos hipotecando las condiciones de vida digna de las generaciones presentes y futuras.
Estamos en un tren que cada vez va a más velocidad y que desde la acción individual parece imposible frenar, cuyo riesgo cada vez más alto de accidente está a la espera de encontrar las condiciones que lo desencadenen.
En este contexto es donde nace el estudio que inicié a principios de año, con el fin de poner el acento en mecanismos para reducir el coste, el consumo energético y nuestra dependencia con los modelos más grandes cuando desarrollamos con agentes de código.
El coste del indeterminismo
Los resultados que ofrecen los agentes de código para todo tipo de tareas, especialmente aquellos que usan LLMs de Tier S, unido al bajo coste percibido por sus usuarios, ha hecho que estemos utilizando los agentes para todo tipo de tareas.
Si bien la inferencia ofrece resultados no deterministas, el razonamiento, el human-in-the-loop, skills y otras técnicas, hacen que cada vez las expectativas del resultado que un humano tiene al delegar una tarea a la IA estén cada vez más alineadas con lo que el agente acaba construyendo.
Y los resultados no solo han mejorado gracias a la mejora de los LLMs, sino especialmente a cómo los agentes buscan y construyen el contexto adecuado para mandar a la capa de inferencia.
Hemos pasado de peticiones a agentes cuyos resultados se alejaban fácilmente de nuestras expectativas, a agentes que se alinean bien y que incluso tienen en cuenta aspectos importantes que habíamos pasado por alto.
Pero esta mejora no es gratis. Mi experiencia durante el último año me dice que hemos pasado de agentes más rudimentarios, a agentes que leen y releen una gran cantidad de archivos, y que razonan y re-razonan sobre los mismos en cada paso, aumentando así la cantidad de tokens necesarios para resolver una misma tarea.
En 10 tareas sencillas de refactoring en un repositorio pequeño (~10k lineas en 125 archivos) Codex (gpt-5.3-codex) necesito ~120k tokens totales de media por refactoring y Claude Code (claude-haiku-4-5-20251001) unos ~470k, y todo eso solo para conseguir una tasa de éxito del 40% (Codex) y 60% (Claude Code).
Para un humano, hacer esos 10 mismos refactorings tiene el coste de localizar y deteminar los refactorings a realizar, pero una vez invocada la herramienta de refactoring no se requiere de ningún tipo de inferencia y, si la herramienta es buena, el éxito esperable es que sea ceracano al 100%.
Más adelante explico cómo determino el éxito, pero a grandes rasgos sería que el código generado tras refactorizar sea idéntico al que esperaríamos al hacer el refactor manualmente.
El tooling de refactoring es solo un ejemplo de las muchas herramientas, existentes y por desarrollar, que podemos utilizar para reducir el coste e impacto negativo de la inferencia, a la vez que mejoramos nuestra experiencia de desarrollo.
¿Por qué estudiar el refactoring?
La mayor parte del coste de la vida útil de un producto de software no está en su construcción inicial sino en su mantenimiento.
El software no es como construir edificios, sino más bien como moldear plastilina. No solo construimos software para que sea útil hoy, sino también para que sea fácil de cambiar mañana.
Y este proceso no solo se da al inicio, sino que cada vez que nos diponemos a cambiar el software, podemos razonar sobre si debemos adaptarlo para las necesidades actuales y futuras.
Todas estas operaciones de cambio en el software las podemos catalogar en dos:
- Modificación del producto: Cambio del comportamiento externo, es decir, lo que ven los usuarios.
- Refactoring: Modificaciones sin cambio del comportamiento externo.
Si bien muchas veces acabamos mezclando los dos tipos de cambios (cosa que también hacen a menudo los agentes), separarlos tiene ventajas.
En este sentido, una de las técnicas promovida por Kent Beck (2) es primero hacer fácil el cambio que vas a introducir (refactoring), para después, añadir la funcionalidad de forma fácil (modificación del producto). En ingles se expresa como "make the change easy, then make the easy change". Al final es como intentar meter ropa nueva en un armario lleno y desorganizado, primero toca ordenarlo y hacer sitio antes de acomodar la nueva ropa.
Así que si separamos las operaciones de refactoring de las que cambian comportamiento, un agente podría expresar muchos de los cambios como una sucesión de pequeños refactorings, y delegar estas tareas a una herramienta determinista que no requeira inferencia de IA:
refactorings = [
(extract_method, range, name),
(rename, file, symbol, new_name),
(move, file, new_path),
(extract_class, symbol),
...
]
refactor_tool(refactorings)
El coste del refactoring multi archivo
No todos los refactorings tienen el mismo coste de inferencia. Los más costosos para un agente son aquellos que requieren revisar todas las posibles referencias de un símbolo en toda la base de código, como por ejemplo, el rename de una función pública.
Esto tiene sentido, ya que un humano sin tooling también tendría que revisar cada archivo manualmente en busca de referencias.
Cuando los agentes no tienen herramientas específicas para el análisis del código, utilizan herramientas de cli como find, grep, etc. para encontrar referencias.
Esa búsqueda es un coste en si mismo, pero eso es solo el inicio. Además de buscar las referencias, los agentes deben enviar cada archivo referenciado a la capa de inferencia para:
- Determinar si es una referencia legítima.
- Hacer propiamente el refactoring.
Mi experiencia me dice que muchos agentes en la actualidad presentan dificultades para encontrar a la primera todas las referencias correctas via inferencia, y eso, además de aumentar el volumen de interacciones y el tiempo de ejecución de la tarea, hace que se equivoquen y tengan que retrabajar.
La búsqueda de referencias puede mejorar al conectar el agente con un servidor LSP (Language Server Protocol) para buscarlas, pero una vez encontradas, si no utiliza las tools de refactoring, el agente tiene que leer y mandar cada archivo a la capa de inferencia para ejecutar el refactoring, manteniendo así una alta cantidad de tokens en el contexto de entrada.
El estudio: resultados preliminares
La hipótesis que pensé hace unos meses fue la siguiente:
Si conectamos un agente con herramientas deterministas de refactoring, para estas operaciones, el uso de tokens podría verse reducido, y la experiencia de desarrollo podría mejorar (tasa de éxito, menos retrabajo, tiempo, etc.), además de que podríamos usar modelos más pequeños, reduciendo así el coste de entrenamiento e inferencia.
El estudio sigue en proceso, pero como voy avanzando a ritmo lento, he creido interesante compatir lo aprendido hasta el momento.
La primera prueba ha consistido en conectar mediante un MCP a agentes como Codex (gpt-5.3-codex) y Claude Code (claude-haiku-4-5-20251001) a un servidor LSP con capacidades de refactoring.
Las tareas por el momento son muy directas:
Rename 'foo' method in @file.py to 'bar'. All references must be refactored. To rename the function, just read the target file and execute the refactoring tool without post execution verification.
La metodología se resume en ejecutar esa misma tarea para una agente que no tiene acceso al MCP de refactoring y otro con el MCP conectado, y comparar los resultados.
Para determinar la tasa de éxito, compruebo si los tests unitarios siguen pasando, y si los cambios generados coinciden con los esperados mediante un archivo patch pre generado. Para pruebas a mayor escala tengo planeado usar AST testing (3), ya que el patch puede dar lugar a falsos negativos (aunque de momento no me los he encontrado).
Los resultados que muestro a continuación son la ejecución de 10 tareas de refactoring en un repositorio pequeño (~10k lineas en 125 archivos).
Los agentes conectados al MCP de refactoring redujeron en un 72,7% de tokens totales en el caso de Claude Code y un 61,9% en Codex.
La tasa de éxito de los agentes sin el MCP de refactoring fue del 60% (Claude Code) y 40% (Codex), mientras que las versiones conectadas obtuvieron un 100% de éxito (Claude Code) y 90% (Codex).
En el caso de Claude Code, al conectarlo al plugin oficial de LSP, la tasa de éxito subió al 100% gracias a la búsqueda de referncias, pero el uso de tokens se mantuvo igual debido a que las modificaciones se realizaron por inferencia. Esta via de estudio es muy reciente así que estoy en proceso de ampliarla.
El tamaño de la muestra es irrisoria, pero al menos muestran un alineamiento con la hipótesis inicial.
Siguientes pasos
Si bien las pruebas iniciales sugieren que podría haber una mejora significativa en la eficiencia para tareas de refactoring, dada la velocidad a la que evoluciona todo el área del desarrollo mediante Inteligencia Artificial generativa, es necesario profundizar más en cómo se comporta el sistema en diferentes contextos y tipos de tareas.
Como comentaba al inicio, mis motivaciones para este estudio es alertar sobre el uso ineficiente del computo que estamos realizando, y la búsqueda de mejores formas de desarrollo que mejoren tanto la eficiencia como la experiencia de desarrollo, no solo en tareas de refactoring, sino en general, en cualquier tarea de desarrollo de producto para la que podamos contruir herramientas deterministas.
Dado que el tiempo que puedo dedicar a este estudio es limitado, he creido interesante publicar este artículo con el fin de divulgar e inspirar a otras personas a trabajar en lineas similares.
En paralelo, mi objetivo es seguir trabajando para poder así publicar los resultados para diferentes tamaños de modelos, agentes, bases de código y tareas.
Espero que esta lectura te haya sido útil y si tienes cualquier duda, sugerencia o petición no dudes en contactarme.
Referencias
(1) Con fijarnos en el coste que tiene acceder via API a los modelos de Anthropic ya nos podemos hacer una idea de que no estamos pagando el coste real de inferencia cuando usamos su suscripción. Los datos que menciono salen de este artículo: Cursor Goes To War For AI Coding Dominance
(3) Aquí el benchmark utiliza AST-testing para evaluar tareas de refactoring: RefactorBench: Evaluating Stateful Reasoning in Language Agents Through Code
✉️ Apúntate a Reflexiones de Software
Recibe mis reflexiones más significativas sobre desarrollo de software, solo cuando surjan.
👷 Por aquí irán los comentarios y esas cosas. Mientras tanto puedes: