Pipeline plan, loop, review
Imagine assim: Um diretor de cinema: primeiro o roteiro (plan), depois as filmagens (loop), depois a edicao e aprovacao (review). Tres fases, cada uma com seu papel.
O pipeline de ouro para tarefas complexas: (1) ative plan mode e peca um plano detalhado, (2) refine o plano 2-3 vezes, (3) aprove e mude para loop mode para executar, (4) quando o loop terminar, revise o resultado com git diff antes de commitar. Tres fases, cada uma com seu proposito.
A fase de review e crucial e muitos pulam. Depois que o loop termina, rode git diff e leia as mudancas. Pergunte ao Claude: "revise o diff e confirme que tudo esta de acordo com o plano". Isso pega erros que o loop nao detectou (ex: mudancas semanticas que passam nos testes mas mudam o comportamento).
Em 1 frase: plan, loop, review. Tres fases, nenhuma pulavel. O review pega o que o loop nao ve.
Handoff entre modos
Imagine assim: O bastao numa corrida de revezamento: se voce passa mal, o proximo corredor tropeça. O handoff entre plan e loop precisa ser limpo para nao perder contexto.
O momento critico e a transicao do plano para a execucao. Ao aprovar o plano, inclua uma instrucao explicita: "agora execute o plano acima, passo por passo, validando entre cada passo". Isso garante que o Claude segue o plano em vez de improvisar.
Se o plano e longo, quebre a execucao em fases: "execute os passos 1-3 agora" e depois "execute os passos 4-6". Isso evita que o Claude perca contexto no meio de uma execucao longa e permite que voce valide progressos intermediarios.
Em 1 frase: handoff limpo = instrucao explicita de "execute o plano acima". Quebre em fases se necessario.
Escalando complexidade
Imagine assim: Construir uma casinha de cachorro e um projeto. Construir um predio de 20 andares e outro. A tecnica e a mesma (tijolo sobre tijolo), mas a orquestracao e completamente diferente.
Para projetos com dezenas de arquivos, um unico plano nao basta. A estrategia: decomponha em modulos, crie um plano por modulo e execute cada um em sequencia. O plano-mestre define a ordem dos modulos; os sub-planos definem os passos dentro de cada modulo.
Use commits como checkpoints entre modulos. Se o modulo 3 quebra algo, voce volta para o commit do modulo 2 sem perder o trabalho dos modulos 1 e 2. Isso transforma um projeto grande e arriscado numa serie de projetos pequenos e seguros.
Em 1 frase: projetos grandes = plano-mestre + sub-planos por modulo + commits como checkpoints.
O pipeline de tres fases: plan, loop, review. Nenhuma e opcional.
Checklist de handoff plan para loop
- - Plano revisado e aprovado (2-3 rounds de refinamento)
- - Commit de checkpoint criado antes de iniciar
- - Worktree ou branch separado ativo
- - Instrucao explicita: "execute o plano acima, passo por passo"
- - Criterio de parada definido no prompt
Multi-file orchestration
Imagine assim: Uma orquestra: cada instrumento toca sua parte, mas todos precisam estar sincronizados. Editar multiplos arquivos e orquestrar: cada mudanca precisa ser consistente com as outras.
Quando uma feature toca 10 arquivos, a ordem das edicoes importa. O plano deve especificar: tipos/interfaces primeiro, implementacao depois, testes por ultimo. Isso evita erros de compilacao intermediarios que confundem o loop.
Peca ao Claude para manter um "mapa de consistencia": quais interfaces mudaram, quais implementadores precisam atualizar, quais testes precisam refletir as novas interfaces. O mapa e parte do plano e guia a execucao.
Em 1 frase: tipos primeiro, implementacao depois, testes por ultimo. Mapa de consistencia no plano.
Rollback strategies
Imagine assim: Um alpinista sempre tem corda de seguranca. Voce nao escala sem poder voltar. Rollback e a corda: quanto melhor ela for, mais alto voce pode ir.
Tres niveis de rollback: (1) git reset volta tudo ao ultimo commit, (2) worktree discard joga fora o branch inteiro sem afetar o main, (3) commits incrementais permitem voltar para qualquer checkpoint intermediario.
A regra de ouro: faca um commit antes de iniciar o loop, e um commit a cada fase completada. Assim voce sempre tem um ponto de retorno limpo. Se algo der muito errado, git reset --hard ao ultimo checkpoint e tente uma abordagem diferente.
Em 1 frase: commit antes de comecar, commit entre fases. Sempre tenha um ponto de retorno limpo.
Case studies reais
Imagine assim: Teoria e bonita, mas exemplos reais convencem. Vamos ver dois pipelines plan+loop em projetos de producao.
Case 1: Migracao de Lodash para ES nativo em projeto com 200 arquivos. Plano: mapear todos os imports de lodash, categorizar por funcao (map, filter, debounce), priorizar por frequencia. Loop: migrar arquivo por arquivo com tsc entre cada. Resultado: 200 arquivos em 45 minutos, zero regressoes.
Case 2: Adicionar i18n a SaaS existente. Plano: extrair todas as strings hardcoded, criar arquivo de traducoes, substituir por chaves i18n. Loop: arquivo por arquivo, validando que nenhuma string ficou hardcoded. Review: diff manual dos arquivos de traducao. Resultado: 3 horas em vez de 3 dias estimados.
Em 1 frase: plan+loop em projetos reais: migracoes em 45min, i18n em 3h em vez de 3 dias.
Resumo do Modulo
Proximo modulo:
2-6 — Agentic Coding — O Novo Normal: a filosofia e o mindset shift.