🎯 O princípio: cada prompt entrega uma camada verificável
Atomicidade de entrega significa que cada prompt entrega exatamente uma camada do sistema — completa, testável, com critério de aceitação claro. Não uma parte de uma camada. Não múltiplas camadas de uma vez. Uma camada, verificada antes de avançar.
O que torna uma camada "verificável"
- •Pode ser testada em menos de 5 minutos após a entrega
- •O resultado é binário: passou ou não passou
- •Falha no teste aponta para esta camada, não para outra
- •Não depende de camadas ainda não construídas para ser testada
📏 O tamanho certo de um prompt
A granularidade correta é a maior dificuldade de LLM coding. Dois critérios práticos definem o tamanho ideal: a entrega deve ser verificável em menos de 5 minutos, e o prompt não deve depender de mais de 2 prompts anteriores para fazer sentido.
Prompt grande demais
- ✗Entrega múltiplas camadas ao mesmo tempo
- ✗Verificação leva horas, não minutos
- ✗Bug não é atribuível a uma camada específica
- ✗Falha exige reescrita de tudo
Prompt pequeno demais
- ✗Overhead de verificação supera benefício
- ✗Inconsistências entre entregas adjacentes
- ✗Contexto perdido entre prompts muito próximos
- ✗20+ prompts para um projeto simples
🔗 Dependências entre prompts
Pré-condições explícitas — cada prompt declara o que assume do estado anterior. Não como contexto implícito na cabeça do desenvolvedor, mas como afirmações verificáveis no próprio prompt.
Dependências implícitas vs. explícitas
✗ Implícita (perigosa)
"Implemente o Stop Hook que lê o estado..."
O modelo assume o formato do estado. Se o prompt anterior usou formato diferente, bugs silenciosos.
✓ Explícita (segura)
"O prompt anterior criou state.json com o schema {'phase': string, 'version': int}. Implemente o Stop Hook que lê este arquivo e..."
Dependência documentada. O modelo sabe exatamente o que esperar.
✅ A verificação entre prompts
O gate de verificação entre prompts é o momento mais importante do processo. É quando você confirma que a camada entregue é sólida antes de construir sobre ela. Pular este gate é a principal causa de reescritas completas.
O protocolo de gate
🔄 Quando um prompt falha
Falha não é exceção — é o estado normal de desenvolvimento. O protocolo de regressão define como responder: identificar a camada que falhou, regredir apenas ela, re-executar com contexto adicional. Nunca reescrever tudo.
Identificar a camada que falhou
O teste que falhou pertence a qual camada? Se o prompt 5 falha em algo que deveria ter sido estabelecido no prompt 3, o problema está no prompt 3.
Regredir apenas a camada com falha
Reverter os arquivos da camada identificada para o estado anterior. Preservar tudo que foi verificado — apenas a camada com falha é regredida.
Re-executar com contexto de diagnóstico
Re-executar o prompt da camada com informação adicional: "o prompt anterior falhou porque X. Corrija antes de prosseguir."
📋 Template de prompt incremental
Um prompt sem estrutura obriga o modelo a fazer suposições. O template de cinco seções elimina ambiguidade — contexto, estado verificado, entrega esperada, invariantes e critério de aceitação são sempre explícitos.
Template: 5 seções
## CONTEXTO DO PROJETO
Nome, propósito, stack tecnológico. Referência ao SPEC se existir.
## ESTADO ATUAL VERIFICADO
O que foi construído e verificado nos prompts anteriores. Formato dos arquivos existentes.
## ENTREGA ESPERADA
O que este prompt deve produzir. Arquivos a criar ou modificar. Comportamento a implementar.
## INVARIANTES A RESPEITAR
As primitivas de segurança que se aplicam a esta camada. O que não pode ser violado.
## CRITÉRIO DE ACEITAÇÃO
Os testes concretos que confirmam que a entrega está correta. O que será verificado antes de avançar.
✅ Resumo do Módulo 3.4
Próximo Módulo:
3.5 — Testando Camada por Camada