Quatro prompts para contrariar a bajulação no Claude Code

O que é a bajulação da IA no Claude Code?#

A psicologia tem há muito um termo para isto: bajulação. Um bajulador diz aquilo que quer ouvir apenas para manter a conversa em andamento. Com a chegada dos grandes modelos de linguagem, a palavra passou para a investigação em IA e, numa análise oficial, a Anthropic reconheceu abertamente que o modelo sacrifica regularmente a precisão em favor da concordância rápida.

Na programação, é assim que acontece. Escreve ao Claude Code: «Corrige este erro em authMiddleware; os magic links deixaram de funcionar.» O bajulador não faz perguntas para esclarecer. Não pede registos. Não pergunta que versão da biblioteca está a utilizar. Oferece imediatamente uma solução porque foi treinado para ajudar rapidamente. E a solução vai parecer correta: imports, tratamento de erros, comentários. Mas será uma solução para o problema de outra pessoa, inventada a partir do contexto que o Claude reuniu com fragmentos.

A causa não é o Claude. A causa é a forma como o pedido está formulado. Quando pergunta «Como é que corrijo isto?», já partiu do princípio de que é possível corrigir. O bajulador adota esse enquadramento e produz uma «correção», mesmo que o verdadeiro problema esteja na arquitetura, na versão da biblioteca ou no facto de o sintoma descrito ser apenas a consequência de um erro de raiz completamente diferente.

Um teste simples para detetar um pedido que incentiva a bajulação: se não consigo responder à pergunta «O que está exatamente avariado?» em três frases, não estou preparado para resolver o problema. Preciso de um diagnóstico. A correção vem depois. É exatamente aí que começa o ciclo de 4 passos.

Um caso prático: 8 commits revertidos numa hora#

Um caso concreto de abril de 2026. Estava a trabalhar na autenticação por magic link em src/lib/auth/. O sintoma: os tokens eram validados, mas a sessão não era guardada. O utilizador clica na ligação do e-mail, chega ao site e, cinco segundos depois, é enviado de volta para /login.

Abri o Claude Code e escrevi: «A sessão não é guardada depois do magic link; procura em src/lib/auth/ e corrige o problema.» O Claude fez três perguntas para esclarecer e, de seguida, produziu imediatamente um plano. Disse: «Vou atualizar o handler do callback, reescrever o serializador JWT, acrescentar a gravação explícita no Redis e corrigir uma condição de corrida no middleware.» Parecia plausível. Aprovei o plano.

Dezoito minutos depois, tinha um diff em 14 ficheiros. O magic link continuava sem funcionar. Mas agora o token de atualização também não funcionava, o início de sessão com palavra-passe estava avariado e havia um erro 500 estranho na rota de pagamentos. Os testes estavam a falhar. Comecei a reverter as alterações.

Reverti 8 commits com git reset --hard origin/main. Uma hora de trabalho foi pelo cano abaixo. Se quiser perceber como reverter corretamente sem perder nada útil, expliquei-o em separado no guia para reverter alterações no Claude Code.

Sentei-me e investiguei devidamente. Abri src/lib/auth/magic-link.ts:42, li o ficheiro, abri os registos e verifiquei o Redis. Vinte minutos depois, descobri o problema. Estava numa linha: faltava o atributo SameSite=lax no cabeçalho set-cookie, e o Safari rejeitava o cookie ao redirecionar do domínio do e-mail para o site. Sem JWT, sem Redis, sem middleware. Uma linha.

Quando pedi ao Claude que corrigisse o problema, ele nem sequer consultou os registos do navegador. Não tinha contexto sobre o Safari. Construiu uma hipótese a partir do padrão «a sessão não é guardada = problema de serialização», porque essa é a resposta mais comum nos dados de treino. O bajulador produziu uma solução estatisticamente plausível, mas sem qualquer relação com a minha tarefa.

Anotei a lição como regra: nunca pergunte «Como é que corrijo isto?». Pergunte sempre «Estabelece os factos». Só faltava formalizar isto como um ciclo de trabalho.

De onde vem a bajulação: Opus 4.8 no lançamento e maio de 2026#

Em abril, a Anthropic analisou separadamente, numa análise técnica pós-incidente, como um erro de cache no Claude Code levou o modelo a «esquecer» o seu raciocínio entre interações.

Quando um modelo se esquece da sua cadeia de raciocínio, torna-se mais fácil «adivinhar» uma resposta com base num padrão — por outras palavras, tornar-se ainda mais bajulador.

O que fazer perante o lançamento do 4.8. Não escolha um modelo «mais fácil». Não volte ao 4.7. Adapte os seus prompts aos factos: o modelo está mais inclinado a concordar, por isso insista mais em «estabelecer os factos». Se ainda não percebeu exatamente o que está a mudar no Opus 4.8, comparei-o em detalhe na análise do Opus 4.8 no Claude Code.

Quando são necessários os 4 passos — e quando são uma perda de tempo#

