Por que as estimativas de tempo do Claude Code são ruins — e como corrigi-las

Quem usa o Claude Code (ou outro agente de código) para tarefas do dia a dia já passou por isso: você pergunta “quanto tempo leva para implementar essa feature?” e recebe uma resposta como “para um único engenheiro, de 3 a 4 semanas de trabalho” — quando, na prática, com uma especificação clara e o Claude bem configurado, a tarefa sai em um único dia. O problema não é falta de informação; é que o modelo está te dando estimativas de humano, não de LLM.

Por que as estimativas são ruins

A explicação central, segundo o engenheiro Eivind Kjosbakken, está nos dados de treinamento. O Claude foi treinado com texto produzido por humanos, incluindo posts de blog sobre quanto tempo uma implementação levou e estatísticas do GitHub da época em que só humanos escreviam código — essencialmente antes de 2022. Assim, o modelo aprendeu estimativas humanas: uma feature que leva 4 semanas para um humano, ou uma correção de bug que leva 2 dias.

O resultado é um descompasso: quando você pede uma estimativa, o modelo responde com base no tempo que uma pessoa levaria — não no tempo que um LLM dirigindo o trabalho levaria. A boa notícia é que, com alguns anos de dados de programação assistida por IA circulando na internet, essas estimativas tendem a se recalibrar naturalmente — mas vão ficar defasadas por um bom tempo.

Por que estimativas precisas importam

Boas estimativas são a base da comunicação com o time: para dizer ao gerente de produto quando algo fica pronto, ou para avisar um colega cujo trabalho depende do seu. Sem isso, o planejamento vira chute — e o pior não é o número errado, é a falsa confiança num prazo que não se sustenta.

Técnica 1: baseie as estimativas nos seus próprios dados

A técnica mais eficaz é fazer o agente registrar quanto tempo cada tarefa realmente leva. Cada tarefa pode ser rastreada numa issue do Linear ou num arquivo de Markdown no Notion. Ao concluir, anote quando começou e quando terminou. Depois de acumular várias features e correções, crie uma skill do Claude Code com esse histórico, algo como:

1. Feature A <descrição> - 12 horas
2. Feature B <descrição> - 3 horas
3. Resolver bug B <descrição e como foi corrigido> - 4 horas

Toda vez que o agente precisar estimar, ele consulta essa skill, compara a tarefa atual com as anteriores e produz uma estimativa muito melhor. Claro, nunca será 100% precisa — não há informação perfeita sobre os desafios que vão surgir no caminho, e sempre pode haver trabalho paralelo para rebasear. Mas o autor afirma que essa prática é a forma mais eficaz de alinhar a comunicação com o time.

Técnica 2: quebre em subtarefas e peça estimativas de LLM

Se você ainda não tem histórico de dados, use a segunda técnica: dividir a tarefa em passos menores e pedir explicitamente que o modelo estime com base no tempo de um LLM, não de um humano. Por exemplo, ao implementar a feature A, divida em: pesquisar o tema, implementar a parte 1, implementar a parte 2 e testar. Quanto mais específicos os passos, melhor — estimar tarefas pequenas é muito mais fácil, tanto para humanos quanto para LLMs.

Peça ao modelo uma estimativa para cada subtarefa considerando que um LLM (ou um humano dirigindo LLMs) fará o trabalho. O modelo tem conhecimento inerente da própria eficácia — pesquisar um tema, por exemplo, é muito mais rápido com LLM do que manualmente no Google. Depois, some as estimativas e você terá o tempo total.

Por que isso importa agora

À medida que os LLMs mudam a forma como trabalhamos, saber comunicar e alinhar humanos com LLMs vira uma habilidade crítica. Quem depende de agentes de código para entregar no prazo precisa entender que a estimativa padrão desses agentes está calibrada para um mundo pré-IA — e que a correção vem de dados próprios e prompts específicos, não de fé no modelo.