Claude Code respondeu algo que você não entendeu: o que perguntar antes de aceitar

O diff chega pronto, roda de primeira, e você não faz a menor ideia do porquê

Aí você aceita

E nesse exato segundo você deixou de ser dono do código e virou revisor de uma coisa que não sabe manter. Funciona hoje, quebra daqui a três semanas, e quem vai abrir o arquivo pra entender o estrago é você (não a IA)

O problema quase nunca é o modelo estar errado. É a sessão andar rápido demais pra você acompanhar

Então vamos ao que interessa: um roteiro de perguntas pra colar no prompt ANTES do aceite, que arranca explicação, alternativas descartadas e efeito colateral. A ideia é simples: transformar a sessão em aprendizado em vez de código colado às cegas

Bora?

Por que a explicação some: 10 ações por prompt e só 4 turnos

Tem número pra isso, e ele explica muita coisa

A pesquisa da Anthropic sobre uso real do Claude Code analisou de forma preservadora de privacidade cerca de 400 mil sessões, entre outubro de 2025 e abril de 2026

Em dados históricos desse período, cada prompt do usuário dispara em média cerca de 10 ações do Claude (às vezes mais de 100!), com média de 2.400 palavras de saída por turno

E a sessão típica tem cerca de QUATRO turnos de interação

Se liga no que isso significa na prática: você escreve uma frase, ele executa dez coisas, devolve um caminhão de texto, e a conversa acaba em quatro rodadas. Não tem espaço natural pra explicação nascer sozinha, você tem que pedir

Pré-inscrição Formação Claude Code

Domine o Claude Code do básico ao avançado

Você vai aprender a criar sistemas completos com Claude Code, sem precisar ser programador. Inscreva-se para ter acesso a um desconto de lançamento e bônus especiais!

Quero minha vaga

Onde exatamente mora o buraco

A mesma pesquisa mostra que, em média, as pessoas tomam cerca de 70% das decisões de planejamento e apenas 20% das decisões de execução

Ou seja: você decide bastante O QUE fazer

E quase nada sobre COMO foi feito

O buraco de entendimento não está no começo da conversa, ele mora na execução, que é justamente a parte que vira código no seu repositório

E tem um detalhe que muda o jogo: a pesquisa aponta um retorno persistente à expertise, quanto maior o domínio de quem conduz a sessão, mais trabalho o Claude realiza por instrução

Entender não é luxo de dev purista, é alavanca

Quem entende o que foi feito escreve a próxima instrução melhor, e a próxima instrução melhor rende mais trabalho útil. Se você quiser ver esse ciclo inteiro rodando num projeto de verdade, do primeiro comando até subir, dá uma olhada no fluxo completo de um projeto com Claude Code

Antes de perguntar: pare a sessão no lugar certo

Antes do roteiro, três coisas precisam estar na sua mão. Sem elas você pergunta tarde, quando o contexto já andou

1. Como frear na hora

Pressionar Esc interrompe o Claude imediatamente: a chamada de ferramenta em execução é cancelada e ele fica aguardando a próxima instrução

É o botão de pausa. Percebeu que ele saiu do trilho? Freia ali mesmo

A própria documentação de boas práticas orienta corrigir o rumo assim que você percebe o desvio, em vez de deixar rolar pra consertar depois

2. Como fazer ele propor sem mexer no código

O plan mode faz o modelo pesquisar e propor mudanças sem executá-las: ele lê arquivos, roda comandos de exploração e escreve um plano, mas não edita o código-fonte

Pra entrar nele, Shift+Tab cicla entre os modos de permissão na ordem default, acceptEdits e plan

E dá pra entrar só naquele prompt específico prefixando com /plan

Esse é o lugar mais confortável pra perguntar: o plano está na tela, seu arquivo continua intacto

3. A rede de segurança

O Claude Code faz checkpointing automático, capturando o estado do código antes de cada prompt do usuário, justamente pra permitir desfazer edições e voltar a estados anteriores

