🚫 Anti-padrão "tudo de uma vez"
O pedido gigante parece eficiente. Um prompt, uma resposta, pronto. Na prática é onde a maioria dos desastres começa. Três problemas estruturais sempre aparecem.
Problema 1 — Checkpoint ausente
Quando o Claude termina "tudo", não há ponto intermediário salvo. Se algo no meio saiu errado, o único rollback é voltar para antes de começar — perdendo também as partes corretas.
Exemplo: Você pediu 5 coisas; 4 saíram certas, 1 errada. Não dá para reverter só a errada sem mexer nas outras.
Problema 2 — Difícil reverter parte
Mudanças entrelaçadas: o passo 2 importa função criada no passo 1, que usa tipo do passo 3. Reverter um força cascata.
Exemplo: Refactor grande: desfazer a mudança de nomes quebra os imports e os testes gerados juntos.
Problema 3 — Contexto satura
Um turno gigante lê muitos arquivos, gera muito output, produz muitos logs. Tudo isso fica no contexto do próximo turno. Você entra no turno 2 já com 40k de "bagagem".
Exemplo: Primeiro turno: lê 8 arquivos, gera 600 linhas. Já consumiu 25k tokens.
⚠️Sinal de que você está no anti-padrão
Se o seu primeiro prompt começa com qualquer um destes:
- •"implementa X, Y e Z"
- •"faz o refactor completo de ..."
- •"agora só precisa fazer tudo que está no plano"
- •"faz o que achar melhor"
Todos provocam um turno gigante. Todos geram os 3 problemas acima.
⚡ Um passo por vez é mais rápido
Contra-intuitivo: mais turnos = menos custo. O motivo é o prompt caching. Cada turno pequeno reutiliza o prefixo cacheado do anterior (0,1× do preço). Um turno gigante não.
Por que blocos curtos casam com cache
Custo estimado para a mesma entrega
| Abordagem | Turnos | Input total | Output total | Custo |
|---|---|---|---|---|
| Tudo de uma vez | 1 | 80k (sem cache útil) | ~8k | US$ 0,36 |
| 5 blocos | 5 | 20k + 4 × cache reads | ~8k total | US$ 0,15 |
Valores ilustrativos em Sonnet 4.6. Blocos curtos custam metade.
🧠O paradoxo em uma frase
"Conversar mais, gastar menos." Cada turno curto aproveita o trabalho de caching já feito. O turno gigante reescreve contexto do zero.
💡Não tenha medo de "ser chato"
Entrar com "faça o passo 1" parece micromanagement. Não é. É o padrão que otimiza cache, reduz retrabalho e mantém checkpoint. Claude não reclama — na verdade responde melhor com escopo estreito.
🛑 Checkpoints entre etapas
Um checkpoint é uma pausa explícita entre blocos onde você confirma estado e libera o próximo. Sem checkpoint, blocos viram uma avalanche.
Como um checkpoint soa na prática
Passo 1 concluído. Criei
src/auth/jwt.ts, adicionei testes. Posso seguir?Três turnos mínimos para um bloco. Mas cada um rápido e barato.
🗣️Frases que provocam checkpoints
Ou coloque no CLAUDE.md: "Sempre aguardar confirmação entre passos do plano."
⏪Checkpoint + /rewind = segurança real
Cada checkpoint é automaticamente um candidato para /rewind. Se o passo 3 der ruim, você volta para o estado após o passo 2 — sem perder os 1 e 2.
✓ Checkpoint bom
- ✓Claude resume o que fez
- ✓Você valida (rodou teste, abriu arquivo)
- ✓Confirmação explícita para o próximo
✗ Checkpoint ruim
- ✗"feito" sem especificar o quê
- ✗Você não valida, só responde "ok"
- ✗"continua" sem revisar nada
🔀 Separar dúvidas de execução
Não misture perguntas com execução. Quando você pede "implementa X e me explica Y", o output vira uma salada: explicação longa + código + explicação + próximos passos. Cada turno deve ter um propósito.
✗ Misturado
Output: 400 linhas de explicação + 50 de código. Cache não ajuda. Leitura demora. Difícil revisar.
✓ Separado
Cada turno enxuto. Output focado. Revisar rápido.
4 tipos de turno — não misture entre si
| Tipo | Exemplo | Output esperado |
|---|---|---|
| Execução | "faz o passo 2" | Código + diff curto |
| Pergunta | "por que escolheu bcrypt?" | Explicação |
| Decisão | "Redis ou in-memory?" | Trade-offs |
| Investigação | "onde está o middleware de CORS?" | Referência + leitura |
🎯Regra rápida
Se o seu prompt tem "e" juntando duas ações, prove que é a mesma categoria. "implementa X e testa X" pode ser 1 turno. "implementa X e explica Y" são 2 turnos.
📏 Tamanho ideal do bloco
Um bloco ideal: 5–10 minutos de trabalho real, toca 1–2 arquivos, produz algo testável. Se demora mais ou mexe em mais, você tem dois blocos.
Régua: tamanho de bloco por dimensão
✓ Blocos bem dimensionados
- •Adicionar validação zod em 1 endpoint
- •Criar teste para 1 função
- •Migrar 1 componente para TypeScript
- •Corrigir 1 bug específico
✗ Blocos inchados
- •"Adicionar validação em todos os endpoints"
- •"Criar testes para todos os services"
- •"Migrar o projeto inteiro para TS"
- •"Resolver todos os bugs da sprint"
🧪Teste de testabilidade
Se o bloco tem um teste/check claro que comprova conclusão (teste passa, endpoint responde 200, migration aplica) — é um bloco. Se termina em "acho que está pronto" — era dois blocos.
📊 Exemplo: refactor de 4 blocos
Caso real: refatorar um serviço de autenticação (AuthService — 600 linhas, múltiplas responsabilidades). Vamos comparar as duas abordagens com números.
1 bloco vs 4 blocos — mesmo trabalho
| Métrica | 1 bloco (tudo) | 4 blocos |
|---|---|---|
| Turnos totais | ~18 (com correções) | ~14 |
| Input acumulado | ~1,1M tokens | ~420k tokens |
| Cache hit rate | ~20% | ~75% |
| Tempo humano | ~60 min (muito revisão) | ~40 min |
| Retrabalho | 2 passos refeitos | 0 |
| Qualidade final | Média (precisou ajuste) | Alta (testes ok de cara) |
| Custo (Sonnet 4.6) | ~US$ 4,20 | ~US$ 1,10 |
menor custo, menos tempo humano, melhor qualidade. O mesmo refactor.
Como os 4 blocos foram estruturados
Blocos pequenos fecham. Turnos gigantes arrastam.
Menos ambição por turno = mais entrega por sessão.
📋Resumo do Módulo
Próximo módulo:
2.3 — 🧹 /clear, /rewind, /compact — Reset Cedo
Três ferramentas oficiais para quando resetar, voltar, ou compactar.