3 vieses cognitivos que estragam sua estimativa de sprint — e como o Claude Code corta 2 deles

Planning fallacy, anchoring e sunk-cost custaram 41 horas de overrun em 47 estimativas que rastreei nos últimos 3 meses. Não são falhas de senioridade nem de stack. São vieses cognitivos que o cérebro humano executa por padrão toda vez que alguém pergunta “quanto tempo leva essa feature?”.

Só que com o Claude Code eu consegui cortar 2 desses 3. O terceiro continua humano puro, e nenhum LLM vai resolver isso por você. Este texto é sobre onde a IA ajuda de verdade e onde ela vira placebo.

O dataset: 47 estimativas, 3 meses, 41h de overrun

Comecei a rastrear em abril. Cada ticket que peguei, anotei estimativa inicial + tempo real gasto. Sem julgar, sem consertar no meio. Só medir.

• 47 tickets entre 2026-04 e 2026-07
• Estimativa mediana: 4 horas por ticket
• Tempo real mediano: 5,25 horas por ticket
• Overrun total: +41 horas em 3 meses (~14h por mês)
• Taxa de ticket dentro da estimativa: apenas 34 % (16 de 47)

Com o custo hora médio de dev sênior no Brasil (R$ 180-250/h em consultoria), 41h viram R$ 7.400-10.250 de horas não faturáveis em um trimestre. Para um dev solo isso é uma passagem para o Chile.

A distribuição dos 41h por causa é o que interessa:

Viés	Horas perdidas	% do overrun
Planning fallacy (cenário otimista)	22h	54 %
Anchoring (âncora do PM ou de ticket anterior)	12h	29 %
Sunk-cost (insistir em abordagem errada)	7h	17 %

Isso bate com o padrão que Magne Jørgensen documenta há duas décadas em estimativa de software: o erro é sistemático e enviesado para baixo, não simétrico. Estimativa mediana abaixo do tempo real, com cauda longa à direita.

Viés 1: Planning fallacy — Claude corta com dados históricos

Kahneman e Tversky batizaram planning fallacy em 1979. É a tendência de estimar a partir do “cenário em que tudo dá certo”: sem retrabalho de PR, sem falha de CI, sem mudança de requisito, sem interrupção. Cada um desses eventos tem probabilidade baixa individualmente, mas pelo menos um acontece com probabilidade alta.

O que faz o cérebro repetir o erro mesmo depois de 47 tickets é que planning fallacy tem imunidade à experiência. “Desta vez é diferente, eu estimei direito” — esse sentimento faz parte do próprio viés.

Como o Claude corta

A contramedida clássica é Reference Class Forecasting (RCF): em vez de estimar pelos detalhes da tarefa atual, consultar dados reais de tarefas similares do passado. Isso é chato de fazer manualmente. O Claude Code faz de graça se você jogar o histórico nele.

Meu prompt padrão hoje:

Anexo em CSV os últimos 30 tickets do meu projeto com:
{título, tags, estimativa inicial em horas, tempo real em horas}.

Nova tarefa: "Adicionar rate limiter no endpoint /login com Redis (window 60s)".

Faça o seguinte:
1. Identifique os 5 tickets historicamente mais parecidos com a nova tarefa
2. Calcule mediana e p75 do tempo real desses 5 tickets
3. Retorne "estimativa RCF: mediana Xh (p75 Yh)" — sem inflar, sem descontar

O Claude retorna algo como “estimativa RCF: mediana 6h (p75 9h)” enquanto meu chute inicial era 3h. A partir da segunda semana usando isso, o overrun por planning fallacy caiu de 22h para 4h no trimestre atual. Corte de ~82 % nessa causa isolada.

O que a IA faz aqui é obrigar meu cérebro a olhar dados que eu tinha, mas evitava consultar. RCF sempre funcionou; faltava um jeito barato de rodar.

Viés 2: Anchoring — Claude corta com estimativa às cegas

No sprint planning, a primeira estimativa vira âncora. Alguém joga “essa aí, uns 3 dias?” e o restante do time converge para 3 dias. Quem estimaria uma semana ajusta sem perceber: “tanto assim não, uns 5 dias talvez”.

