Claude Code y los subagentes reducen la reescritura de un proyecto legacy de tres meses a una semana

La diferencia entre tres meses y una semana en esta historia no se explica porque los modelos escriban de pronto código perfecto, sino porque el autor dejó de usar la IA como un autocompletado inteligente y la convirtió en una cadena de montaje de ingeniería completa. Con dos proyectos Go de la misma escala, muestra que cuando el legacy se desenreda a mano y por intuición, la velocidad se topa con el caos. Cuando el modelo tiene roles, procedimientos, revisión y un circuito de pruebas, la reescritura de un monolito se acelera varias veces.

Hace un año, el punto de partida era la deuda técnica tras un MVP, algo que a muchos les resultará familiar. El proyecto tenía un único main.go de unas dos mil líneas, donde se mezclaban la lógica de negocio, la configuración, los handlers HTTP, el acceso a la base de datos y otros elementos auxiliares.

Una estructura así puede sobrevivir al lanzamiento temprano de un producto, pero aguanta mal el crecimiento: cualquier cambio arrastra efectos secundarios, el código es difícil de dividir en áreas de responsabilidad y las pruebas dejan de ser un apoyo para convertirse en un dolor añadido. El autor recuerda que entonces llevó el sistema a una arquitectura decente por partes, con pruebas caseras y una constante verificación manual.

Hizo la primera refactorización en Cursor y le dedicó unos tres meses. Fue un proceso cuidadoso, casi quirúrgico: extraer un bloque, comprobar si el comportamiento se había roto y pasar al siguiente.

Un proyecto reciente de la misma escala dio un resultado muy distinto. El autor tomó Claude Code con el modelo Opus, conectó tres subagentes revisores y montó a su alrededor unas treinta skills, es decir, escenarios repetibles para operaciones típicas. La reescritura llevó una semana, y buena parte de ese tiempo no se fue en trasladar el código, sino en la capa BDD sobre la implementación. Según su estimación, sin los escenarios de godog la tarea podría haberse resuelto en unos tres días.

Lo esencial del artículo no es que una herramienta concreta resultara más potente que otra, sino que el autor cambió su forma de trabajar. Contrapone su práctica a los consejos populares del tipo «dale a la red neuronal un buen prompt y espera el resultado». En un legacy real eso no basta: el modelo necesita no solo contexto, sino un entorno controlado.

Los subagentes aportan una mirada paralela sobre los cambios y detectan errores antes de que lleguen a la rama principal. Las skills eliminan la rutina, estandarizan los pasos y reducen el número de decisiones que hay que tomar de nuevo. BDD añade un contrato externo de comportamiento para que la reescritura no se convierta en una sustitución silenciosa de la lógica de negocio por una estructura nueva y bonita.

Por eso el autor considera que el resultado más importante no es solo la aceleración, sino la aparición de un toolchain funcional, level85. En esencia, es un conjunto de acuerdos entre la persona, el modelo y los agentes auxiliares: cómo descomponer una tarea, cómo verificar los resultados intermedios, cómo limitar la libertad de generación y dónde incorporar pruebas. Este enfoque convierte a la IA no en un botón mágico, sino en un participante disciplinado del desarrollo.

El autor no intenta vender una receta universal. Al contrario, subraya que incluso con la configuración montada quedan trampas: exceso de contexto, una descomposición errónea, comprobaciones débiles o un momento mal elegido para automatizar pueden comerse fácilmente la ganancia. La conclusión principal es práctica: la aceleración en el desarrollo asistido por IA no nace de un solo modelo, sino del sistema operativo que lo rodea.

Si un equipo sigue tratando la IA como una ventana de chat para consejos puntuales, el código monolítico se seguirá reescribiendo de forma lenta y nerviosa. Pero si el modelo pasa a formar parte del proceso, con roles, revisión, escenarios y técnicas fijas, incluso un legacy pesado puede desmontarse varias veces más rápido sin renunciar a la disciplina de ingeniería. Esa es, quizá, la principal lección del artículo.