Exemplos concretos. Corrigir o texto de um e-mail de boas-vindas: faça-o diretamente. Acrescentar um novo botão CTA a um site: Plan Mode sem o ciclo. Migrar um projeto de MySQL para Postgres: o ciclo de 4 passos é obrigatório. Um erro 500 estranho em produção que não pode ser reproduzido localmente: o ciclo de 4 passos com um passo «zero» adicional: «vamos primeiro criar um exemplo mínimo reproduzível».

Um erro comum ao usar o ciclo é aplicá-lo a tarefas triviais. Isso reduz a velocidade e faz com que as pessoas rapidamente desistam da metodologia. O ciclo é necessário precisamente quando o custo de um erro é superior ao custo de 15 minutos de planeamento.

Antes de implementar o ciclo, tenha em conta que os quatro prompts funcionam numa única sessão de Plan Mode. Se ainda não utilizou este modo, leia primeiro o guia do Plan Mode no Claude Code e depois volte.

Passo 1. Proíba soluções — faça o Claude estabelecer os factos#

O passo mais importante. É aqui que se bloqueia o primeiro impulso — «aqui está a solução». O prompt:

Dei de caras com o seguinte: [sintoma].

A tua tarefa agora é estabelecer os factos. São proibidas
quaisquer soluções, ideias ou sugestões. Apenas:
- o que observo (a formulação exata do sintoma)
- passos para reproduzir (um cenário mínimo)
- que dados estão disponíveis (registos, versões, ambiente)
- que dados faltam (o que é preciso recolher)

Condição de paragem obrigatória: não sugiras soluções;
apenas regista o diagnóstico. Se quiseres sugerir algo,
formula antes uma pergunta para mim.

O que faz. Com uma proibição explícita de apresentar soluções, o Claude não pode atalhar. Tem de preencher quatro campos: o que vejo, como reproduzir, o que sei e o que não sei. O último campo é o mais valioso. Muitas vezes, acaba por ser: «Não sei a versão da biblioteca, o que está nos registos nem se o sintoma ocorre em produção.» Esse é o ponto de partida para o passo seguinte.

A armadilha do passo 1. Se o sintoma estiver formulado de forma demasiado vaga («a autenticação não funciona»), o Claude continuará a fazer suposições. A solução está no próprio prompt: descreva o sintoma exato numa frase e apresente um cenário mínimo de três passos. Se não conseguir fazê-lo, isso significa que ainda não percebe exatamente o que está avariado e, de qualquer forma, a resposta do Claude será inútil.

Passo 2. Precedentes da Internet em vez de alucinações tiradas da memória#

Este passo bloqueia o segundo impulso: «inventar uma solução de memória». O prompt:

Agora que o diagnóstico está estabelecido, procura na Internet
precedentes para resolver problemas semelhantes.

Pelo menos 3 abordagens diferentes. Para cada uma:
- uma ligação para a fonte primária (issue, artigo, documentação)
- uma breve descrição da abordagem
- vantagens e desvantagens para a nossa situação
- armadilhas conhecidas

São proibidas ligações baseadas nos teus próprios conhecimentos
sem confirmação através de uma ligação. Se não conseguires encontrar
um precedente, diz isso explicitamente.

O efeito na prática. O Claude vai ao mundo e traz abordagens verificáveis. Surgem ligações para issues no GitHub e documentação. Se o Claude não conseguir encontrar precedentes, é um sinal de que a tarefa é invulgar ou de que o sintoma está formulado incorretamente. Volte ao passo 1.

Quando isto falha. O Claude pode citar uma ligação inexistente. Trata-se de uma alucinação do género «aqui está a issue número 4291 no repositório X», quando, na realidade, a issue 4291 é sobre outra coisa. Resolva isto com uma regra explícita no CLAUDE.md: «abre sempre a ligação com WebFetch antes de a citar». Consulte o guia para configurar corretamente o CLAUDE.md para obter mais detalhes.

Passo 3. Um plano detalhado em plans/ com riscos previstos#

Agora, o Plan Mode está a funcionar como previsto. O prompt:

Escolhe a melhor opção do passo 2 e escreve um plano
pormenorizado no ficheiro plans/YYYY-MM-DD-fix-[name].md:

- que ficheiros específicos vamos alterar (caminhos completos e números de linha)
- o que vamos acrescentar e o que vamos remover
- que testes vamos escrever e quais dos existentes têm de passar
- riscos com dois a três passos de antecedência (o que pode deixar de funcionar para os utilizadores)
- um plano de reversão caso algo corra mal

Transforma cada passo numa caixa de verificação [ ]. O ficheiro tem de caber num ecrã.
Se o plano tiver mais de 200 linhas, divide-o em fases.

O resultado. O plano passa a ser um artefacto, em vez de uma nota temporária no chat. Pode lê-lo duas semanas depois, entregá-lo a outro agente ou usá-lo como condição para o comando /goal. Um ficheiro de plano dura mais do que a conversa no Claude Code.

A parte fundamental são os riscos previstos com dois ou três passos de antecedência. Isto bloqueia outro padrão de bajulação: um plano otimista sem efeitos secundários. Quando pede explicitamente ao Claude que enumere os riscos, ele encontra coisas que teria ignorado silenciosamente num plano normal.

