Confiei no Claude: 3 vieses da era IA que peguei
Rodei o Claude Code por 3 semanas em modo agente no meu lab caseiro em Tóquio. RTX 4070, um monorepo de uns 40 mil linhas, três projetos paralelos. Deleguei bastante coisa. Achei que estava usando IA bem.
Perdi três decisões críticas em três semanas. Não por bug do Claude. Por mim confiando de formas diferentes em três momentos diferentes.
Cada uma virou um viés cognitivo com nome: automação, ancoragem, deferência. Todos os três estão documentados desde antes da IA generativa existir. O que muda em 2026 é que agora tem um agente executando código no seu terminal, e o gatilho fica muito mais barato.
Um estudo randomizado da METR em 2025 já mostrou o padrão: engenheiros open source experientes, usando IA, achavam que ficaram mais rápidos e na verdade ficaram mais lentos. A distância entre o que a gente sente e o que o cronômetro mede é o território onde esses três vieses moram.
Viés 1: Automação — "compilou, então está certo"
A primeira armadilha foi na semana 1. Pedi ao Claude para migrar um script de deploy do bash antigo para uma versão com error handling decente. Ele devolveu 80 linhas, rodou local, saída verde. Merge.
Três dias depois, o cron falhou silenciosamente às 3 da manhã porque o set -e que eu tinha antes desapareceu na reescrita. O Claude tinha "melhorado" o error handling substituindo o set -e global por try/catch bash artesanal em cada função. Duas funções ficaram sem o wrapper. Elas engoliram o erro e o script terminou com exit 0.
Isso é viés de automação clássico: confiar demais na saída de um sistema automatizado só porque parece funcionar. Fenômeno conhecido em aviação desde os anos 90. A Georgetown CSET publicou em 2024 o relatório "AI Safety and Automation Bias" tratando do mecanismo, e a mesma organização publicou no mesmo ano um brief sobre riscos de código gerado por IA.
O truque na era IA é que "funciona" tem três definições e a gente só verifica uma:
- Compila: o código passa no parser. Trivial.
- Executa sem crash: rodou uma vez, saiu verde. Enganoso.
- Faz o que eu queria: precisa checagem semântica que só humano faz.
O Claude entrega os dois primeiros com facilidade. O terceiro é meu. Eu esqueci que era meu.
O contra-hábito que adotei: antes de aceitar qualquer reescrita de script crítico, rodo um diff mental e pergunto "o que a versão nova removeu?". Não "o que ela adicionou". O que sumiu.
Se você trabalha com CLT ou PJ em empresa BR, o mesmo padrão aparece com agente rodando pipeline de CI/CD ou deploy no Nubank, PicPay, iFood — o gatilho é o mesmo, muda o custo do incidente.
Viés 2: Ancoragem — a primeira sugestão vira a única
Semana 2. Precisava desenhar o schema de uma tabela nova para armazenar histórico de execuções de agentes. Perguntei ao Claude "qual seria uma boa estrutura?".
Ele devolveu 8 colunas, com JSON blob para o "resultado". Aceitei o esqueleto e comecei a refinar em cima. Discutimos índices, discutimos tipos, discutimos partition strategy. Duas horas depois eu tinha um schema bonito construído em cima daquela primeira sugestão.
Uma semana depois percebi que a estrutura estava errada no eixo mais básico: eu deveria ter usado event sourcing (uma linha por evento), não snapshot (uma linha por execução com JSON gordo). Se eu tivesse escrito a pergunta do zero sem pedir sugestão ao Claude primeiro, event sourcing teria sido a primeira coisa a passar pela minha cabeça.
O que aconteceu foi ancoragem. A primeira sugestão da IA fica na minha cabeça como ponto de partida, e todas as correções partem dali. Pesquisa empírica em engenharia de software já mostra o padrão: um estudo publicado em Information and Software Technology (2025), "Don't settle for the first!", indica que aceitar a primeira sugestão do Copilot costuma ser subótimo e que checar várias alternativas melhora o resultado.
O leque mental estreita. Uma abordagem que viria à cabeça naturalmente some do meu radar no segundo em que o Claude joga a primeira opção na tela.
O contra-hábito: antes de pedir sugestão ao Claude para uma decisão de design, escrevo minha primeira ideia em um comentário // no arquivo. Duas linhas. Não precisa estar certa. Só precisa existir antes da resposta dele. Assim eu tenho uma âncora minha para comparar, não só a dele.
Truque secundário: pedir "sugira três abordagens diferentes" em vez de "sugira uma". O Claude entrega três, e ver as três lado a lado devolve o leque que o modo pergunta-única estreita.
Viés 3: Deferência — "ele explicou com confiança"
Semana 3, a mais cara. Estava investigando um bug de race condition em um worker de fila. Perguntei ao Claude a causa provável. Ele analisou o código e respondeu com um parágrafo articulado sobre reordering de operações no event loop do Node.js, citando timing de setImmediate vs process.nextTick.
Soou coerente. Bati o dedo no teclado, comitei um fix baseado na explicação. Testei em staging, deu certo. Deu certo pela razão errada.
O bug real era um await faltando três funções acima na stack. O fix do Claude mascarou o sintoma coincidentemente porque introduziu um delay que ordenou as operações por acaso. Uma semana depois o mesmo bug voltou em uma execução com carga diferente.
Isso é deferência à autoridade, virada para LLM. A saída do Claude vem com tom enciclopédico, sintaxe segura, exemplos concretos. Esse tom autoritativo dispara o mesmo circuito mental que aciona quando um senior developer fala "isso é assim". A OWASP Top 10 for LLM Applications cataloga esse risco — em versões anteriores como "Overreliance", e na versão 2025 renomeado para "Misinformation" (LLM09:2025) — exatamente por essa combinação.
Quando um colega humano diz "acho que é assim", eu verifico. Quando o Claude declara "esta é a causa", a barreira de verificação cai sem eu perceber. Passa como conhecimento validado quando na verdade é probabilidade condicionada em texto.
O contra-hábito mais eficaz: pedir ao mesmo Claude "liste três fraquezas dessa análise". Ele lista. Externaliza o Sistema 2 de forma forçada. Se depois das três fraquezas a análise ainda parece sólida, aí sim eu confio mais. Se aparece uma fraqueza que eu não tinha pensado, provavelmente a causa raiz está em outro lugar.
Também aprendi a não aceitar explicações causais sem rodar um experimento que refute. No caso do race condition, deveria ter reproduzido o bug com um Promise.all sintético antes de aceitar a explicação sobre event loop.
O padrão comum: o custo de verificar sumiu
Os três vieses acima existem há décadas. O que muda com o Claude é que o custo de aceitar uma resposta caiu para zero. Compilar? Automático. Refatorar? Um comando. Reescrever schema? Uma pergunta.
Quando o custo de aceitar cai, o custo relativo de verificar sobe. Sistema 1 (rápido, automático) vence Sistema 2 (lento, deliberado) por padrão. Os vieses cognitivos que a psicologia catalogou nos anos 70 ganham um multiplicador de frequência em 2026.
O relatório 2025 da METR mencionado no começo faz sentido nesse mapa: engenheiros achavam que estavam mais rápidos porque o esforço cognitivo caiu. Menos esforço se traduziu em "mais rápido" na percepção, mas o cronômetro contava o tempo real, que subiu.
O único ajuste durável é tratar o Claude como ferramenta que exige verificação, não como colega cuja opinião merece respeito. A opinião do colega tem custo social alto para contestar; a saída da ferramenta é dado bruto que precisa passar por controle antes de virar decisão.
A síntese 2024 da Microsoft ("Appropriate Reliance on Generative AI: Research Synthesis", MSR-TR-2024-7) sistematiza "appropriate reliance" — conceito já discutido em HCI antes disso — para o contexto GenAI: nem negar tudo, nem aceitar tudo, ajustar o grau de confiança conforme a natureza da tarefa. Foi o que tentei aplicar depois desses três incidentes.
Checklist de 30 segundos antes de aceitar sugestão de agente
Coloquei isto na parede do laboratório e revisito antes de aceitar qualquer decisão delegada:
- O que sumiu na versão nova? (contra automação)
- Escrevi minha primeira ideia antes de ver a dele? (contra ancoragem)
- Pedi para ele listar três fraquezas? (contra deferência)
Trinta segundos. Não elimina os vieses — eles são cognitivos, não desaparecem por vontade. Mas força o Sistema 2 a acordar por tempo suficiente para pegar o pior caso.
Rodo o Claude Code aqui do Japão, mas o padrão vale para qualquer engenheiro rodando agente em qualquer stack em qualquer país. Nubank, iFood, PicPay, ou lab pessoal com RTX 4070. O gatilho psicológico é o mesmo. Só muda quem paga a conta quando dá errado.
ken imoto · WebRTC & Voice AI engineer · kenimoto.dev · TabNews