Como fazer o Claude discordar de você em vez de concordar com tudo

Você joga a ideia no chat, o Claude responde "ótima ideia!" e você fica com a sensação de ter conversado com um espelho

Não é falta de capacidade do modelo, ele consegue te confrontar muito bem quando é isso que você pede

O problema mora na FORMA do pedido, e esse comportamento tem nome técnico, tem documentação e tem lugar certo pra você configurar

Neste post: como formular o pedido pra receber objeção em vez de aplauso, onde deixar essa instrução fixa em cada produto e como filtrar o que volta sem tratar toda crítica como sentença 🙂

Por que o Claude tende a concordar com você

O nome do fenômeno é sicofantia (sycophancy): o modelo concordar com o usuário em vez de dizer o que acredita ser verdade

Isso não é impressão de internet, é objeto de estudo

O artigo Towards Understanding Sycophancy in Language Models, com participação da Anthropic, mostrou o padrão em cinco assistentes de IA de ponta em tarefas de texto livre

E tem um detalhe que dói: o artigo aponta que tanto humanos quanto modelos de preferência às vezes preferem uma resposta sicofântica bem escrita à resposta correta

Ou seja, a bajulação bem redigida ganha da verdade mal embalada… e o treino aprende com essa preferência

O que a Constituição do Claude diz sobre isso

A Anthropic publicou uma nova Constituição do Claude em janeiro de 2026, e ela é bem direta no assunto

Honestidade acima de simpatia: o modelo deve afirmar apenas o que acredita ser verdade, mesmo quando não é o que a pessoa quer ouvir

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

Bajulação é tratada como algo que vai contra o bem-estar do usuário, o texto diz que o Claude deve evitar ser sicofântico ou estimular dependência excessiva nele mesmo

E tem a parte que eu acho a mais massa de todas: preservação da autonomia epistêmica

Oferecer perspectivas equilibradas, ter cautela ao promover as próprias opiniões, favorecer o pensamento independente e respeitar o direito da pessoa de chegar às próprias conclusões

A constituição ainda ordena as propriedades desejadas por prioridade explícita: amplamente seguro, amplamente ético, aderente às diretrizes e, por último, genuinamente útil

Repara que "útil" é o ÚLTIMO da fila, não o primeiro

E os modelos mais novos melhoraram?

Melhoraram, sim

O Claude Sonnet 5 foi lançado em 30 de junho de 2026 e o system card registra melhora acentuada em sicofantia e em alucinação em relação ao Sonnet 4.6

Ele também é apontado como o modelo Claude mais forte na medida MASK de desonestidade sicofântica

Mas o mesmo system card traz o efeito colateral: um leve aumento das respostas "wet blanket", aquele tom excessivamente desencorajador, dispensivo ou moralizante

Conclusão prática: a tendência de concordar caiu, não sumiu, e agora existe também o risco do oposto

Em qualquer um dos dois cenários, a alavanca que está na sua mão é a mesma: o pedido

O que você precisa antes de começar

Antes de sair colando prompt, escolhe ONDE isso vai morar

Instrução solta no chat evapora, instrução em arquivo persistente volta em toda conversa

E aqui vale um aviso: os produtos são diferentes, o que existe no Claude Code não existe do mesmo jeito no Claude.ai

No Claude Code:

As instruções persistentes ficam nos arquivos CLAUDE.md, e dentro da sessão o comando /memory lista e abre esses arquivos de memória (CLAUDE.md, CLAUDE.local.md e os demais locais, em escopo de usuário e de projeto)

Os output styles são arquivos markdown que alteram o system prompt, guardados em ~/.claude/output-styles (usuário) ou .claude/output-styles (projeto)

Eles mudam COMO o Claude responde, não o que ele sabe

Além do padrão, já vêm embutidos o Default, o Proactive, o Explanatory e o Learning

Já as skills pessoais ficam em ~/.claude/skills/<nome>/SKILL.md, cada uma numa pasta, com frontmatter YAML entre marcadores --- aceitando campos como name e description

O description é o campo recomendado pro Claude saber QUANDO usar aquela skill, então caprichar nele importa mais do que parece

Se você ainda está montando seu ambiente, dá uma olhada no fluxo completo do Claude Code antes de sair mexendo nesses arquivos

No Claude.ai:

As instruções de perfil valem pra todas as conversas da conta

As instruções de projeto valem só dentro daquele projeto

E as Skills são pastas de instruções e recursos carregadas dinamicamente: você cria uma vez e ela funciona em qualquer conversa, inclusive dentro de projetos

Uma nota importante: o menu de estilos está sendo removido e os estilos existentes estão migrando para Skills, ativadas no chat por um comando de barra no formato /{nome-do-estilo}-style

