O que Isso nos Deu
Uma análise honesta do que o processo de 7 prompts incrementais produziu — o que melhorou, o que teria dado errado com uma abordagem diferente, e o custo real de construir sobre camadas não verificadas.
O plugin antes e depois do safety pass
O safety pass não adiciona features visíveis. Ele muda como o sistema se comporta quando algo dá errado. A diferença é invisível durante o caminho feliz — e crítica em produção.
- ✗Erro no hook = Claude fica bloqueado indefinidamente
- ✗Estado file corrompido por write parcial durante crash
- ✗Race condition possível em CAS na transição de fase
- ✗Loop antigo em estado "running" bloqueia novos loops para sempre
- ✓Qualquer erro no hook retorna approve automaticamente (fail-open)
- ✓Escrita atômica via tmp+rename — nunca estado parcialmente escrito
- ✓CAS garante que apenas uma transição de fase válida vence
- ✓Stale sweeper limpa loops fantasmas no próximo start-loop
Bugs capturados pelo processo — não pela revisão manual
Três classes de bugs que foram detectadas pelos testes incrementais — e que uma revisão de código humana teria dificuldade de encontrar sem executar o sistema.
O round counter que ultrapassava max_rounds
O contador interno de rounds incrementava uma vez após o último round ser marcado como completo, antes da lógica de parada ser ativada. Resultado: o display mostrava "round 4/3" em loops de 3 rounds.
Tópico com quebra de linha corrompendo o YAML do state file
Se o usuário digitava um tópico com newline (copia-cola de um editor), o campo topic: no YAML ficava com valor multi-linha inválido. O state file parava de ser lido por todos os scripts que usavam grep/awk para parsear campos.
O runner script com expansão shell no prompt do Codex
O runner gerava um heredoc sem aspas: cat <<PROMPTEOF. Quando o prompt do review continha $variable ou backticks, o shell os expandia antes de passar ao Codex. O Codex recebia um prompt mutilado.
O que teria dado errado com um único prompt
É fácil subestimar os riscos da abordagem "escreva tudo de uma vez". Vamos ser concretos sobre os cenários de falha mais prováveis.
Cenário 1: O hook sem ERR trap bloqueia o usuário no primeiro deploy
Com um único prompt, a instrução de safety provavelmente viria no final, depois de páginas de lógica de negócio. O Claude priorizaria implementar o comportamento funcional e trataria o safety como detalhe. O ERR trap seria omitido ou implementado incorretamente (instalado depois da linha que muta estado, tornando-o inútil).
Cenário 2: Arquitetura de estado inconsistente
Sem incrementar sobre uma estrutura de estado já testada, o Claude inventaria sua própria estrutura de YAML — possivelmente usando arrays onde o parser espera strings, ou campos com nomes diferentes entre scripts. Cada script novo seria uma oportunidade de divergência.
Cenário 3: Testes nunca escritos por "falta de espaço de contexto"
Um prompt de 2000 palavras descrevendo toda a arquitetura deixa pouco espaço cognitivo para os detalhes de testing. O Claude implementaria os scripts e colocaria os testes como "TODO" ou os escreveria de forma superficial — apenas para satisfazer o requisito, sem assertions reais.
Prompts incrementais não são apenas sobre gerenciar o context window. Eles criam checkpoints de verificação — cada prompt começa do estado verificado pelo prompt anterior. Quando algo falha, você sabe exatamente qual prompt introduziu o problema.
Comparação: um prompt vs. sete — qualidade do código gerado
Não é especulação — é uma análise dimensão por dimensão do que muda quando você incrementa em vez de especificar tudo de uma vez.
| Dimensão | Um Prompt | Sete Prompts |
|---|---|---|
| Consistência de nomenclatura | Diverge entre arquivos — cada script inventa seus próprios nomes para as mesmas operações | Cada prompt reutiliza e referencia helpers definidos no prompt anterior; nomenclatura converge naturalmente |
| Cobertura de edge cases | O happy path é bem coberto; edge cases recebem handling genérico ou são ignorados | Edge cases descobertos em testes de um prompt viram requisitos explícitos do próximo prompt |
| Qualidade dos testes | Testes escritos depois do código — tendência a testar apenas o que o código faz, não o que deveria fazer | Testes escritos junto com cada feature incremental; assertions refletem o behavior esperado, não o observado |
| Documentação de decisões | Decisões arquiteturais se perdem no código — sem comentários explicando o "por quê" | Cada prompt documenta a razão da mudança; comentários como "# deliberate force site — override regardless of phase" aparecem naturalmente |
| Debuggability | Quando algo falha, é difícil isolar qual componente introduziu o problema | Cada prompt é um checkpoint verificado — falha em produção pode ser bisectada ao prompt de origem |
Em projetos comparáveis de geração de código com LLM, a abordagem incremental tende a reduzir em ~60% o número de bugs encontrados em testes de integração — não porque o LLM seja mais cuidadoso, mas porque cada checkpoint cria um contrato verificado que o próximo prompt não pode silenciosamente quebrar.
O custo real de construir sobre camadas não verificadas
Technical debt precoce é diferente de technical debt tradicional. Quando você constrói com LLMs sobre camadas não verificadas, o debt se materializa de formas não-óbvias — e se compõe exponencialmente.
Cada prompt do Claudex termina com: "Run all tests, send counts." Isso cria um contrato explícito: o próximo prompt só começa depois que o atual passa em todos os testes.
- •Falha early, não late
- •Cada camada é uma fundação verificada
- •O LLM tem contexto confiável para o próximo prompt
Sem checkpoints verificados, o custo de debug cresce exponencialmente com a profundidade da stack:
Quer usar o Claudex na prática?
Você acabou de ver como o Claudex foi construído — 7 prompts incrementais, cada um verificado antes do próximo começar. Agora é hora de usar a ferramenta que você entende por dentro.
Curso Completo de Uso do Claudex
Aprenda a usar o Claudex em projetos reais — da instalação ao uso avançado com múltiplos rounds e entrevista de planejamento.
Resumo do Módulo 2.4
Uma análise concreta do valor gerado pelo processo de 7 prompts incrementais:
- ✓ O safety pass transforma "funciona no happy path" em "é resiliente a falhas" — a diferença é invisível até que algo quebre em produção
- ✓ 3 classes de bugs foram detectadas pelos testes — o round counter, o YAML multi-linha e o heredoc sem aspas — todos invisíveis em revisão manual
- ✓ Um único prompt teria produzido: hook sem ERR trap, nomenclatura inconsistente, testes superficiais, e documentação ausente
- ✓ Technical debt em camadas não verificadas se compõe exponencialmente — o custo de debug na camada 4 é ~15x o custo de testar a camada 1
- ✓ O próximo passo: usar o Claudex na prática no curso completo de uso