Claude Code Plan Mode: revise o plano antes de implementar

O momento que faz diferença vem antes da aprovação: você percebe que um trecho que chama a função ficou de fora, preserva um contrato existente ou elimina uma alteração desnecessária no banco de dados. Um plano detalhado justifica o esforço quando muda uma decisão.

Como o Claude Code Plan Mode funciona hoje

O Plan Mode pede ao Claude que investigue a base de código e proponha mudanças. Ele pode ler arquivos, executar comandos de investigação e escrever o plano. Em condições normais, as edições no código-fonte ficam bloqueadas até você aprovar. É como revisar a planta de uma reforma antes de começar a derrubar paredes. Fluxo de planejamento da Anthropic.

Há uma exceção importante na documentação: em uma sessão interativa de terminal com bypass de permissões disponível, os bloqueios do Plan Mode não são aplicados. O Claude continua recebendo a instrução de planejar, mas uma tentativa de edição pode ser executada. Isso inclui disponibilizar o bypass com --allow-dangerously-skip-permissions, mesmo sem escolhê-lo como modo ativo. Se a intenção é condicionar as edições no código-fonte à sua aprovação, inicie a sessão sem habilitar o bypass. Regras dos modos de permissão da Anthropic.

O fluxo de planejamento e o sistema de permissões trabalham juntos. O plano descreve o que o Claude pretende mudar; o modo de permissão controla quais ações podem prosseguir sem perguntar a você.

Como entrar e sair do Plan Mode

No terminal, inicie diretamente no Plan Mode:

claude --permission-mode plan

Se a sessão já estiver em andamento, use os controles abaixo. Observe o indicador de modo em vez de contar quantas vezes apertou o atalho.

A partir de auto, o ciclo passa por default (Manual), depois acceptEdits e então plan. Em seguida vêm os modos opcionais disponíveis: primeiro o bypass de permissões, por último o auto. No Windows, a Anthropic documenta Alt+M como alternativa quando o runtime do Node ou do Bun não habilita o modo de entrada VT. Alternância entre modos, referência de atalhos, referência de comandos.

Quando o Claude apresenta um plano, a solicitação de aprovação permite:

• Escolher No, keep planning (Não, continuar planejando) e dar orientações específicas de correção.
• Escolher Yes, manually approve edits (Sim, aprovar edições manualmente) para aprovar a abordagem e revisar cada edição individualmente.
• Escolher Yes, and use auto mode (Sim, e usar o modo auto) para aprovar e continuar no modo auto, quando disponível.

Se o modo auto estiver indisponível, a opção automática passa a aceitar edições automaticamente. Se a sessão começou com o bypass habilitado, essa opção ativa o bypass de permissões. Leia qual modo está sendo oferecido antes de selecioná-lo. A aprovação encerra o Plan Mode e inicia a implementação com as permissões escolhidas. Alternar com Shift+Tab também encerra o planejamento, mas não aprova o plano proposto. Comportamento da aprovação de planos.

Está usando a interface de um editor? No VS Code, clique no indicador de modo abaixo do prompt e selecione Plan. Na aba Code do Desktop, use o seletor de modo ao lado de Send. Nos IDEs JetBrains, use os controles da CLI no terminal integrado. O changelog também registra o suporte ao comando /plan digitado no VS Code a partir da v2.1.280. Controles das interfaces, changelog oficial.

Configurações que vale conhecer

Para iniciar as sessões de terminal de um projeto no Plan Mode, incorpore esta configuração ao arquivo .claude/settings.json:

{
  "permissions": {
    "defaultMode": "plan"
  }
}

Para definir o padrão de terminal do seu usuário, use ~/.claude/settings.json. A flag de inicialização tem precedência sobre as configurações, e configurações do projeto ou gerenciadas podem substituir o padrão do usuário. O VS Code tem uma configuração própria de inicialização: defina "claudeCode.initialPermissionMode": "plan" nas configurações de usuário do VS Code. A extensão não consulta as configurações do projeto para definir o modo de permissão inicial. Configuração do modo inicial.

Estas chaves adicionais ficam no nível principal das configurações do Claude Code, fora de permissions:

São decisões independentes: onde salvar o plano, como revisar comandos durante o planejamento e se haverá uma opção de aprovação que limpa a conversa. Referência de configurações, armazenamento dos planos, opção de limpar o contexto.

Se decidir limpar o contexto, registre no próprio plano as restrições, as decisões em aberto e os critérios de aceitação. Caso contrário, você estará contando com uma discussão à qual a implementação não terá mais acesso.