Até a migração terminar, os estilos existentes continuam disponíveis ao lado das Skills

Escolhe UM lugar, beleza? Espalhar a mesma instrução em quatro arquivos não deixa o Claude quatro vezes mais crítico, só deixa você sem saber de onde veio o comportamento quando algo sair estranho

Passo a passo: como pedir o contraponto em vez da validação

A sequência abaixo é pra copiar e adaptar

Cada passo tem o texto do pedido e o erro comum que faz ele não funcionar

1. Descreva a ideia sem se declarar dono dela

Em vez de "minha ideia é migrar o banco pra X", escreva "existe uma proposta em avaliação: migrar o banco pra X"

Parece bobo, mas você está tirando o seu ego da mesa antes de pedir avaliação

O erro comum deste passo: abrir com "minha ideia", "o que eu pensei", "acabei de montar isso". Você está pedindo elogio sem perceber

2. Nomeie o papel e a tarefa, com saída concreta

Papel vago ("seja crítico") gera crítica vaga

Avalie a proposta acima no papel de revisor técnico cético

Entregue, em listas separadas:
1. riscos concretos, do mais provável pro menos provável
2. hipóteses que a proposta assume como verdade e ainda não foram verificadas
3. o cenário específico em que essa proposta falha feio

O erro comum deste passo: pedir "me dê feedback". Feedback é um balde onde cabe elogio

3. Peça a posição contrária construída na forma mais FORTE possível

Ressalva morna não serve pra nada, você quer o melhor argumento que existe do outro lado

Agora construa o caso contra essa proposta na versão mais forte que existir

Escreva como se você precisasse convencer alguém que já está inclinado a aprovar

Não suavize, não abra com concessões, não termine dizendo que no fim depende

O erro comum deste passo: aceitar a resposta que começa com "apesar de ser uma boa abordagem". Isso é elogio com fantasia de crítica

4. Exija critério explícito de abandono

Essa é a pergunta que separa análise de conversa fiada

Qual evidência específica me faria abandonar essa proposta?

Descreva um teste, uma medição ou um fato observável que, se acontecer, mata a ideia

O erro comum deste passo: aceitar critério impossível de observar ("se não escalar bem"). Escalar mal COMO? Medido em quê?

5. Peça separação entre objeção de fato e objeção de preferência

As duas coisas voltam misturadas no mesmo parágrafo e é aí que você se perde

Marque cada objeção da sua lista com uma etiqueta:

FATO: quando ela se apoia em algo verificável, e diga como eu verifico
PREFERÊNCIA: quando ela é uma escolha de estilo, gosto ou convenção

O erro comum deste passo: tratar preferência de estilo como bloqueio técnico e refazer meio projeto por causa disso

6. Fixe tudo no arquivo persistente que você escolheu

No Claude Code, um trecho assim dentro do CLAUDE.md:

## Como avaliar propostas minhas

Antes de concordar, liste riscos e hipóteses ainda não verificadas
Construa a posição contrária na versão mais forte dela, sem ressalva morna
Diga qual evidência específica derruba a proposta
Marque cada objeção como FATO (com o caminho de verificação) ou PREFERÊNCIA
Se concordar, diga POR QUE concorda e o que precisaria ser verdade pra você mudar de posição
Não abra respostas com elogio à ideia

Se preferir empacotar como skill pessoal, o esqueleto do arquivo é este:

---
name: advogado-do-diabo
description: Usar quando eu apresentar uma ideia, plano, arquitetura ou texto e pedir avaliação. Lista riscos, hipóteses não verificadas, a posição contrária mais forte e o critério de abandono.
---

# Advogado do diabo

Quando esta skill estiver ativa, avalie a proposta antes de qualquer elogio

Entregue riscos, hipóteses não verificadas, o caso contrário na forma mais forte,
o critério explícito de abandono e a etiqueta FATO ou PREFERÊNCIA em cada objeção

O erro comum deste passo: escrever o description genérico tipo "ajuda com análise". Se a descrição não diz QUANDO usar, a skill fica lá parada

Modelos de pedido para as situações mais comuns

O esqueleto é o mesmo, o que muda é o que você manda ele atacar primeiro

Decisão de arquitetura ou stack:

Proposta em avaliação: descreva aqui a arquitetura e as restrições reais do projeto

Ataque nesta ordem:
1. o custo de reverter essa decisão daqui a seis meses
2. o que ela assume sobre volume, time e manutenção que ainda não foi verificado
3. a alternativa mais simples que resolve o essencial do problema

Se a alternativa mais simples for suficiente, diga isso na primeira linha

