Un artículo en Habr describe un framework de IA que guía a Claude con Clean Architecture y un ciclo TDD

Habr ha publicado un análisis detallado de un framework de IA que obliga a un LLM a escribir código siguiendo un proceso de ingeniería estricto, y no el «vibe coding» libre. El autor asegura que ya canaliza casi todo su desarrollo con este enfoque, que se apoya en Clean Architecture, TDD y revisión humana obligatoria.

Cómo funciona el flujo

El enfoque parte de una idea sencilla: el buen software no es un conjunto de archivos, sino un conjunto de escenarios de comportamiento confirmados. Por eso el trabajo no empieza con la generación de código, sino dividiendo el producto en historias independientes, cada una con valor propio para el usuario.

Para cada historia, Claude pasa primero por una fase de especificación: realiza una entrevista, redacta la descripción y los criterios de aceptación, diseña la API, crea maquetas y solo después elabora la lista de casos de prueba. La implementación empieza a continuación.

El autor cuenta que probó el proceso en la práctica durante 3,5 meses: por él pasaron unos 4000 commits, 1500 pruebas, aproximadamente 350 comprobaciones e2e y unas 25 000 líneas de código de producción, sin contar la capa de pruebas.

El elemento central del esquema es el comando /continue. Consulta la lista de historias y el archivo progress.md, determina en qué paso se detuvo el desarrollo y hace avanzar la tarea sin que nadie elija manualmente la siguiente acción.

TDD y gates

El framework no se limita a pedirle al modelo que «escriba una funcionalidad»: lo guía literalmente por un ciclo ATDD con pasos TDD anidados. En el backend empieza con una prueba de aceptación en rojo; después Claude baja al caso de uso y a los adaptadores, y pone en verde cada nivel por etapas. La lógica es la misma para el resto del producto: primero se fija el comportamiento verificable y luego se escribe el código, no al revés. Así el autor intenta atar el trabajo del modelo a la arquitectura y no a la suerte.

• entrevista y formalización de requisitos de la historia
• generación del plan de pruebas y de los casos antes de empezar la implementación
• ciclo red-green-refactor para el caso de uso, los adaptadores y las pruebas de aceptación
• quality gates que comprueban el rigor de las pruebas, la arquitectura y la cobertura
• commit tras cada paso y pausa obligatoria para la revisión humana

«Con prompts desnudos no se llega lejos».

Sobre el TDD, el autor añadió quality gates como red de seguridad. En el paso rojo, el modelo comprueba por separado el rigor de las pruebas y que no rompan la arquitectura de pruebas; en el verde, refactoriza el código y verifica la cobertura. Cada gate tiene una lista de comprobación que el LLM debe recorrer de forma explícita.

Se da especial importancia a la gestión del contexto: cada subpaso se ejecuta en un agente distinto, y progress.md permite reiniciar el contexto tras cada commit y cargar solo los datos mínimos para la siguiente pasada.

Ventanas de IDE en paralelo

La parte práctica de este enfoque importa tanto como la arquitectura. Una sola ejecución de /continue puede durar de 5 a 20 minutos, y hasta 40 minutos o incluso una hora con pruebas pesadas. Para no esperar en un único hilo, el autor aconseja clonar el repositorio de demostración varias veces o usar worktrees y ejecutar historias distintas en paralelo en IDE separados. En su propio proceso hay hasta seis ventanas abiertas a la vez: cuatro o cinco ocupadas con el trabajo del agente y el resto dedicadas a revisión, refactorización y deuda técnica.

Para los casos atípicos hay comandos adicionales junto al flujo principal. Para empezar, el autor publicó dos repositorios: un Kanban de demostración en Java + React y un esqueleto vacío del framework. /task sirve para corrección de bugs, infraestructura y tareas largas que no encajan en una historia con el ritual TDD completo. /prompt-update sirve para mejorar el propio framework cuando el modelo vuelve a tropezar con un problema recurrente.

El autor reconoce abiertamente las limitaciones: la solución surgió de un stack web concreto, está pensada para Clean Architecture y ATDD, gasta muchos tokens y no hace el desarrollo totalmente autónomo. Si un bug no se detecta en la revisión, llegará a producción sin problemas.

Qué significa

El enfoque muestra hacia dónde se desplaza el desarrollo maduro con IA: de los prompts aislados a pipelines reproducibles en los que el modelo trabaja dentro del proceso, no en su lugar. La conclusión principal es bastante dura: un LLM ya puede acelerar el desarrollo de producción, pero solo si se le mantiene dentro de pruebas, listas de comprobación, pasos cortos y un control humano constante.