Claude Code propôs outra solução: aceito o plano dele ou insisto no meu caminho?

Fala aí, beleza? Você abriu o terminal com a solução pronta na cabeça, pediu, e o Claude Code voltou com um plano que faz tudo de um jeito diferente do seu

E agora?

A dúvida aqui não é "quem manda no projeto" (você manda, sempre)

A dúvida real é bem mais chata e bem mais prática: qual dos dois caminhos vai te gerar MENOS retrabalho daqui a duas horas…

O plan mode foi feito pra esse instante exato: ele lê arquivos, roda comandos de exploração e escreve o plano, mas não encosta no código fonte

As edições ficam bloqueadas até você aprovar o plano (a exceção são sessões com bypass permissions disponível)

Ou seja: esse é um momento de decisão barato, você ainda não perdeu nada

Então bora aos critérios, sem fé cega no agente e sem teimosia de dev também 😀

Quando ceder e aceitar o plano do Claude Code:

Ceder não é fraqueza, é economia de tempo

A própria documentação dá uma pista de quando o planejamento vale mais: quando a abordagem é incerta, quando a mudança toca vários arquivos ou quando você não conhece bem aquele código

Repara na raiz comum: são cenários onde a sua ideia inicial é um palpite, não uma decisão

E tem mais dois casos que a doc não cita, mas que aparecem direto no dia a dia

Você não conhece bem aquele trecho do código:

É o caso mais óbvio

Se você caiu de paraquedas num módulo legado, ou pegou uma parte do sistema que outra pessoa escreveu, o seu "caminho A" nasceu de suposição

O plano dele nasceu de leitura de arquivo

Empate técnico? Não é: leitura ganha de suposição

A mudança toca vários arquivos e ele mapeou dependência que você não viu:

Esse é o mais valioso

Quando o plano cita um arquivo que você nem lembrava que existia, você acabou de ganhar informação nova de graça

Antes de brigar, lê o plano procurando isso: tem algum arquivo, alguma chamada, algum efeito colateral ali que não estava no seu mapa mental?

Se tem, o plano dele já é melhor que o seu, mesmo que a implementação final seja sua

A divergência é só de estilo, com o mesmo resultado:

Aqui é onde a maioria das brigas acontece e onde elas menos valem a pena

Ele criou um helper e você faria inline

Ele quebrou em duas funções e você faria em uma

Mesmo resultado, mesmo teste passando, mesma manutenção

Se o resultado é idêntico, insistir é só gasto de rodada de conversa (e no fim do post te conto por que isso custa mais caro do que parece)

Seu caminho era chute, não escolha:

Seja honesto na hora de responder isso

Você escolheu aquela abordagem por um motivo que você consegue explicar em voz alta, ou porque foi a primeira coisa que apareceu na sua cabeça?

Se você não consegue defender o porquê, ceda e siga a vida

Quando insistir no seu caminho:

Agora o espelho

Insistir NÃO é teimosia quando você tem contexto que o agente simplesmente não tem como ter

E isso acontece muito mais do que o pessoal admite

Informação que não está no código:

O Claude lê o repositório

Ele não lê a reunião de ontem, o prazo que o cliente empurrou, a migração que o time começou semana passada e ainda está pela metade, nem a restrição contratual que proíbe subir aquela dependência

Se a sua escolha vem de uma dessas, você está certo e ele não tinha como saber

Insiste, e mais importante: escreve isso em algum lugar (o passo a passo do CLAUDE.md está mais pra frente no post)

Convenção do projeto que o plano ignorou:

O plano pode estar tecnicamente correto e ainda assim errado pro seu projeto

Padrão de nomenclatura, camada onde a regra de negócio vive, biblioteca que o time decidiu abandonar

Nesse caso não é opinião contra opinião, é regra do projeto contra desconhecimento da regra

Escopo inflado (o clássico):

Você pediu para corrigir um bug e o plano veio com refatoração de três arquivos, extração de serviço e renomeação de variável "de quebra"

Tome cuidado com esse

Ele parece produtivo e ele é justamente o que te faz revisar um diff gigante às onze da noite

Segura o escopo: o que você pediu é o que precisa ser feito

O caso do "diff em uma frase":

Esse aqui nem era caso de plano

A orientação da doc é direta: escopo claro e mudança pequena (corrigir typo, adicionar log, renomear variável) se pede direto

Se você consegue descrever o diff em uma frase, pula o planejamento

O plano nesse cenário só te dá um documento pra ler antes de fazer uma coisa de dez segundos 😛

Resumo dos dois lados:

Como discordar sem perder o trabalho já feito:

