Claude Code y Subagentes Redujeron la Reescritura de Proyecto Legacy de Tres Meses a Una Semana

La diferencia entre tres meses y una semana en esta historia se explica no porque los modelos de repente comenzaron a escribir código perfecto, sino porque el autor dejó de usar IA como un autocompletado inteligente y la transformó en un pipeline de ingeniería completo. Usando dos proyectos Go de escala similar como ejemplo, muestra: cuando el legado se refactoriza manualmente e intuitivamente, la velocidad se ve limitada por el caos; cuando el modelo tiene roles, procedimientos, revisión y un bucle de pruebas, la reescritura del monolito se acelera exponencialmente. Hace un año, el punto de partida era la familiar deuda técnica posterior a un MVP.

El proyecto tenía un main.go de aproximadamente dos mil líneas, donde la lógica empresarial, la configuración, los manejadores HTTP, las operaciones de base de datos y otro código de soporte estaban mezclados en un lugar. Tal estructura puede sobrevivir al lanzamiento inicial del producto, pero no escala bien: cualquier cambio causa efectos secundarios, el código es difícil de dividir en zonas de responsabilidad, y las pruebas se convierten en dolor adicional en lugar de apoyo.

El autor recuerda que en aquel entonces estaba tirando el sistema hacia una arquitectura normal poco a poco, con pruebas improvisadas y constante reverificación manual. Realizó la primera refactorización en Cursor e invirtió aproximadamente tres meses en ella. Fue un proceso cuidadoso, casi quirúrgico: extraer un bloque, verificar si el comportamiento se rompió, luego pasar al siguiente.

Un proyecto reciente de escala similar produjo resultados muy diferentes. El autor tomó Claude Code, modelo Opus, conectó tres subagendes revisores y construyó alrededor de ellos aproximadamente treinta skills — escenarios repetibles para operaciones típicas. Como resultado, la reescritura tomó una semana, con una porción significativa de ese tiempo no dedicada a la migración de código en sí, sino a la capa BDD sobre la implementación.

Según su evaluación, sin escenarios en godog la tarea podría caber en aproximadamente tres días. La esencia del artículo no es que una herramienta específica resultara más fuerte que otra, sino que el autor cambió su forma de trabajar. Contrasta su práctica con consejos populares de la serie "dé a la red neuronal un buen prompt y espere el resultado".

En el legado real esto no es suficiente: los modelos necesitan no solo contexto, sino también un entorno gestionado. Los subagendes proporcionan una perspectiva paralela sobre los cambios y atrapan errores antes de que lleguen a la rama principal. Los skills eliminan la rutina, estandarizan pasos y reducen la cantidad de decisiones que deben tomarse nuevamente.

BDD añade un contrato de comportamiento externo para que la reescritura no se convierta en la sustitución silenciosa de lógica empresarial por una nueva estructura bonita. Por eso el autor llama al resultado más importante no simplemente aceleración, sino la aparición de un toolchain funcional nivel85. Esencialmente, este es un conjunto de acuerdos entre una persona, un modelo y agentes auxiliares: cómo descomponer una tarea, cómo verificar resultados intermedios, cómo limitar la libertad de generación y dónde conectar pruebas.

Tal enfoque convierte la IA no en un botón mágico, sino en un participante disciplinado del desarrollo. Al mismo tiempo, el autor no está intentando vender una receta universal. Por el contrario, enfatiza que incluso en la configuración montada hay escollos: contexto extra, descomposición incorrecta, verificaciones débiles, o momento incorrectamente elegido para la automatización fácilmente se comen la ganancia.

La conclusión principal aquí es práctica: la aceleración en el desarrollo asistido por IA nace no de un modelo, sino del sistema operativo a su alrededor. Si un equipo continúa trabajando con IA como una ventana de chat para consejos ocasionales, el código monolítico seguirá siendo reescrito lentamente y nerviosamente. Pero si transforma el modelo en parte del proceso — con roles, revisión, escenarios y técnicas fijas — incluso el legado pesado puede ser desarmado varias veces más rápido sin abandonar completamente la disciplina de ingeniería.

Y esto, quizás, sea la principal lección del artículo.