Plan Mode no dia a dia: quando vale, quando atrapalha

O Plan Mode do Claude Code é uma das ferramentas mais poderosas — e mais fáceis de usar errado. Em uma palavra: ele força um ciclo de leitura, exploração e desenho de plano antes de qualquer modificação. Ótimo quando o terreno é incerto. Ruim quando você já sabe exatamente o que fazer.

Aqui está como decido, na prática.

Quando ligo Plan Mode

• A tarefa toca código que eu não escrevi — preciso entender padrões, dependências e contratos antes de mexer.
• Tem mais de um caminho razoável — quero ver o trade-off escrito antes de comprar uma direção.
• A mudança atravessa camadas (banco → API → UI) — esquecer um lugar é fácil; o plano me obriga a listar todos.
• Já errei aqui antes — quando uma área tem histórico de regressões, o custo de planejar é menor que o custo de corrigir depois.

Quando não ligo

• Bug fix com causa identificada — abro o arquivo, ajusto, testo. Plano só atrasa.
• Mudança puramente mecânica — renomear, mover, ajustar import. Não há decisão.
• Já planejei numa sessão anterior — se o plano existe, vou direto para implementação.

O hábito que mudou tudo

Comecei a tratar o plano como commit zero: ele descreve a entrega antes de existir. Se eu não consigo escrever um plano claro em 5 minutos, o problema raramente é “preciso pensar mais” — é falta de contexto. Aí volto a ler código antes de planejar.

Bom plano em 5 minutos > plano “completo” em 30 minutos que ninguém vai ler depois.

O custo escondido

Plan Mode consome contexto. Em tarefas curtas, isso é desperdício — você gasta tokens descrevendo coisa que ia codificar em duas linhas. Em tarefas longas, você economiza muito mais do que gasta, porque o plano evita refatorações grandes no fim.

Regra prática: se a implementação cabe em 50 linhas, pule o plano. Se passa disso ou toca múltiplos arquivos, ligue.

Resumindo

Plan Mode não é cerimônia — é seguro contra erro caro. Use quando o erro custa mais que o plano. Em tudo o mais, vá direto.