3 armadilhas cognitivas em debugging: 2h → 15min

Semana passada, passei duas horas olhando para o arquivo errado.

Duas. Horas. Não é figura de linguagem. Abri o log, li TimeoutException, decidi na hora que “era rede”, e fui direto para o módulo de HTTP client. Investiguei retry, backoff, connection pool, DNS. Nada. E quanto mais eu não achava, mais eu me convencia de que estava perto, porque afinal, “só pode ser rede”.

Não era rede. Era um deadlock em uma transação de banco de dados aberta três funções acima. O TimeoutException era o segundo efeito, não o primeiro. Descobri isso quando abri o postmortem de um incidente parecido, de janeiro. Eu tinha o log escrito por mim mesmo com a resposta. Só que dessa vez eu já tinha decidido a hipótese antes de olhar.

Isso é armadilha cognitiva pura, e conhecimento técnico sozinho não protege. Depois desse episódio, comecei a mapear as três armadilhas que mais me pegam em depuração. As três estão em pesquisa clássica de vieses (Kahneman, Tversky, Wason). Nenhuma é nova. Mas eu não conhecia até me ver caído dentro delas.

Armadilha 1: viés de confirmação (2 horas no arquivo errado)

O viés de confirmação é a tendência de procurar prioritariamente evidências que sustentam a hipótese que você já formou, e ignorar as que contradizem. Na depuração, ele age assim:

1. Você pega uma palavra do log (TimeoutException).
2. Forma uma hipótese na primeira meia frase que consegue montar (“deve ser rede”).
3. Investiga a fundo o lado da hipótese.
4. Trata cada evidência de que a rede está bem como “coincidência” ou “vou olhar depois”.
5. Perde a evidência real (deadlock no banco) porque o filtro que separa “sinal” de “ruído” já está enviesado.

Os passos 3 a 5 são o viés operando. E o mais desconfortável é que esforço não resolve isso. Eu estava trabalhando duro, só que na direção errada.

Há inclusive pesquisa publicada no Software Quality Journal mostrando que testadores tendem a executar prioritariamente os casos que confirmam a hipótese e adiar os casos que a refutariam. Isso é humano. Não é preguiça.

Armadilha 2: heurística da disponibilidade (o incidente do mês passado)

A heurística da disponibilidade é a tendência de julgar como frequente ou importante aquilo que vem fácil à memória.

Se no mês passado eu passei uma noite investigando memory leak, no incidente deste mês minha primeira hipótese vai ser memory leak. Estatisticamente, memory leak nem é a causa mais provável. É só a que aparece primeiro na cabeça. E o que aparece primeiro na cabeça normalmente vira a hipótese que eu vou defender por mais tempo, e é aí que a armadilha 1 encaixa com essa.

O detalhe que me pega: causas nunca vividas custam a aparecer. Um engenheiro que nunca enfrentou falha de DNS não considera DNS. Ele até pode ter lido sobre isso, mas a hipótese simplesmente não sobe à cabeça na hora certa.

Fatores que reforçam disponibilidade, em ordem do que mais me pega em produção:

• Vivacidade: o bug que virou noite fica muito mais marcado do que o bug resolvido em 5 minutos.
• Proximidade temporal: o incidente da semana passada ganha do de dois meses atrás, mesmo que o de dois meses atrás seja mais parecido.
• Impacto emocional: incidente em que o cliente ligou irritado ocupa a memória inteira. O que aconteceu de madrugada e ninguém viu, ninguém lembra.

Nenhum desses fatores tem relação com a probabilidade real da causa. É só o que a memória privilegia.

Armadilha 3: anchoring (a primeira frase do log define tudo)

Anchoring é a tendência de dar peso desproporcional ao primeiro valor ou informação que você encontra. Em debugging, o que ancora é normalmente a primeira linha do log de erro. Ou o primeiro sintoma reportado pelo usuário.

