Habr detalha um framework de AI para Claude com Clean Architecture e ciclo de TDD

No Habr, foi publicada uma análise detalhada de um framework de IA que força o LLM a escrever código não em modo livre de "vibe-coding", mas de acordo com um processo de engenharia rigoroso. O autor afirma que já conduz quase todo o seu desenvolvimento por meio dessa abordagem e se baseia em Clean Architecture, TDD e revisão obrigatória de código por humanos.

Como o fluxo é estruturado

A abordagem se baseia em uma ideia simples: bom software não é um conjunto de arquivos, mas um conjunto de cenários de comportamento confirmados. Por isso, o trabalho não começa com geração de código, mas com a divisão do produto em histórias independentes, cada uma fornecendo valor de usuário separado. Para cada história, Claude primeiro passa por uma fase de especificação: conduz entrevistas, forma descrições, critérios de aceitação, projeta APIs, cria mockups e só depois compila uma lista de casos de teste. Somente depois disso começa a implementação.

O autor escreve que testou esse processo na prática ao longo de 3,5 meses: aproximadamente 4.000 commits passaram por ele, 1.500 testes, cerca de 350 verificações e2e e cerca de 25.000 linhas de código de produção, sem contar a camada de teste. O elemento central do esquema é o comando /continue. Ele analisa a lista de histórias e o arquivo progress.md, determina em qual estágio o desenvolvimento parou e avança a tarefa sem seleção manual da próxima ação.

TDD e gates

O framework não apenas pede ao modelo para "escrever um recurso", mas literalmente o guia pelo ciclo ATDD e etapas TDD aninhadas. Para o backend, isso começa com um teste de aceitação vermelho, depois Claude desce para casos de uso e adaptadores, após o que gradualmente "deixa verde" cada nível. A lógica é a mesma para outras partes do produto: primeiro o comportamento verificável é fixado, depois o código é escrito, não o contrário. Assim é como o autor tenta vincular o trabalho do modelo à arquitetura em vez de sorte aleatória.

• entrevistas e formalização de requisitos da história
• geração de plano de teste e casos antes do início da implementação
• ciclo red-green-refactor para casos de uso, adaptadores e testes de aceitação
• quality gates com verificações de rigor de teste, arquitetura e cobertura
• commit após cada etapa e pausa obrigatória para revisão humana

"Prompts simples não levam você longe."

Além do TDD, o autor adicionou quality gates de segurança. Na etapa vermelha, o modelo verifica separadamente como os testes são rigorosos e se não quebram a arquitetura de teste; na etapa verde, refatora o código e verifica a cobertura. Cada gate tem uma lista de verificação que o LLM deve percorrer explicitamente. Ênfase especial é colocada no gerenciamento de contexto: cada subetapa é executada em um agente separado, e progress.md permite redefinir o contexto após cada commit e carregar apenas o mínimo de dados para a próxima passagem.

Janelas paralelas de IDE

O lado prático dessa abordagem não é menos importante que a arquitetura em si. Uma execução de /continue pode levar de 5 a 20 minutos e em testes pesados—até 40 minutos ou até uma hora. Para não ficar esperando em uma thread, o autor sugere clonar o repositório de demonstração várias vezes ou usar worktrees e executar histórias diferentes em paralelo em IDEs separadas.

Em seu próprio processo, até seis janelas estão abertas simultaneamente, com quatro ou cinco ocupadas pelo trabalho do agente, enquanto as restantes são usadas para revisão, refatoração e débito técnico. Para casos não-padrão, existem comandos adicionais ao lado do fluxo principal. O autor publicou dois repos para entrada: um Kanban de demonstração em Java + React e um scaffold de framework vazio.

/task é necessário para correções de bugs, infraestrutura e tarefas longas que não cabem em uma história com ritual TDD completo. /prompt-update é para melhorar o framework em si se o modelo tropeçar em um problema recorrente novamente. No entanto, o autor reconhece diretamente as limitações: a solução cresceu de um stack web específico, é adaptada para Clean Architecture e ATDD, consome muitos tokens e não torna o desenvolvimento totalmente autônomo. Se um bug não for detectado na revisão, ele calmamente chegará à produção.

O que isso significa

A abordagem mostra para onde o desenvolvimento maduro de IA está se deslocando: de prompts únicos para pipelines reproduzíveis, onde o modelo trabalha dentro do processo em vez de no lugar dele. A conclusão principal aqui é bastante rigorosa: LLM já pode acelerar o desenvolvimento de produção, mas apenas se for mantido dentro dos limites de testes, listas de verificação, etapas curtas e controle humano constante.