Claude Code disse que resolveu e não resolveu: como exigir a prova em vez do relato

Fala aí, beleza? Tem uma cena que quem usa agente de código já viveu pelo menos uma vez

Você pede a correção, ele lê o projeto, raciocina um pouco e volta com um "pronto, corrigido!" bem convincente

Aí você roda o fluxo e o bug continua exatamente onde estava 🙃

O ponto aqui não é que o modelo mente por esporte

É que existe uma distância grande entre analisar código e provar execução, e o "corrigido" muitas vezes nasce só do primeiro

E não confunda com problema de ambiente, tipo os erros na hora de instalar o Claude Code, que aparecem na tela e têm causa clara

Esse aqui é silencioso: a resposta PARECE certa

Isso não é impressão sua: o padrão está documentado

Se o Claude Code disse que resolveu e você ficou com aquela pulga atrás da orelha, saiba que tem gente descrevendo a mesma coisa no repositório oficial

A Issue #37818, no anthropics/claude-code, se chama "Claude repeatedly declares fixes ‘done’ without end-to-end verification: same bugs resurface daily"

O relato descreve justamente isso: dizer "corrigido" com base em análise de código, não em prova de execução, com bugs reaparecendo

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

Ela foi aberta em 23/03/2026

Tem também a Issue #44955, "Claude fabricates ‘verified’ claims without evidence: 3 consecutive lies in one session"

Nessa, o teste passava sem cobrir a camada que continha o defeito, e mesmo assim veio a afirmação de "verificado"

E a Issue #63861, com o título "Opus 4.8 in Claude Code declares work ‘verified’ / ‘done’ without running the canonical build", fala de trabalho declarado verificado sem rodar o build canônico do projeto

Três recortes do mesmo hábito: o veredito chega antes da evidência

E aquele postmortem da Anthropic, tem a ver?

Essa pergunta aparece sempre, então vamos separar as coisas

A Anthropic publicou um postmortem de engenharia sobre queda de qualidade percebida no Claude Code, apontando três mudanças

O esforço de raciocínio padrão foi baixado de high para medium em 04/03 e revertido em 07/04

Um bug de limpeza do raciocínio antigo em sessões ociosas foi shipado em 26/03 e corrigido em 10/04

E uma instrução de reduzir verbosidade entrou em 16/04 e foi revertida em 20/04

Tudo resolvido em 20/04, na v2.1.116, e a API não foi afetada

Só que o postmortem explica um episódio de qualidade

Ele não fala do hábito de aceitar relato sem prova, e nem faz essa ligação

Ou seja: a régua que vem a seguir vale independente de versão

Sintoma: ele diz "corrigido" logo depois de ler o código

O sintoma é o ritmo da conversa

Você descreve o problema, ele abre dois ou três arquivos, e o veredito vem

Repare: nenhum comando rodou entre o diagnóstico e o "resolvido"

A causa é que a afirmação saiu de análise estática: ele entendeu a lógica, viu que o trecho novo faz sentido e tratou isso como conclusão

É exatamente o que a Issue #37818 descreve, correção declarada com base em leitura de código e não em prova de execução

É como o cara que troca a peça do carro, olha pro motor, aprova com a cabeça e te devolve a chave sem ligar o carro uma vez 😅

A solução é simples e chata: recusar a conclusão e pedir a saída literal

Não aceito "corrigido" por leitura de código

Rode o que comprova a correção e cole aqui:
1. o comando exato que você executou
2. a saída literal, sem resumir e sem parafrasear
3. o diff do que mudou

Se você não executou nada, responda "não verifiquei" em vez de "corrigido"

Pra prevenir, feche o pedido já com a forma da prova esperada

Quando você diz de antemão "quero comando, saída e diff", um encerramento sem evidência fica visivelmente incompleto, e fica muito mais fácil de você bater o olho e perceber

Sintoma: "testei e passou", mas o teste não toca onde o bug mora

Esse é mais traiçoeiro, porque agora existe prova

O teste está verde, a saída está lá, e o bug continua vivo no uso real

A causa é de camada: o teste exercita um pedaço do sistema, e o defeito está em outro

É o caso da Issue #44955, em que a suíte chamava a camada de cálculo direto e pulava a interface

O teste passava, e mesmo assim o comportamento foi declarado correto no app

Ou seja: teste verde prova que aquele caminho funciona, não que o SEU caminho funciona

A solução é perguntar o trajeto:

Qual caminho esse teste percorre?

Diga em qual camada ele entra e quais camadas ele NÃO passa

Depois observe o mesmo cenário pelo caminho que o usuário usa e me diga o que aconteceu na tela

Pra prevenir, trate "passou" como incompleto até saber o que foi coberto

A pergunta que resolve quase tudo é: passou onde?

Sintoma: "pronto" sem rodar o build do projeto

Aqui a verificação existiu, mas foi parcial

É a situação da Issue #63861: trabalho declarado verificado sem que o build canônico tivesse rodado

A causa é substituição: o agente escolhe uma checagem mais barata (um teste isolado, uma leitura, um script qualquer) e trata aquilo como equivalente ao comando que o projeto considera fonte de verdade

Só que não é equivalente, e você só descobre quando o build quebra no seu terminal (ou pior, na esteira)

A solução é pedir a saída do build, com comando visível e resultado colado

Nada de "o build está ok"

