Limpiar un proyecto de un millón de líneas con 1.393 subagentes

A quién le sirve. Equipos de desarrollo con un proyecto grande lleno de código repetido o sin uso, aunque el método (dividir el trabajo, comprobar cada paso y revisar) vale para cualquier tarea grande.

Qué hicieron

Teknium dio a su agente Hermes un objetivo permanente con /goal y una habilidad de desarrollo que el agente había ido acumulando. El coordinador dividió el código en 36 grupos que no se pisaban y escribió instrucciones para los trabajadores. Cada uno usó su propia copia del repositorio, guardó cambios tras cada paso comprobado y verificó las interfaces contra el original. Un token caducado detuvo el proceso a los 50 minutos; otra sesión preparó un relevo y se retomó.

Cómo salió

El Python sin contar pruebas pasó de 1.063.826 a 698.363 líneas (un 34,4 % menos), y el archivo gateway/run.py de 34.847 a 5.512. Los revisores encontraron errores que las pruebas no detectaron, y seis archivos seguían superando las 5.000 líneas.

Conviene saber

El gasto en modelos fue de unos 19.300 $ en la ejecución principal y cerca de 25.000 $ con los retoques, sin contar la revisión humana. La revisión detectó nombres públicos eliminados que usan los complementos y excepciones alteradas en unos 65 sitios.

Qué necesitas

• Un proyecto de código en Git con pruebas automáticas que se puedan lanzar con un solo comando
• Hermes Agent (el del caso) o un agente de programación parecido, como Claude Code o Codex
• Una rama o copia de seguridad del proyecto para poder volver atrás
• Presupuesto para el uso de modelos de IA, porque una limpieza así consume mucho
• Tiempo de una persona para revisar los cambios antes de aceptarlos

Cómo hacerlo tú, paso a paso

1. Define un objetivo que puedas medir, por ejemplo menos líneas de código sin que fallen las pruebas, y apunta cómo lo vas a medir.
2. Comprueba que las pruebas actuales pasan antes de empezar. Si ya fallan, el agente no podrá saber si rompe algo.
3. Pide al agente que lea el proyecto y proponga cómo dividirlo en partes independientes que no se pisen entre sí, por carpetas o módulos.
4. Haz que cada parte se trabaje en su propia rama o copia del repositorio, para que los cambios no se mezclen.
5. Exige que después de cada cambio lance las pruebas y compruebe que los nombres y funciones que usan otras partes o complementos siguen igual que en el original.
6. Si el trabajo es largo, pide que guarde su progreso y escriba notas de relevo, por si la sesión se corta. En el caso, una credencial caducó y hubo que retomarlo.
7. Revisa tú los cambios antes de fusionarlos. Busca nombres públicos eliminados y errores alterados sin querer, que las pruebas no siempre detectan.

Revisa mi proyecto en [ruta o nombre del repositorio] y busca código muerto, lógica duplicada y módulos demasiado complicados. Divide la limpieza en partes independientes, trabaja cada una en una rama aparte y ejecuta [comando de pruebas] después de cada cambio. Habrás terminado cuando entregues un resumen de una sola propuesta de cambios (pull request) con las líneas eliminadas y los resultados de las pruebas. Detente a esperar mi revisión antes de fusionar o borrar nada.

Consejos

• Empieza por una parte pequeña del proyecto, no por todo. Mide cuánto cuesta y qué tal sale antes de ampliar.
• Pide una sola propuesta de cambios (pull request) con las líneas eliminadas y los resultados de las pruebas. Así la revisión es manejable.
• No te fíes solo de las pruebas: en el caso, los revisores encontraron fallos que ellas no veían.

Preguntas frecuentes

Fuentes

• nousresearch.com ↗

En el directorio desde el 3 de octubre de 2026.