Passo 4. Faça uma autoavaliação do plano — detete pressupostos bajuladores#

O filtro final. O prompt:

Agora faz uma autoavaliação obrigatória. Relê o teu plano com honestidade.

Há pontos que inventaste e que não confirmaste através de:
- código que leste;
- documentação que citaste no passo 2;
- um precedente do passo 2?

Se houver, assinala-os explicitamente, revê-os ou elimina-os.

Verifica também:
- se menciona bibliotecas que ainda não estão instaladas
  em package.json;
- se menciona variáveis de ambiente que não especifiquei;
- se o plano tem passos descritos em termos gerais
  em vez de pormenorizados.

O que faz. O Claude tem de voltar a verificar o seu próprio raciocínio. Na amostra do autor, de cerca de 50 ciclos, pelo menos dois ou três itens do plano são revistos especificamente no passo 4. São pontos por onde o bajulador tentou passar no passo 3 e que o passo 4 deteta.

Depois dos quatro passos, o plano está pronto para ser aprovado. Pode avançar para a implementação sem se preocupar: «E se tiver de reverter 8 commits?»

Porquê exatamente 4 passos, e não 2 ou 7?#

Eis o raciocínio, seguindo o método que a Anthropic usa para orientar o Claude na sua documentação oficial.

A documentação recomenda um fluxo de trabalho em quatro fases: Explore, Plan, Implement, Commit.

O meu ciclo de 4 passos é uma especialização da fase Plan para combater a bajulação. Das quatro fases da Anthropic, desenvolvo uma em quatro micro-passos: proibir soluções, procurar precedentes, escrever o plano e fazer uma autoavaliação. Trata-se de um plano detalhado que é depois transmitido às fases Implement e Commit.

Eis o que corre mal se saltar qualquer um dos quatro passos:

A tabela deixa-o claro: cada passo bloqueia a sua própria classe de erros. Precisa dos quatro porque cada um deteta uma categoria diferente. Se a tarefa parecer suficientemente pequena para dois passos, então é mesmo pequena — e não precisa de usar o Plan Mode.

Como se relacionam plans/, o comando /goal e os passos seguintes#

O ciclo funciona num sistema que inclui:

1. Plan Mode ativado (duplo Shift+Tab no Claude Code).
2. Uma pasta plans/ no repositório para guardar os planos.
3. Opcionalmente, o comando /goal para implementar planos longos de forma autónoma.

Mais especificamente, sobre a pasta plans/. Depois do passo 3, obtém um ficheiro plans/2026-05-27-fix-magic-link.md com fases e caixas de verificação. É um artefacto. Abra-o uma semana depois e lembrar-se-á do motivo por que escolheu aquela abordagem. Daqui a três meses, encontrará uma tarefa semelhante e reutilizá-la-á. Daqui a seis meses, mostrá-la-á a um colega e poupar-lhe-á duas semanas de integração. A pasta plans/ faz parte do conceito de «segundo cérebro» no Claude Code.

Mais especificamente, sobre /goal. Depois de concluir os quatro passos e aprovar o plano, sai do Plan Mode e introduz:

/goal executar todas as fases de plans/2026-05-27-fix-magic-link.md,
todos os testes em test/auth passam ou parar após 30 turnos

Numa sessão local do Claude Code, mantenha o terminal em execução, o computador acordado e a rede disponível. Não feche o portátil sem ter configurado explicitamente uma forma suportada de o manter acordado. Ao regressar, examine o histórico: pode indicar conclusão, limite de turnos, pedido de permissão ou erro. Um objetivo não garante progresso enquanto a máquina dorme. Sem o ciclo de 4 passos, o /goal desperdiça tokens em iterações inúteis. Com o ciclo de 4 passos, o /goal leva um plano concluído até aos testes passarem.

O que fazer a seguir. Se está a começar a utilizar o Claude Code, experimente o ciclo na próxima tarefa não trivial. Não um erro tipográfico. Algo que envolva 3+ ficheiros ou um comportamento que não compreenda totalmente. Pegue nos prompts acima, copie-os e preencha os seus próprios detalhes. Vai notar como muda a taxa de reversões.

Se já utiliza o Plan Mode, acrescente uma pasta plans/ ao seu repositório. Defina consigo próprio um formato para os nomes dos ficheiros: YYYY-MM-DD-feature-name.md. Dentro de um mês terá 20–30 ficheiros; dentro de seis meses, mais de uma centena. É assim que se constrói o segundo cérebro do projeto: um histórico vivo de decisões. Se quiser aprofundar a gestão do contexto antes do prompt, abordei a engenharia de contexto no Claude Code como disciplina autónoma.

Se já tem o Plan Mode e plans/, experimente /goal numa tarefa autónoma. Escolha uma tarefa que normalmente faria à mão em 30–40 minutos. Execute-a pelos 4 passos, guarde o plano, inicie /goal e mantenha o terminal local e o computador acordados. Para trabalhar com esse computador desligado, configure primeiro um percurso remoto ou na nuvem e confirme que a tarefa está efetivamente em execução aí.