Habr describe un framework de AI para Claude con Clean Architecture y ciclo de TDD

En Habr se publicó un análisis detallado de un framework de IA que obliga al LLM a escribir código no en modo libre de "vibe-coding", sino de acuerdo con un proceso de ingeniería riguroso. El autor afirma que ya realiza casi todo su desarrollo a través de este enfoque y se basa en Clean Architecture, TDD y revisión obligatoria de código por humanos.

Cómo se estructura el flujo

El enfoque se basa en una idea simple: el buen software no es un conjunto de archivos, sino un conjunto de escenarios de comportamiento confirmados. Por eso, el trabajo no comienza con la generación de código, sino con la división del producto en historias independientes, cada una proporcionando valor de usuario separado. Para cada historia, Claude primero pasa por una fase de especificación: realiza entrevistas, forma descripciones, criterios de aceptación, diseña APIs, crea maquetas y solo entonces compila una lista de casos de prueba. Solo después de esto comienza la implementación.

El autor escribe que probó este proceso en la práctica durante 3,5 meses: aproximadamente 4.000 commits pasaron por él, 1.500 pruebas, alrededor de 350 verificaciones e2e y aproximadamente 25.000 líneas de código de producción, sin contar la capa de prueba. El elemento central del esquema es el comando /continue. Observa la lista de historias y el archivo progress.md, determina en qué etapa se detuvo el desarrollo y avanza la tarea sin selección manual de la siguiente acción.

TDD y gates

El framework no solo pide al modelo que "escriba una característica", sino que literalmente lo guía a través del ciclo ATDD y pasos TDD anidados. Para el backend, esto comienza con una prueba de aceptación roja, luego Claude desciende—a casos de uso y adaptadores, después de lo cual gradualmente "verifica" cada nivel. La lógica es la misma para otras partes del producto: primero se fija el comportamiento verificable, luego se escribe el código, no al revés. Así es como el autor intenta vincular el trabajo del modelo con la arquitectura en lugar de la suerte aleatoria.

• entrevistas y formalización de requisitos de historias
• generación de plan de prueba y casos antes del inicio de la implementación
• ciclo red-green-refactor para casos de uso, adaptadores y pruebas de aceptación
• quality gates con verificaciones de rigor de prueba, arquitectura y cobertura
• commit después de cada paso y pausa obligatoria para revisión humana

"Los prompts simples no te llevan lejos."

Además de TDD, el autor agregó quality gates de seguridad. En el paso rojo, el modelo verifica por separado qué tan rigurosas son las pruebas y si no rompen la arquitectura de prueba; en el paso verde, refactoriza el código y verifica la cobertura. Cada gate tiene una lista de verificación que el LLM debe recorrer explícitamente. Se hace especial énfasis en la gestión del contexto: cada subpaso se ejecuta en un agente separado, y progress.md permite restablecer el contexto después de cada commit y cargar solo el mínimo de datos para la siguiente pasada.

Ventanas paralelas de IDE

El lado práctico de este enfoque no es menos importante que la arquitectura en sí. Una ejecución de /continue puede tomar de 5 a 20 minutos y en pruebas pesadas—hasta 40 minutos o incluso una hora. Para no esperar en un solo hilo, el autor sugiere clonar el repositorio de demostración varias veces o usar worktrees y ejecutar historias diferentes en paralelo en IDEs separados.

En su propio proceso, hay hasta seis ventanas abiertas simultáneamente, con cuatro o cinco ocupadas por trabajo de agente, mientras que las restantes se usan para revisión, refactorización y deuda técnica. Para casos no estándar, hay comandos adicionales junto al flujo principal. El autor publicó dos repos para entrada: un Kanban de demostración en Java + React y un scaffold de framework vacío.

/task es necesario para correcciones de bugs, infraestructura y tareas largas que no caben en una historia con ritual TDD completo. /prompt-update es para mejorar el framework en sí si el modelo tropieza con un problema recurrente nuevamente. Sin embargo, el autor reconoce directamente las limitaciones: la solución creció a partir de un stack web específico, está adaptada a Clean Architecture y ATDD, consume muchos tokens y no hace que el desarrollo sea completamente autónomo. Si un bug no se detecta en la revisión, llegará tranquilamente a producción.

Qué significa esto

El enfoque muestra hacia dónde se está desplazando el desarrollo maduro de IA: de prompts individuales a pipelines reproducibles, donde el modelo funciona dentro del proceso en lugar de en lugar de él. La conclusión principal aquí es bastante rigurosa: LLM ya puede acelerar el desarrollo de producción, pero solo si se mantiene dentro de los límites de pruebas, listas de verificación, pasos cortos y control humano constante.