Como o Plan Mode se integra ao modo auto

O Plan Mode reserva a decisão de implementar para a revisão. O modo auto reduz as solicitações rotineiras de permissão ao usar um modelo classificador separado para avaliar as ações. O classificador analisa uma ação do ponto de vista das permissões; a sua revisão do plano verifica se o desenho proposto resolve o problema certo.

Quando o modo auto está disponível e useAutoModeDuringPlan continua habilitado, esse classificador também revisa os comandos de shell durante o planejamento. Comandos aprovados são executados; os rejeitados ficam bloqueados. Sem disponibilidade do modo auto, ou com essa configuração desabilitada, comandos fora do conjunto integrado de operações somente de leitura passam a pedir confirmação. A remoção de caminhos críticos tem tratamento separado, e a exceção do bypass no terminal interativo tem prioridade. Estar no planejamento não significa que todo comando de shell seja somente de leitura. Comandos durante o planejamento.

Na implementação, default significa revisão Manual; acceptEdits permite automaticamente edições dentro do escopo e comandos comuns do sistema de arquivos, com exceções documentadas; e auto acrescenta a revisão de ações em segundo plano. Nenhum desses modos avalia se a arquitetura é uma boa ideia. Nosso guia do modo auto do Claude Code detalha essa escolha de permissões.

A documentação atual identifica o auto como modo inicial padrão integrado para sessões interativas de terminal e do VS Code a partir da v2.1.283, sujeito às regras de configuração, organização e disponibilidade. Definir explicitamente o Plan Mode na inicialização continua sendo relevante. Regras atuais do modo inicial.

Instruções antigas podem deixar passar mudanças relevantes. O changelog da Anthropic registra o argumento de descrição de /plan na v2.1.72, a opção de limpar o contexto passando a ficar oculta por padrão na v2.1.81 e, na v2.1.218, o tratamento pelo classificador de comandos Bash cuja condição de somente leitura é incerta durante o planejamento com auto. Changelog oficial.

Exemplo prático: compartilhar a lógica de preços sem alterar as cobranças

Considere uma refatoração concreta: uma aplicação calcula os preços do checkout na API e os preços de renovação em um worker em segundo plano. A ideia é compartilhar as regras de preços, preservando o comportamento atual de arredondamento e descontos de cada ponto de chamada. Este plano é ilustrativo: não é o relato de um repositório testado nem uma garantia do que o Claude vai produzir.

Entre no Plan Mode e informe a restrição real:

Suponha que os arquivos relevantes do projeto sejam estes:

Uma primeira versão plausível poderia propor extrair um calculador comum, migrar os dois pontos de chamada, excluir as funções auxiliares antigas e atualizar os testes. Parece organizado. Mas também está incompleto: o que acontece se o checkout arredonda em uma etapa diferente da renovação?

Edite o plano antes de aceitá-lo. Na revisão, pressione Ctrl+G e substitua a etapa de exclusão antecipada por esta alteração:

Salve o plano e volte. Se a proposta ainda precisar de ajustes, escolha a opção de continuar planejando e peça ao Claude que harmonize o plano inteiro com essa alteração. O objetivo é remover a etapa de exclusão que entrou em contradição, não acrescentar um aviso abaixo dela. A edição direta e a continuidade do planejamento são partes documentadas do fluxo. Orientações da Anthropic para explorar, planejar e programar.

O plano revisado deve apresentar uma sequência que possa ser implementada:

1. Registrar o comportamento existente. Adicione casos para os valores atuais de checkout e renovação, incluindo limites de arredondamento, descontos e entradas inválidas. Esclareça qualquer resultado esperado ainda desconhecido antes de prosseguir.
2. Introduzir a política compartilhada por trás de adaptadores. Preserve as entradas, as saídas e o comportamento em caso de erro de cada função existente. Expresse explicitamente as diferenças entre os pontos de chamada.
3. Migrar os pontos de chamada em etapas separadas. Atualize o checkout, verifique seu funcionamento e só então atualize a renovação. Deixe limpezas de código sem relação com a tarefa fora dessas mudanças.
4. Verificar o resultado. Execute as verificações reais de preços, API e worker do projeto, seguidas pelas verificações habituais de tipos e integração. Revise o diff em busca de alterações nas respostas públicas ou na semântica das cobranças.
5. Manter uma forma de reverter a mudança. Preserve a camada de compatibilidade até a verificação ser concluída com sucesso. Remova o código obsoleto em uma etapa separada, que possa ser revisada por si só.