O planning poker existe por isso mesmo. O valor está na revelação simultânea de cartas, que impede a âncora da primeira pessoa de puxar as demais. A mediana do time em si nem prevê melhor. Se alguém no time diz “deixa eu ver primeiro” ou “vamos ouvir o senior antes”, o efeito anti-ancoragem some.

Como o Claude corta

Uso o Claude como “primeira carta às cegas”. Antes de qualquer conversa com o PM ou com o time sobre estimativa, mando o ticket para o Claude sem contexto de expectativa:

Aqui está a descrição do ticket. NÃO leia nenhuma
expectativa de prazo, nenhum comentário sobre "seria bom
entregar até". Só leia o escopo técnico e as dependências
listadas.

Estime em horas com base em RCF (histórico anexo).
Retorne apenas o número — nada de justificar,
nada de perguntar "o cliente precisa quando?".

A resposta do Claude vira minha carta às cegas. Depois disso, na conversa com PM ou time, eu já entro com um número calibrado que não passou pela âncora do “dá para 2 semanas, né?”. O overrun por anchoring caiu de 12h para 3h no trimestre. Corte de ~75 %.

Isso funciona porque LLM não sente pressão social. Você sente. O Claude não vai encolher a estimativa porque o PM levantou a sobrancelha na reunião.

Viés 3: Sunk-cost — humano puro, Claude não resolve

Sunk-cost é o viés que te faz continuar em uma abordagem errada porque você já investiu 6 horas nela. “Se eu parar agora, joguei fora meia manhã. Mais 1 hora e resolvo.” Aí vira mais 1, mais 1, mais 1.

Rastreei 7 horas do meu overrun trimestral vindas de sunk-cost puro. Um caso emblemático: fiquei 4 horas tentando resolver com debounce de UI um problema que era de state management. Cada meia hora eu pensava “está quase”. Não estava.

Por que o Claude não corta

Tentei. Coloquei o Claude para me lembrar de reavaliar a cada 30 minutos: “você está há X horas nisso. A abordagem inicial era Y. Considere parar e refazer o design.” Funcionou nos 2 primeiros dias e depois eu comecei a ignorar a resposta do Claude com a mesma facilidade que ignoro o timer do Pomodoro.

O problema é que sunk-cost não é falha de informação. É apego emocional ao trabalho já feito. Nenhum prompt resolve isso, porque quem precisa reagir é você — e o mesmo cérebro que caiu no viés é o que decide se ouve ou não o alerta.

O único remédio que funcionou pra mim: combinar antes com outra pessoa que se eu estivesse 2× o prazo em uma tarefa, ela viria me perguntar “posso ver o que você está tentando?”. Isso corta sunk-cost porque adiciona uma voz externa que não tem apego emocional ao meu código. Compromisso com um par, não LLM.

Sobre esse ponto, escrevi antes em Confiei na IA para ir mais rápido — e fiquei mais lento, onde o mesmo padrão apareceu: a IA acelera onde falta informação; onde falta vontade, ela não muda nada.

O que ficou depois de 3 meses

O saldo do trimestre atual (comparando com o anterior, mesma metodologia):

Viés	Overrun antes	Overrun depois	Redução
Planning fallacy	22h	4h	-82 %
Anchoring	12h	3h	-75 %
Sunk-cost	7h	6h	-14 % (ruído)
Total	41h	13h	-68 %

28 horas recuperadas em um trimestre só por delegar RCF e estimativa às cegas para o Claude. O ganho todo veio de estimar melhor e parar de me deixar ancorar. Escrever código mais rápido não entrou na conta.

E as 6 horas restantes de sunk-cost seguem lá, teimosas, à espera de algum par que me pergunte “tá batendo cabeça faz tempo?”. Isso não é problema de ferramenta. É problema de gente.

A conclusão contrarian

A conversa dominante hoje é que a IA acelera desenvolvimento porque escreve código mais rápido. Nos meus dados isso é a menor parte. O ganho grande veio de eliminar 2 vieses cognitivos sobre estimativa — algo que nenhum GitHub Copilot Metrics API vai capturar, porque não é medido em linhas de código nem em cycle time de PR (mesmo com as métricas novas da API em 2026).

Sua estimativa erra por três motivos: seu cérebro subestima sistematicamente, ancora na primeira voz que fala e não solta abordagens já investidas. Dois desses três ficaram delegáveis. O terceiro ainda precisa de você — ou de alguém do seu lado.

---

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