No caso das duas horas, minha âncora foi a palavra TimeoutException na terceira linha do stacktrace. O tempo todo eu estava tentando explicar aquele timeout, quando o timeout era efeito secundário. A causa raiz estava três frames acima e não gerava exception por conta própria — só travava a transação.

Anchoring é insidioso porque parece racional: “estou seguindo a evidência”. Só que a ordem em que a evidência aparece no stacktrace foi decidida pelo formatador, não pela relevância da causa raiz.

Se você quiser ver o outro lado dessa moeda (a velocidade com que o cérebro reconhece um padrão de bug antes mesmo de ler o log inteiro, e como isso ajuda quando calibrado), escrevi sobre isso em seu cérebro reconhece o bug antes de ler o log. Reconhecimento rápido ajuda quando o padrão que você identificou bate com o real. O anchoring é a mesma máquina cognitiva rodando em cima de um padrão falso, e o resultado é ir na direção errada com toda a convicção.

O checklist de 4 perguntas (que corta o loop em 15 minutos)

Depois do episódio das 2 horas, montei um checklist que passo em voz alta antes de abrir o primeiro arquivo. Leva 30 segundos. As 4 perguntas:

1. “Quais são as 3 causas possíveis, não só a que veio primeiro?” Força listar múltiplas hipóteses antes de afunilar. É o antídoto direto para o viés de confirmação: quando você tem 3 na mesa, nenhuma vira ídolo.
2. “Qual evidência refutaria a hipótese 1?” Se a resposta é “sei lá”, a hipótese não é hipótese, é palpite. Boa hipótese já vem com o teste que a mata.
3. “O primeiro erro do log é causa ou efeito?” Puxa o anchoring de volta. Timeout na 3ª linha pode ser sintoma da linha 47 (ou de nenhuma linha, se é um deadlock silencioso).
4. “Já tive esse sintoma antes? Onde procuro?” Se sim, abre o postmortem antigo antes de formar hipótese nova. Isso ataca a disponibilidade pela raiz: você consulta o registro antes de confiar na memória.

Passei a rodar esse checklist antes de abrir o editor. Nos últimos 6 debugs sérios que fiz, o tempo médio até encontrar a causa raiz caiu de 90 minutos para cerca de 15. Amostra pequena, mas o padrão é claro: quase todo o tempo que eu perdia era em ler o arquivo errado. Ler código em si nunca foi o gargalo.

Uma nota sobre como Claude Code (não) me salva

Comecei a usar mais o Claude Code para depuração e ele ajuda, mas em uma dimensão diferente. O viés de confirmação dele não age como o meu: o problema dele é dar resposta plausível quando não sabe. Se eu pergunto “isso é rede?”, ele vai me responder olhando o código de rede. Se eu perguntar “isso é banco?”, ele vai olhar o banco. A hipótese vem de mim; ele executa a busca.

Se eu entro no diálogo já ancorado, ele amplifica a minha âncora. Se eu entro com o checklist de 4 perguntas, ele vira multiplicador de busca. Já escrevi sobre um caso mais grave, em que ele escondeu o bug 3 vezes, em peguei o Claude escondendo bug 3 vezes. Junto com as armadilhas humanas, dá para montar um roteiro que fecha os dois lados.

Fechando

Depurar rápido depende de uma coisa só: não deixar a primeira hipótese fechar as outras.

As três armadilhas (viés de confirmação, disponibilidade, anchoring) são o modo padrão do Sistema 1 quando estresse é alto, tempo é curto e informação é incompleta. Ou seja, exatamente as condições de qualquer incidente de produção. Inteligência não protege ninguém desse padrão. Confiar na atenção individual funciona menos justamente no momento em que o viés age mais forte. Por isso o checklist. Mecanismo bate atenção quando a atenção está sob pressão.

Nas próximas duas horas que eu não perder no arquivo errado, esse texto pagou o próprio tempo.

---

ken imoto · WebRTC & Voice AI engineer · kenimoto.dev · TabNews