Artigo no Habr descreve framework de IA que conduz o Claude com Clean Architecture e ciclo TDD

O Habr publicou uma análise detalhada de um framework de IA que obriga um LLM a escrever código seguindo um processo rígido de engenharia, e não o "vibe coding" livre. O autor afirma que já conduz quase todo o seu desenvolvimento com essa abordagem, que se apoia em Clean Architecture, TDD e revisão humana obrigatória.

Como funciona o fluxo

A abordagem parte de uma ideia simples: bom software não é um conjunto de arquivos, e sim um conjunto de cenários de comportamento confirmados. Por isso o trabalho não começa pela geração de código, mas pela divisão do produto em histórias independentes, cada uma entregando valor próprio ao usuário.

Para cada história, o Claude passa primeiro por uma etapa de especificação: faz uma entrevista, redige a descrição e os critérios de aceitação, projeta a API, cria protótipos e só então monta a lista de casos de teste. A implementação começa depois disso.

O autor escreve que testou o processo na prática ao longo de 3,5 meses: passaram por ele cerca de 4 mil commits, 1500 testes, aproximadamente 350 verificações e2e e cerca de 25 mil linhas de código de produção, sem contar a camada de testes.

O elemento central do esquema é o comando /continue. Ele consulta a lista de histórias e o arquivo progress.md, identifica em que passo o desenvolvimento parou e avança a tarefa sem que ninguém escolha manualmente a próxima ação.

TDD e gates

O framework não se limita a pedir ao modelo que "escreva uma funcionalidade": ele o conduz literalmente por um ciclo de ATDD com passos de TDD aninhados. No backend, começa com um teste de aceitação vermelho; depois o Claude desce até o caso de uso e os adaptadores, deixando cada nível verde por etapas. A lógica é a mesma para as demais partes do produto: primeiro se fixa o comportamento verificável, depois se escreve o código, e não o contrário. Assim o autor tenta amarrar o trabalho do modelo à arquitetura, e não à sorte.

• entrevista e formalização dos requisitos da história
• geração do plano de testes e dos casos antes do início da implementação
• ciclo red-green-refactor para o caso de uso, os adaptadores e os testes de aceitação
• quality gates que verificam o rigor dos testes, a arquitetura e a cobertura
• commit após cada passo e pausa obrigatória para revisão humana

"Com prompts soltos não se vai longe."

Sobre o TDD, o autor acrescentou quality gates como rede de segurança. No passo vermelho, o modelo verifica separadamente o rigor dos testes e se eles não quebram a arquitetura de testes; no verde, refatora o código e confere a cobertura. Cada gate tem um checklist que o LLM precisa percorrer de forma explícita.

Há ênfase especial no gerenciamento de contexto: cada subpasso roda em um agente separado, e o progress.md permite zerar o contexto após cada commit e carregar apenas o mínimo de dados para a próxima rodada.

Janelas de IDE em paralelo

O lado prático dessa abordagem importa tanto quanto a arquitetura. Uma única 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 esperar em uma única thread, o autor aconselha clonar o repositório de demonstração várias vezes ou usar worktrees e rodar histórias diferentes em paralelo, em IDEs separadas. No processo dele, chegam a ficar seis janelas abertas ao mesmo tempo: quatro ou cinco ocupadas com o trabalho do agente e as demais com revisão, refatoração e dívida técnica.

Para casos fora do padrão, há comandos adicionais ao lado do fluxo principal. Para começar, o autor publicou dois repositórios: um Kanban de demonstração em Java + React e um esqueleto vazio do framework. O /task serve para correção de bugs, infraestrutura e tarefas longas que não cabem em uma história com o ritual completo de TDD. O /prompt-update serve para aprimorar o próprio framework quando o modelo volta a tropeçar num problema recorrente.

O autor reconhece abertamente as limitações: a solução nasceu de uma stack web específica, é voltada a Clean Architecture e ATDD, gasta muitos tokens e não torna o desenvolvimento totalmente autônomo. Se um bug não for pego na revisão, ele vai tranquilamente para produção.

O que isso significa

A abordagem mostra para onde caminha o desenvolvimento maduro com IA: de prompts isolados para pipelines reproduzíveis, nos quais o modelo trabalha dentro do processo, e não no lugar dele. A conclusão principal é bastante dura: o LLM já pode acelerar o desenvolvimento de produção, mas só se for mantido dentro de testes, checklists, passos curtos e controle humano constante.