Neste exemplo, aprove com revisão manual das edições. Depois da implementação, compare as mudanças efetivas e os resultados dos testes com o plano. Um plano que menciona testes continua sendo apenas uma proposta até que essas verificações sejam executadas.

O ganho econômico aqui é específico: identificar uma mudança de comportamento antes que os dois pontos de chamada e seus testes sejam reescritos. Não é preciso atribuir a isso um percentual especulativo de economia de tokens.

Quando vale mais a pena planejar primeiro

Priorize trabalhos nos quais um erro inicial de concepção pode se espalhar. Em ordem de valor provável, estas são as situações que eu colocaria no planejamento primeiro:

Esses são fluxos propostos, não resultados medidos. Eles seguem a recomendação da Anthropic de planejar quando a abordagem é incerta, a mudança abrange vários arquivos ou o código não é familiar. Para um erro de digitação, uma instrução de log já definida ou uma renomeação com escopo claro, peça a mudança diretamente. Quando a Anthropic recomenda planejar.

Para estimar os custos, compare o fluxo antes e depois. Na execução direta, você gasta tempo de implementação e revisão antes de descobrir que a abordagem estava errada. O planejamento acrescenta investigação e revisão do plano no início, com a possibilidade de evitar esse retrabalho.

Planejar compensa quando o custo do trabalho de planejamento somado ao uso adicional do modelo fica abaixo do custo esperado do retrabalho que ele evita. Essa é uma regra de decisão, não um benchmark de economia da Anthropic. Use os custos de engenharia e o consumo real da sua equipe. Se o plano apenas repetiria uma mudança que você já consegue especificar com precisão, pule essa etapa.

Que produto vale a pena criar a partir disso?

A oportunidade mais forte é um pacote de revisão de refatorações para equipes: transformar uma mudança proposta em um material pronto para revisão, com mapa de arquivos, contratos a preservar, verificações de aceitação e notas de rollback. Uma liderança de engenharia poderia pagar pela consistência entre desenvolvedores, especialmente em mudanças na lógica de negócio compartilhada.

As estimativas de palavras-chave da DataForSEO para os Estados Unidos, consultadas em 12 de outubro de 2026, indicam 170 buscas por mês para “code refactoring tools”. É um sinal modesto de interesse na tarefa, não uma evidência de que essas pessoas comprariam um produto de revisão de planos. A versão mínima útil poderia receber um plano exportado e um mapa de arquivos do repositório, procurar pontos de chamada ausentes ou premissas sem sustentação e gerar um resumo para o pull request. O desafio: a geração genérica de planos já faz parte do Claude Code. O produto precisa de verificações específicas da equipe e de um material de revisão útil para justificar sua adoção.

Uma oportunidade mais restrita é um pacote de preparação para migrações voltado a agências: produzir um inventário dos componentes afetados, um checklist de implantação em etapas e uma lista de decisões pendentes antes de orçar uma atualização. A mesma consulta à DataForSEO estima 20 buscas mensais nos Estados Unidos para “code migration tools”. O baixo volume dessa consulta comercial é um motivo para validar a ideia com clientes atuais antes de criar um produto abrangente.

A versão mínima poderia se concentrar em uma família de migrações e exigir links para a documentação aplicável do fornecedor ao lado de cada mudança. O desafio é a manutenção: regras de migração específicas de cada versão ficam desatualizadas rapidamente. O Plan Mode pode ajudar na investigação, mas não fornece um manual de migração verificado. Essas são hipóteses de produto baseadas na demanda de busca, não previsões de receita.

O Ultraplan não está mais disponível

A Anthropic removeu a prévia de pesquisa do Ultraplan, incluindo /ultraplan, seu acionamento por palavra-chave e a opção de aprovação que permitia refinar o plano com o Ultraplan na web. A página informa que prévias de pesquisa são experimentais e podem mudar ou ser removidas com base no feedback. Como alternativas para os fluxos de planejamento, ela aponta o Plan Mode local e as sessões do Claude Code na nuvem. Página atual do Ultraplan na Anthropic.

Dúvidas antes da próxima sessão

Na segunda-feira, pegue a próxima refatoração com lógica chamada de vários pontos, entre no Plan Mode e peça que ele detalhe o comportamento a preservar, os arquivos afetados, a verificação e o rollback. Corrija a premissa mais frágil antes de aprovar. Combine isso com os hábitos de revisão mais amplos do guia de boas práticas do Claude Code.

Se a sua equipe precisa de um fluxo de planejamento e revisão que possa repetir, podemos incorporá-lo ao seu processo de desenvolvimento.