Un experimento de tres semanas de CodeScene le puso cifra a la modernización de código heredado con agentes, y es una cifra difícil de ignorar: unos 4.000 dólares en tokens para llevar 300.000 líneas de C desde un Code Health de 5,6 hasta un 10,0 impecable. El número viaja bien. La condición que lleva adosada viaja mal, y esa condición es el hallazgo más útil para cualquiera que planee el mismo trabajo.
Esa condición es un oráculo. Cada cambio que hicieron los agentes se contrastó con un arnés de repetición de trazas que comparaba el hash del estado de rollback del juego fotograma a fotograma. El código bajo el bisturí era una decompilación de código abierto de Street Fighter III: 3rd Strike, elegida, según el informe de CodeScene, en parte porque los dos ingenieros juegan a ese título y notarían de inmediato si algo se rompía. Un juego de lucha determinista es uno de los pocos tipos de software donde esa verificación siquiera resulta posible.
Claves
- El gasto en tokens de la mejora rondó los 4.000 dólares, que CodeScene equipara a medio salario mensual de un desarrollador frente a una estimación previa a los agentes de 12 a 18 meses de trabajo experto.
- La red de seguridad fue conductual, no basada en pruebas: un arnés de repetición que comparaba hashes de estado de rollback fotograma a fotograma, respaldado por una puntuación CodeHealth que los agentes podían optimizar.
- Las cifras que circulan como resultados —un 70% menos de defectos inducidos por IA, un 45% menos de tokens desperdiciados— son proyecciones heredadas de investigaciones previas de CodeScene y no se midieron aquí.
Qué cubrieron realmente los 4.000 dólares
El registro de actividad es considerable: 2.903 commits, 726 archivos tocados, 252.055 líneas modificadas. El alcance importa para leer esos totales. Fueron dos ingenieros a tiempo parcial, no un equipo dedicado, y el gasto cubre únicamente tokens, no salarios ni tiempo de revisión.
La retroalimentación llegó a través de un servidor MCP que puso la métrica CodeHealth de CodeScene al alcance de los agentes, de modo que cada transformación pudiera puntuarse y no solo intentarse. Emparejar una nota de calidad determinista con una comprobación de corrección igualmente determinista es lo que permitió que el bucle corriera casi sin supervisión; quítese cualquiera de las dos mitades y la cifra de rendimiento deja de significar gran cosa.
El hallazgo es el manual, no la nota
Una métrica perfecta es la parte menos transferible de este experimento. El artefacto duradero es un manual de 22 recetas y 82 notas de apoyo que los agentes fueron ensamblando sobre la marcha, poniendo nombre a las formas de transformación que se repetían y anotando las precondiciones de cada una.
Algunas entradas salen del repertorio estándar: Extraer Función, Cláusulas de Guarda, Objeto Parámetro. Tres difícilmente aparecerán en catálogo de refactorización alguno, porque describen este código en concreto. Shared Index Range fusiona bucles cuya única diferencia está en dónde empiezan y terminan. Action Parameter absorbe estructuras de control duplicadas que varían sobre todo en qué función invocan. Uniform Step Table sustituye una dispersión de llamadas heterogéneas por un despacho dirigido por tabla.
También se conservaron los resultados negativos. Numerosos intentos dejaron la métrica intacta y algunos incluso la empeoraron; quedaron escritos en el manual junto a los aciertos, algo más cercano a la disciplina de un cuaderno de laboratorio que a una limpieza de código.
La jerarquía de modelos quedó a la vista durante la ejecución. Claude Opus, de Anthropic, se encargó del grueso tras una fase inicial de tanteo, y el equipo reportó que Claude Code con Opus superaba a Codex con Sol en la tarea concreta de capturar y documentar patrones emergentes. Las ejecuciones con los modelos más pequeños, Sonnet y Terra, tendían a atascarse: los archivos se estancaban en lo que parecía un óptimo local con los malos olores de código todavía presentes.
Dónde aterrizan las objeciones
Según documentó InfoQ, la discusión que siguió en LinkedIn no giró en torno a si el experimento ocurrió, sino a qué autoriza a concluir a los demás. Quienes lo defendieron señalaron que la repetición de trazas supera un listón mucho más alto que una batería de pruebas en verde, que solo certifica que las pruebas siguen pasando.
Los reparos sobre el alcance fueron afilados. Un responsable técnico quiso saber si el resultado llegó a fusionarse y si el código de un juego de código abierto sustituye al software de producción que sostiene ingresos. Daniel Webb, CTO de NeoSee y uno de los dos ingenieros, respondió que aterrizó en main dentro de un fork mediante 54 pull requests: una fusión real, aunque no en un proyecto upstream con mantenedores externos.
Otras críticas fueron a por el vocabulario. Describir un código como perfecto ya generó rechazo por sí solo. También lo hicieron las recetas nuevas: si DRY trata del conocimiento duplicado y no de los caracteres duplicados, una receta anclada en los límites de un bucle puede estar borrando una distinción que conviene mantener. Y como Claude Code y Codex están afinados cada uno para su propio modelo, no está nada claro cómo se reparte el mérito entre la capacidad del modelo y el diseño del arnés. La arquitectura nunca se puntuó, lo que deja abierto el escenario en que las métricas de salud lucen limpias y la deuda estructural aflora un año después.
Lo que no se ha medido
Adam Tornhill, fundador de CodeScene, situó la ejecución frente a treinta años de trabajo con sistemas grandes y la llamó su primer encuentro con un rendimiento sobrehumano de la IA a escala. También subrayó que las pruebas automatizadas y las comprobaciones de equivalencia son salvaguardas absolutamente esenciales, una advertencia que fija en silencio el precio de entrada, porque un código enfermo suele estarlo en parte por carecer justamente de eso.
Las dos cifras más citadas en circulación son pronósticos. El 70% menos de defectos inducidos por IA y el 45% menos de tokens desperdiciados salen de extrapolar la investigación anterior Code Red de CodeScene, que halló que el código sano evoluciona 10 veces más rápido y arrastra 15 veces menos defectos de media. En este proyecto solo se observaron los 4.000 dólares y las tres semanas.
Comprobar el resto es el objetivo de un estudio previsto en la Universidad de Lund, que entregará a los estudiantes ambas versiones del código —una con 5,6 y otra con 10,0— para que desarrollen funciones con modelos de frontera y comparar coste y calidad directamente. Es una verificación que vale la pena hacer, sobre todo frente a la evidencia de que los correctores de errores basados en LLM rompen código que funciona más a menudo de lo que arreglan el que está roto.
Preguntas frecuentes
¿Se fusionó realmente el código refactorizado?
Se fusionó en main, pero en un fork y no en el proyecto upstream. Daniel Webb situó el total en 54 pull requests. Varios participantes en la discusión sostuvieron que lograr que un trabajo comparable fuera aceptado por un proyecto upstream activo, con mantenedores independientes, sería una prueba mucho más dura.
¿Los 4.000 dólares incluyen el tiempo de ingeniería?
No lo incluyen. Esa suma corresponde solo al gasto en tokens, a lo largo de tres semanas de dedicación parcial de dos ingenieros. CodeScene la compara con medio salario mensual de un desarrollador y calcula que la misma modernización habría consumido de 12 a 18 meses de trabajo de un desarrollador experto en la era previa a los agentes.
¿Puede funcionar este enfoque en un sistema heredado típico?
La mitad que puntúa se traslada a cualquier parte; la mitad que verifica, casi nunca. La repetición fotograma a fotograma depende de un bucle de juego determinista, y los sistemas de negocio corrientes rara vez ofrecen un equivalente. Sin un oráculo de corrección comparable, un agente puede empujar la métrica de calidad hacia arriba sin que nada confirme que el comportamiento sigue intacto.