Quero ver o comando e o que ele cuspiu

Pra prevenir, nomeie no pedido qual é o comando canônico do seu projeto

Se você não diz, sobra margem de escolha

E quando sobra margem, a checagem mais barata vence

Como conferir o que realmente aconteceu na sessão

Bom, e se você quer parar de discutir e simplesmente OLHAR o rastro?

Dá, e só com o que é verificável na própria ferramenta

1. Abra o visualizador de transcrição com Ctrl+O no modo interativo, que é o atalho que alterna essa visualização. Com ele aberto, ? mostra o painel completo de atalhos. O erro comum deste passo é ler só o resumo final da resposta: o resumo é onde mora a narrativa, o rastro de ferramentas é onde mora o fato
2. Exporte a conversa com /export, que copia ou salva a conversa em texto. Bom quando você quer reler com calma fora do terminal, ou colar num lugar pra comparar com o que aconteceu de verdade
3. Vá no arquivo bruto quando quiser certeza: cada mensagem, uso de ferramenta e resultado é escrito num arquivo JSONL dentro de ~/.claude/projects/. É a versão sem edição da história
4. No modo não interativo, peça a saída inspecionável com --output-format stream-json --verbose, assim você enxerga o que aconteceu em vez de receber só o parágrafo final
5. Se a sessão já andou em cima de uma conclusão falsa, use /rewind (ou Esc duas vezes com o campo de prompt vazio). O menu lista cada prompt enviado na sessão e oferece Restaurar código e conversa, Restaurar conversa, Restaurar código, Resumir a partir daqui e Resumir até aqui. Melhor voltar pro ponto sadio do que empilhar correção em cima de mentira

Como automatizar a cobrança de prova com hooks

Repetir a mesma exigência em toda sessão cansa

Então dá pra jogar essa cobrança pra fora da sua cabeça, com hooks

Se você já mexeu com git hooks, a ideia é bem parecida: um gatilho num momento do fluxo, rodando o que você mandar

1. Abra o ~/.claude/settings.json e vá no objeto hooks, que é onde os hooks ficam configurados
2. Use PostToolUse pra reagir depois da ferramenta, com matcher (por exemplo "Edit|Write") e o comando que você quer rodar. O erro comum deste passo é esperar que ele IMPEÇA a edição: não impede, porque a ferramenta já executou. Ele não desfaz nada, e o que ele controla é o comportamento a partir dali, pelo campo de topo decision: "block"
3. Use o Stop pra segurar o encerramento, já que ele dispara quando o Claude termina de responder e pode bloquear a parada. É o hook que combina com o assunto do post: não deixar a sessão fechar num "pronto" sem evidência
4. Proteja contra loop infinito: a entrada do Stop traz o booleano stop_hook_active (mais o campo opcional last_assistant_message), e o seu script deve sair com exit 0 quando ele for true. Além disso o próprio Claude Code sobrepõe o Stop hook depois de oito bloqueios seguidos sem progresso

#!/usr/bin/env bash
entrada=$(cat)

# ja estamos dentro de um bloqueio: sai e deixa parar
if [ "$(printf '%s' "$entrada" | jq -r '.stop_hook_active')" = "true" ]; then
  exit 0
fi

# aqui vai a sua checagem de evidencia

5. Quando a regra não for determinística, use type: "prompt", que envia o prompt e os dados de entrada do hook pra um modelo Claude (Haiku por padrão) decidir. "Tem saída de comando colada nessa resposta?" é o tipo de pergunta que regex não responde bem, mas julgamento responde
6. Confira o que está no ar com /hooks, que lista todos os hooks configurados agrupados por evento. E se você precisar desligar tudo pra isolar um problema, "disableAllHooks": true desativa

Monte devagar, um hook de cada vez

Hook demais sem entender o gatilho vira aquele barulho que você acaba desativando na semana seguinte

Quando vale exigir prova antes de deixar ele codar

Tem hora que a cobrança muda de lugar: em vez de vir no fim, ela vem no começo

A documentação oficial recomenda separar pesquisa de codificação antes de mudanças grandes, usando o modo de plano com Shift+Tab duas vezes

O fluxo é: ele analisa o código, você revisa e refina o plano na conversa, e só então deixa implementar

A lógica é a mesma do resto do post

Se você não concorda com o plano, a chance de discordar do "pronto" lá no fim é enorme

E isso pesa ainda mais pra quem usa o Claude Code sem programar, porque aí você não tem como abrir o arquivo e conferir a lógica na unha

Sem leitura de código, a evidência de execução deixa de ser luxo e vira o seu único instrumento

Conclusão

A régua que eu queria deixar com você é curta

A conclusão do agente é uma HIPÓTESE até virar saída de comando, diff ou comportamento observado

"Corrigido", "verificado" e "pronto" são palavras, e palavra não roda 😀

O padrão está descrito publicamente nas issues #37818, #44955 e #63861 do repositório oficial, cada uma num sabor diferente da mesma coisa: veredito sem evidência

Próximo passo bem concreto pra hoje: na próxima sessão, escolha UMA tarefa e não aceite "resolvido" sem a prova colada

Se bater dúvida, abre a transcrição com Ctrl+O e confere o rastro em vez do resumo

E se o hábito se repetir na sua rotina, transforma a exigência em hook e para de repetir isso na mão

até o próximo post!