Beleza, decidiu discordar

Agora a parte mecânica, que é onde muita gente perde trabalho à toa: cada tipo de discordância tem um movimento diferente

Aprovar por cansaço e depois desfazer no braço é o pior dos mundos

Sintoma: o plano está quase certo, só um pedaço incomoda

Não precisa jogar tudo fora

Solução: Ctrl+G abre o plano proposto no seu editor de texto padrão e você edita ele direto, antes do Claude prosseguir

É o movimento mais subestimado do fluxo: você fica com o mapeamento que ele fez e troca só a parte que era decisão sua

Sintoma: o plano está errado na direção, não no detalhe

Aí não adianta editar, a premissa é que está torta

Solução: a opção "No, keep planning" mantém a sessão em plan mode e você diz o que quer diferente

O ponto forte é que nada foi editado ainda, então o custo de recomeçar o raciocínio é praticamente zero

Use essa opção com feedback específico, não com "não gostei"

Sintoma: você já aprovou e ele começou a editar errado

Aprovar o plano encerra o plan mode e muda a sessão para o modo de permissão da opção que você escolheu, e é aí que ele começa a mexer nos arquivos

Solução imediata: Esc para na hora

A chamada de ferramenta em execução é cancelada e ele fica esperando a sua próxima instrução, com o contexto preservado

E se já entrou coisa no código? O menu de rewind resolve

/rewind

O mesmo menu abre com Esc duas vezes, mas só com o campo de prompt VAZIO (se tiver texto digitado, o duplo Esc limpa o texto em vez de abrir o menu)

Lá dentro você escolhe restaurar código e conversa, só a conversa, só o código, ou resumir a partir daquele ponto

Isso funciona porque todo prompt que você envia vira um checkpoint, e ele tira snapshot dos arquivos antes de cada mudança

A ressalva dura do rewind:

E aqui vai o "já me ferrei uma vez por causa disso" que você não precisa viver na pele

O checkpointing rastreia as edições feitas pelas ferramentas de edição de arquivo do Claude

Arquivo mexido por comando bash NÃO é rastreado

Os rm, mv e cp da vida ficam de fora, e o rewind não desfaz eles

Então quando o plano envolve mover ou apagar arquivo por comando, o botão de voltar não existe: revise ANTES

Sintoma: aprovou, mas quer voltar a planejar

Sem drama

Pressione Shift+Tab para ciclar os modos de permissão de novo, ou prefixe o próximo prompt com /plan

É o mesmo caminho de entrada de sempre, e vale tanto pra começar quanto pra voltar

Se você quiser o passo a passo do fluxo desde o começo, tem um post aqui do blog sobre planejar antes de executar mudanças

Prevenção vale mais que rewind:

A documentação tem uma recomendação que resume tudo isso: corrigir cedo e com frequência

Ciclos de feedback curtos costumam produzir soluções melhores e mais rápidas do que deixar ele seguir e consertar depois

Traduzindo: no segundo em que você pensou "hmm, não era bem isso", já é hora de parar

Não espera terminar pra ver no que dá

Como registrar a decisão para não repetir a discussão toda tarefa:

Agora o pulo do gato

Decidir uma vez é fácil

O que cansa é discutir a MESMA coisa em toda tarefa nova, porque a sessão seguinte não sabe o que você decidiu na anterior

O Claude Code tem dois sistemas de memória que se complementam: os arquivos CLAUDE.md (instruções que você escreve) e a auto memory (notas que o próprio Claude escreve a partir das suas correções e preferências)

Bora usar os dois direito?

1. Passe a decisão pelo filtro de memória

O critério do que merece virar arquivo de memória é bem específico: precisa ser algo não dedutível do código nem do CLAUDE.md, e útil em sessões futuras

"Usamos TypeScript" ele deduz olhando os arquivos

"Não mexemos na camada de pagamento até a migração terminar em outubro" ele não deduz de jeito nenhum

O erro comum deste passo: registrar coisa óbvia que já está visível no repositório, e transformar seu arquivo de memória num monte de ruído que dilui as regras que importam de verdade

2. Escreva a regra no CLAUDE.md do projeto

Os arquivos de escopo de projeto ficam no repo, sob .claude/ (com CLAUDE.md, .mcp.json e .worktreeinclude na raiz), e o CLAUDE.md é lido no começo de toda sessão

## Decisões de arquitetura

- Regra de negócio fica na camada de serviço, nunca no controller
- Não refatorar módulo de pagamento até a migração do gateway terminar
- Preferir função pura e teste unitário a helper compartilhado novo

O erro comum deste passo: escrever regra vaga tipo "seguir boas práticas"