O menu abre com /rewind, ou pressionando Esc duas vezes com o campo de input vazio

Tome cuidado! Se tiver texto escrito no input, o duplo Esc limpa o texto em vez de abrir o menu. Já vi gente achar que o recurso não existe por causa disso 😅

A documentação de boas práticas lembra que as conversas são persistentes e reversíveis

Traduzindo: perguntar não custa a sessão

Você não perde o trabalho por parar pra entender

O roteiro de perguntas, passo a passo

Agora o núcleo. Seis passos, com a pergunta literal pra colar no prompt

Não precisa decorar, salva num arquivo de notas e vai colando

1. Pare antes do apply

Se ele já está editando, Esc

Se você ainda vai pedir a mudança e desconfia que vem coisa grande, entra no plan mode antes (Shift+Tab até chegar em plan, ou /plan como prefixo do prompt)

O erro comum deste passo: deixar terminar "só pra ver se funciona" e perguntar depois. Aí a resposta vem sobre um código que já está no disco, e a pergunta perde a força de decisão

2. Peça o fluxo de controle em linguagem simples

Explicar código é uso previsto na documentação: o Claude Code localiza os arquivos relevantes, lê a implementação e explica o fluxo de controle em linguagem simples, incluindo pontos de entrada, ramificações de decisão, casos de borda e como aquilo se conecta ao resto do sistema

E aceita perguntas de acompanhamento, então não precisa acertar a pergunta perfeita de primeira

Antes de eu aceitar: explique o fluxo de controle dessa mudança em
linguagem simples. Quais são os pontos de entrada, onde estão as
ramificações de decisão, quais casos de borda ela trata e como isso
se conecta ao resto do sistema?

O erro comum deste passo: perguntar "o que esse código faz?"

É vago demais, e você recebe de volta uma paráfrase do código linha a linha, que é exatamente o que você já não entendeu

3. Pergunte as alternativas descartadas e o critério

Essa é a pergunta que mais ensina, na minha opinião

A solução na tela é uma entre várias, e o raciocínio de por que ela ganhou é onde mora o conhecimento de verdade

Quais outras abordagens você considerou pra resolver isso e descartou?
Por qual critério você escolheu esta? Em que cenário a alternativa
descartada seria melhor?

O erro comum deste passo: aceitar a primeira justificativa genérica ("é mais simples", "é mais idiomático") sem puxar o follow-up. Puxe: "mais simples comparado a quê, e o que eu perco?"

4. Pergunte os efeitos colaterais

A mudança quase nunca vive sozinha no arquivo dela

O que mais no projeto passa por esse mesmo caminho de código?
O que pode quebrar com essa mudança que não aparece no diff?
Tem algum comportamento existente que muda sem eu perceber?

O erro comum deste passo: perguntar só "tem algum efeito colateral?", que abre espaço pra um "não" rápido. Peça o caminho de código e os pontos que dependem dele, é bem mais difícil escapar disso

5. Peça como verificar sozinho

Explicação boa termina com você conseguindo checar sem depender da explicação

Como eu verifico sozinho que isso funciona e que não quebrou o resto?
Me dê os passos de verificação e o que exatamente eu devo observar
em cada um pra saber que está certo.

O erro comum deste passo: aceitar "rode os testes" como resposta. Rode os testes é o que fazer, você quer saber o que OBSERVAR

6. Só então aceite, ou volte atrás

Se as respostas fecharam, aceita tranquilo, agora é uma decisão sua e não uma aposta

Se não fecharam, /rewind (ou Esc duas vezes com o input vazio) abre o menu com os prompts enviados na sessão, e você escolhe: restaurar código e conversa, restaurar só a conversa, restaurar só o código, resumir a partir daqui, resumir até aqui, ou cancelar

Repare que dá pra restaurar SÓ o código e manter a conversa

Isso é ouro pro nosso caso: você desfaz a edição que não entendeu e continua o papo explicativo do mesmo ponto, sem perder o raciocínio 😀

