O que e plan mode
Imagine assim: voce contrata um pedreiro excelente. Antes de ele sair quebrando parede, voce pede a planta. Ele desenha, voce confere, ajusta, e so entao ele executa. Plan mode e a planta antes da obra.
No modo normal do Claude Code, voce pede algo e ele sai fazendo: lendo arquivos, editando codigo, rodando comandos. Funciona bem para tarefas simples. Mas quando a tarefa e complexa, isso e como construir sem planta. O plan mode muda esse comportamento: em vez de agir, o Claude primeiro pensa e propoe o que pretende fazer.
Para ativar, basta pressionar Shift+Tab antes de enviar sua mensagem, ou incluir a palavra "plan" no prompt. O Claude vai analisar o codebase, considerar as implicacoes e apresentar um plano estruturado com os passos que pretende seguir. Voce le, ajusta se necessario e so entao autoriza a execucao.
Em 1 frase: plan mode = o Claude mostra o que vai fazer antes de fazer; voce decide se segue.
Quando usar (e quando nao)
Imagine assim: voce nao faz planta pra trocar uma lampada. Mas faz planta pra reformar a cozinha. O criterio e o mesmo: complexidade e risco.
Plan mode brilha quando a tarefa envolve multiplos arquivos, decisoes de arquitetura, ou quando o erro e caro de reverter. Para um "adiciona um console.log aqui", nao faz sentido planejar. Para "refatora o sistema de autenticacao para usar OAuth", planejar pode salvar horas.
A regra pratica: se a tarefa toca mais de 3 arquivos ou voce nao tem certeza do caminho, use plan mode. Se e uma mudanca pontual e reversivel, va direto. Com o tempo voce calibra essa intuicao.
Use plan mode
- - Feature nova com varios arquivos
- - Refatoracao que muda interfaces
- - Bug que voce nao sabe onde esta
- - Migracoes de dependencias
Va direto (sem plano)
- - Fix de typo ou string
- - Adicionar log ou comentario
- - Mudanca em 1 arquivo isolado
- - Tarefa que voce ja sabe o caminho
Em 1 frase: plan mode para o complexo e arriscado; execucao direta para o simples e reversivel.
Anatomia de um plano
Imagine assim: uma receita de bolo boa tem ingredientes, passos numerados e tempo de forno. Um plano bom tem a mesma estrutura: o que, em que ordem, e o que verificar.
Um bom plano do Claude Code tem quatro partes: (1) objetivo claro em uma frase, (2) lista de arquivos que serao tocados, (3) passos ordenados do que sera feito em cada um, e (4) riscos ou pontos de atencao. Se alguma dessas partes estiver faltando, peca pro Claude complementar antes de aprovar.
A qualidade do plano depende diretamente da qualidade do seu pedido. Um prompt vago gera um plano vago. Quanto mais contexto voce der (quais padroes seguir, quais arquivos olhar, o que nao mudar), mais preciso o plano sai.
Em 1 frase: um plano precisa de objetivo, arquivos, passos e riscos; se faltar um, peca antes de aprovar.
Approval flow — revisando e ajustando
Imagine assim: o arquiteto entrega a planta. Voce nao assina de olhos fechados. Voce olha, pergunta "e se chover?", ele ajusta, e voce assina a versao revisada.
Quando o Claude apresenta o plano, voce tem tres opcoes: aprovar e ele executa, rejeitar e comecar de novo, ou refinar pedindo ajustes especificos. A terceira opcao e a mais poderosa: "bom plano, mas troque a abordagem do passo 3" ou "adicione testes unitarios ao plano".
O approval flow e o seu ponto de controle. E onde voce exerce julgamento humano: o plano faz sentido para o projeto? Respeita os padroes existentes? Toca so o que precisa? Se alguma resposta for "nao", refine antes de aprovar.
O que voce faz quando o plano esta 90% bom?
Em 1 frase: o approval flow e seu checkpoint de qualidade; refinar e quase sempre melhor que aprovar as cegas.
Iterando no plano antes de executar
Imagine assim: um escritor revisa o rascunho 3 vezes antes de publicar. Cada revisao custa minutos; uma publicacao errada custa horas. Com planos e igual: cada iteracao no plano e barata, corrigir depois da execucao e caro.
A tecnica mais poderosa do plan mode e iterar no plano multiplas vezes antes de executar. Voce nao precisa aprovar o primeiro draft. Peca ao Claude: "refine o passo 2, considere que ja temos um middleware de auth", ou "mude a ordem, faca os testes primeiro". Cada round custa poucos tokens; corrigir codigo errado depois custa muito mais.
Trate o plano como um documento vivo. A primeira versao raramente e a melhor. Dois ou tres rounds de refinamento costumam ser o ponto ideal: ja captura as nuances sem gastar demais em planejamento.
Dica pratica
Use perguntas especificas na iteracao: "e se o usuario nao estiver autenticado?", "como isso afeta o componente X?", "adicione tratamento de erro ao passo 4". Perguntas genericas como "melhore o plano" geram respostas genericas.
Em 1 frase: iterar no plano e barato; corrigir apos a execucao e caro. Refine 2-3 vezes antes de aprovar.
Anti-patterns comuns
Tres erros que quase todo mundo comete no inicio:
Anti-patterns de plan mode
- Rubber-stamp approval: aprovar sem ler. O plano parece grande, voce clica "go" sem conferir. Resultado: o Claude faz algo que voce nao queria e voce gasta mais tempo revertendo.
- Over-planning: planejar demais, iterar 10 vezes no plano sem nunca executar. A certa altura, e melhor executar e corrigir do que ficar refinando o plano infinitamente.
- Plan drift: aprovar o plano e depois, no prompt seguinte, dar instrucoes que contradizem o plano. O Claude fica confuso entre o que foi planejado e o que voce esta pedindo agora.
Antes de aprovar o plano, cheque: [ ] Li todos os passos (nao so o titulo) [ ] O plano lista os arquivos que serao tocados [ ] Nenhum passo toca algo que nao deveria [ ] Riscos estao identificados [ ] 2-3 rounds de refinamento ja foram feitos Se 3+ falharam, refine antes de aprovar.
Em 1 frase: nao aprove sem ler, nao planeje sem parar, e nao contradiga o plano depois de aprovar.
Resumo do Modulo
Proximo modulo:
2.2 — Planos que Funcionam: como criar planos eficazes para features, refactors e bug fixes.