Isso não decide nada e não impede a próxima divergência

Regra boa é a que faz o plano mudar

3. Direcione a regra pra parte certa da árvore

Nem toda decisão vale pro projeto inteiro

Dá pra ter CLAUDE.md por diretório e regras com escopo de caminho em .claude/rules/

Iniciando o Claude na raiz do repositório, o CLAUDE.md de cada subdiretório carrega assim que ele lê um arquivo daquele diretório

O erro comum deste passo: subir pro escopo global uma decisão que era só daquele projeto

Os arquivos de escopo global ficam em ~/.claude/ e valem para TODOS os projetos, então a convenção do cliente X vaza pro projeto Y e você não entende por que ele começou a inventar moda

4. Use CLAUDE.local.md pro que é só seu

Preferência pessoal que não deve virar regra do time vai pro CLAUDE.local.md na raiz do projeto

Ele é carregado junto com o CLAUDE.md e tratado igual

A orientação é adicionar ele ao .gitignore pra não ser commitado:

CLAUDE.local.md

O erro comum deste passo: esquecer o .gitignore e mandar sua preferência pessoal pro repositório do time (constrangedor e improdutivo, os dois ao mesmo tempo)

5. Edite tudo isso sem sair da sessão

/memory

O /memory navega e abre os arquivos de memória, listando CLAUDE.md, CLAUDE.local.md e outros locais, em escopo de usuário e de projeto

Selecionar um arquivo abre no editor e, se ele não existir, é criado

E tem o caminho preguiçoso, que é o melhor de todos: pedir direto pro Claude "adicione isso ao CLAUDE.md" no momento em que a decisão acontece

O erro comum deste passo: adiar

A decisão que você não escreve no dia é a decisão que você vai rediscutir na semana que vem

E a auto memory nisso tudo?

Essa é a parte que trabalha sozinha

Além do que VOCÊ escreve, o Claude mantém notas próprias por repositório git, em ~/.claude/projects/<project>/memory/, com um MEMORY.md de entrypoint e arquivos de tópico opcionais

Os tipos de nota são quatro: user (seu papel, expertise e preferências de trabalho), feedback (correções que você dá e abordagens que você confirma), project (trabalho em andamento, prazos e decisões que ele não consegue deduzir do código ou do histórico git) e reference (onde achar informação fora do projeto)

Repara no tipo feedback: é exatamente ali que a sua correção de rota tem chance de sobreviver à sessão

Ela requer o Claude Code na versão 2.1.59 ou mais nova

A configuração autoMemoryEnabled vem com default true, e quando está false ele não lê nem escreve no diretório de auto memory

Dá pra alternar isso pelo /memory dentro da sessão

Cabo de guerra sai caro: o que realmente decide

Agora o argumento que amarra o post todo

Brigar tarefa a tarefa tem um custo escondido, e ele não é o seu tempo: é CONTEXTO

Cada rodada de discordância (o plano, a sua objeção, o replanejamento, a nova objeção) enche a janela de contexto

E a janela de contexto é o recurso mais importante de gerenciar na sessão: conforme ela enche, a performance degrada, o Claude pode "esquecer" instruções anteriores e cometer mais erros

Sacou a ironia? Discutir demais pra ele acertar é justamente o que faz ele errar mais na frente

O caminho oposto está na mesma doc: quanto mais precisa a instrução, menos correção é necessária ao longo da tarefa

Precisão no começo compra silêncio no meio

E quando a sessão já esticou demais, tem uma saída no próprio menu de rewind: resumir a partir de um ponto pra liberar contexto

Se você quiser acompanhar esse gasto de perto, dá pra ver quanto token a sessão gastou e sentir na prática o tamanho do cabo de guerra

Então o veredito é esse, e ele não é sobre ego:

A pergunta certa nunca foi "quem tem razão"

A pergunta certa é "o que vai ficar escrito"

Discordância que vira linha no CLAUDE.md custa uma vez

Discordância que vira conversa custa toda tarefa, pra sempre

Conclusão

O critério cabe em uma linha: informação que só você tem (prazo, time, cliente, convenção) = insista

Incerteza técnica em código que você não domina = ceda e aproveita o mapeamento

O resto é estilo, e estilo não vale rodada de contexto

Na próxima vez que o plano vier diferente do que estava na sua cabeça, faz dois movimentos: usa a opção "No, keep planning" com feedback específico em vez de aprovar por cansaço, e manda a decisão pro CLAUDE.md no MESMO dia, enquanto o motivo ainda está fresco

É o tipo de hábito chato que economiza tarde inteira depois…

até o próximo post! 😀