O erro comum que se repete em todos: perguntar depois de aceitar

Com ~10 ações por prompt, o contexto anda rápido, e a pergunta tardia vira arqueologia em cima de um código que já é seu

Quando trocar de output style em vez de perguntar de novo

Se a sua dúvida é pontual, o roteiro acima resolve

Agora, se ela é crônica (base de código nova, stack que você não domina, refatoração grandona), repetir as mesmas quatro perguntas em todo turno cansa

A saída é mudar o MODO em vez de repetir pergunta

O Claude Code tem output styles embutidos, trocados pelo comando /output-style

E eles não são um verniz de formatação: output styles modificam diretamente o system prompt do Claude Code

/output-style explanatory

O Explanatory entrega Insights educativos enquanto ajuda a completar as tarefas de engenharia, explicando escolhas de implementação e padrões do codebase

A tarefa anda e a explicação vem junto, sem você pedir

/output-style learning

O Learning é um modo colaborativo de aprender fazendo: além dos Insights, o Claude pede que VOCÊ escreva pequenos trechos estratégicos de código, marcando os pontos com TODO(human)

É mais lento, é claro. E é exatamente por isso que funciona pra aprender

E se você montar o seu próprio jeito de ser explicado, dá pra guardar: output styles criados pelo comando /output-style:new são salvos por padrão como arquivos markdown no nível de usuário em ~/.claude/output-styles, e podem ser usados entre projetos

Escreveu uma vez, vale pra todos os repositórios. Mto massa

Ninguém decide por você: o que não auto-resolve mais

Tem um medo legítimo aqui: "se eu parar pra ler e pensar, a sessão anda sozinha e aceita por mim?"

Não anda

A aprovação de plano no Claude Code nunca é resolvida automaticamente por inatividade. O timeout de auto-continuar se aplica só às perguntas de múltipla escolha do AskUserQuestion, não aos prompts de permissão nem à aprovação de plano

E mesmo essas perguntas de múltipla escolha mudaram: os diálogos do AskUserQuestion deixaram de auto-continuar por padrão, o timeout de ociosidade virou opt-in via /config

E se nenhuma opção da pergunta te serve?

O AskUserQuestion é a ferramenta que o Claude usa pra fazer perguntas de múltipla escolha quando precisa de uma decisão ou esclarecimento

E você não está preso às opções prontas: dá pra responder escolhendo uma opção OU escrevendo texto próprio, pela linha Other ou pelo campo de notas

Use isso a seu favor

Quando ele te oferecer três caminhos e você não entendeu nenhum dos três, a resposta certa não é chutar o do meio, é escrever no Other: "explique a diferença prática entre as três antes de eu escolher"

Conclusão prática: o tempo de ler e perguntar é seu, ninguém está com o dedo no botão por você

Conclusão

O resumo é meio óbvio quando a gente escreve: código que você não entende não é produtividade, é dívida com juros

O roteiro serve pra devolver pra você justamente a parte que hoje está mais delegada, as decisões de execução (aquelas onde o humano decide só 20%)

Recapitulando o essencial:

• Esc freia a ação em curso, plan mode (Shift+Tab ou /plan) faz ele propor sem editar arquivo
• As quatro perguntas: fluxo de controle em linguagem simples, alternativas descartadas e critério, efeitos colaterais, como verificar sozinho
• /rewind (ou Esc duas vezes com o input vazio) é a rede, e dá pra restaurar só o código mantendo a conversa
• Dúvida crônica pede troca de modo: /output-style explanatory, ou /output-style learning quando o objetivo é aprender fazendo

Próximo passo concreto pra sua próxima sessão: ativa o /output-style explanatory logo no começo, e usa as quatro perguntas antes do primeiro aceite

Se a explicação não fechar, /rewind e segue o jogo

Faça o teste e me conta se a sessão não fica bem mais sua =)

Até o próximo post!