Aqui o que muda é o foco no custo de REVERSÃO, porque decisão de arquitetura erra caro e demora a doer

Plano de conteúdo ou de produto:

Plano em avaliação: cole aqui o plano, passo a passo

Me diga qual parte dele existe só porque parece produtiva, e não porque resolve o problema declarado

Aponte o passo que, se eu cortar, muda pouco no resultado final

Depois aponte o único passo que, se eu cortar, quebra tudo

Plano gosta de inchar, então o pedido aqui é de PODA, não de acréscimo

Revisão de código que você já escreveu:

O código abaixo já está escrito e já funciona no caminho feliz

Não comente estilo nem formatação

Procure: caso de borda não tratado, erro engolido em silêncio, suposição sobre o dado de entrada
que não está validada e comportamento diferente entre ambiente local e produção

Para cada achado, mostre a linha e o insumo exato que provoca o problema

O detalhe que salva tempo: proibir comentário de estilo explicitamente, senão a resposta enche de nomenclatura e você perde o bug de verdade

Texto pronto pra publicar:

Texto em avaliação, já finalizado

Aponte: afirmação que eu não sustentei com nada, parágrafo que promete algo que o texto não entrega
e trecho onde eu escrevi com confiança sobre algo que não verifiquei

Não reescreva o texto, só marque os trechos e explique o problema de cada um

"Não reescreva" é a parte importante… senão você recebe uma versão nova e nunca descobre o que estava errado na sua

Quando a crítica volta errada: o que fazer

Dois sintomas opostos aparecem, e o remédio de um piora o outro

Sintoma 1: ele voltou a concordar depois de algumas mensagens

A causa quase sempre é dupla

Primeiro: a instrução estava só no chat, sem persistência, e foi ficando pra trás conforme a conversa andou

Segundo: o SEU texto começou a puxar concordância. Frases como "acho que resolvi", "ficou bom assim, né?" ou "então tá certo" são convite pra bajulação

A solução é mover a instrução pro arquivo persistente que você escolheu lá em cima e reformular o pedido em vez de repetir "seja crítico"

Em vez de perguntar "ficou bom?", pergunte "o que ainda está errado aqui?"

Como prevenir: nunca peça avaliação e aprovação na mesma mensagem

Sintoma 2: virou crítica desencorajadora em TUDO

Esse é o outro lado da moeda, e ele está documentado

O system card do Claude Sonnet 5 registra, junto com a melhora em sicofantia, um leve aumento das respostas "wet blanket", aquele tom excessivamente desencorajador, dispensivo ou moralizante

A correção não é pedir menos crítica, é pedir PESO e critério

Ordene suas objeções por impacto real, da que mata o projeto até a cosmética

Diga quais delas você largaria se eu tivesse tempo pra resolver apenas duas

Se alguma objeção for de risco baixo, diga que é de risco baixo em vez de listar tudo no mesmo tom

Como prevenir: sempre peça a lista ordenada, nunca a lista solta. Volume de objeção não é qualidade de análise

Como avaliar o que volta

Essa parte é sua e não terceiriza

Objeção NÃO é veredito, é hipótese sobre um problema

Para cada uma, pergunta: isso se apoia num fato que eu consigo verificar, ou é preferência bem escrita?

Se é fato, verifica antes de mudar qualquer coisa

Se é preferência, decide se ela combina com o seu contexto e segue a vida

E lembra da autonomia epistêmica que a Constituição do Claude prevê: perspectivas equilibradas, cautela do modelo em promover as próprias opiniões e respeito ao seu direito de chegar às suas próprias conclusões

Trocar "o Claude concordou comigo" por "o Claude discordou de mim, então tá errado" é o mesmo erro com o sinal invertido

A conclusão continua sendo sua 😀

Conclusão

A tendência de concordar tem nome (sicofantia), tem estudo com participação da Anthropic mostrando o padrão em cinco assistentes de ponta e tem contrapeso na Constituição do Claude, que coloca honestidade acima de agradar

Os modelos melhoraram nisso, o system card do Sonnet 5 registra melhora acentuada, mas quem puxa a alavanca é o seu pedido

Descreva a ideia sem se declarar dono dela, nomeie o papel, peça a posição contrária na forma mais forte, exija critério de abandono e separe fato de preferência

E o arquivo persistente é o que segura tudo isso de pé quando a conversa esfria

Próximo passo, hoje mesmo: escolhe UM lugar de persistência (CLAUDE.md no Claude Code ou instruções de projeto no Claude.ai), cola a instrução e usa na próxima decisão real que você tiver que tomar

Depois volta aqui e me conta se o "ótima ideia!" sumiu 😛

até o próximo post!