Claude Code estima uma tarefa em dois dias. Termina em duas horas. Às vezes em vinte minutos. Isso acontece com frequência suficiente para não ser ruído — é sintoma de que a unidade que usamos para planejar trabalho parou de medir o que precisa medir.
Por que story point foi desenhado para outra coisa
Story point nunca foi estimativa de tempo — Mike Cohn, que popularizou a técnica, sempre insistiu nisso. É estimativa relativa de esforço e incerteza humana. Cinco pontos não significa "cinco horas", significa "mais complexo e mais incerto que uma tarefa de três pontos, na percepção de quem vai executar".
O problema é estrutural, não de calibração: quando um agente de IA executa a tarefa, a correlação entre complexidade percebida e esforço de execução achata. Adicionar um endpoint simples e fazer uma mudança de arquitetura que atravessa vários serviços podem gerar perfil de esforço humano completamente diferente — mas, para o agente, o tempo de execução fica muito mais parecido entre os dois casos. A régua que discriminava bem tarefa fácil de tarefa difícil, quando o esforço era humano, para de discriminar quando quem executa é outra coisa.
O que já está sendo proposto — sem consenso ainda
Vale deixar claro: isso é debate aberto de 2026, não framework assentado. Encontrei pelo menos quatro propostas concorrentes, cada uma atacando um ângulo diferente do mesmo problema.
Planejar por objetivo de negócio, não por user story. A tese mais radical argumenta que, se um agente decompõe a feature em tarefas entregáveis sozinho, debater se uma história vale cinco ou oito pontos não agrega nada — a unidade de planejamento devia subir de nível, para o objetivo que a feature entrega, não a tarefa técnica que a compõe.
Tamanho pelo esforço de revisão, não de geração. Essa é a que mais conversa com o que já escrevemos [sobre revisão de código em escala](/lab/revisao-codigo-ia-generativa-escala): se gerar ficou barato e replicável, o gargalo real é quanto trabalho humano a mudança exige para ser revisada com segurança. Inverter o critério — tamanho da tarefa = dificuldade de verificar, não de construir — parece pequeno ajuste, mas muda completamente o que "grande" e "pequeno" significam num board.
Marcar novidade, não só tamanho. Tarefa que repete padrão já visto custa, segundo essa proposta, de duas a três vezes menos que tarefa genuinamente nova — porque IA generativa é boa em replicar padrão e fraca em julgamento sobre o inédito. Rastrear novidade separadamente da complexidade captura um tipo de risco que story point tradicional nunca isolou.
Confiança em vez de magnitude. Em vez de perguntar "quantos pontos", perguntar "qual sua confiança nessa estimativa" — para trabalho de IA, o nível de certeza sobre o que vai acontecer importa mais que o tamanho do número.
Existe até quem tenha proposto rebatizar a unidade inteira de "prompt points" — vale registrar que isso soa mais rebranding que mudança de substância, e citamos aqui só para deixar claro que nem toda proposta desse momento tem peso igual.
O caso mais concreto que encontrei: transformar planejamento em auditoria
A implementação mais madura e mais bem documentada até agora vem de um time que usa Claude com acesso ao próprio repositório durante o refinamento. Em vez de o time debater ponto, o agente faz um dry-run de cada história: rascunha um esboço de implementação contra o código real, mapeia os arquivos que a mudança provavelmente toca, pesa a carga de revisão esperada pela criticidade dessas áreas, verifica quais testes já cobrem o caminho e quais precisariam ser escritos, e identifica quem precisaria aprovar a mudança.
Se sobra pergunta que o agente não consegue resolver sozinho a partir da história ou do código, isso volta direto como sinal de que a tarefa não está pronta — no vocabulário que já usamos [no nosso guia de DoR](/lab/depois-do-scrum-cerimonia-agil-ia), uma história que a IA não consegue nem começar a mapear não está pronta, ponto.
No fim, o agente sugere um tamanho com uma linha de justificativa — algo como "M: dois serviços, diff moderado, testes de integração já cobrem o caminho principal". Quando ninguém discorda, a sugestão vale e a reunião nem precisa debater. Quando alguém discorda, geralmente é porque tem contexto que o agente não podia ver — um módulo politicamente sensível, uma mudança de posição do stakeholder que ainda não chegou ao código. Planejamento deixa de ser sessão de estimativa e vira sessão de auditoria — só se discute o que realmente exige julgamento humano.
Isso é, no fundo, o mesmo conceito de sensor que já usamos [no post sobre agent harness](/lab/o-que-e-agent-harness) aplicado a uma camada nova: sensor computacional mapeando blast radius e cobertura de teste, sensor inferencial sugerindo o tamanho — e humano só entra quando o sensor não resolve sozinho.
O limite que não pode ficar de fora
Vale uma dose de realismo, para não vender isso como resolvido. O próprio relatório de tendência de codificação agêntica da Anthropic para 2026 registra que desenvolvedores usam IA para cerca de 60% do próprio trabalho, mas só conseguem delegar de fato, sem supervisão, entre 0% e 20% das tarefas. Isso significa que qualquer sistema de estimativa baseado em dry-run de agente ainda depende de validação humana ativa — o agente sugere e mapeia, mas a confiança cega na sugestão erra na mesma proporção que a delegação sem supervisão erra hoje.
O que fazer com isso agora, sem esperar consenso
Nenhuma das propostas acima é padrão estabelecido — é terreno em movimento. Três ajustes práticos, que não dependem de esperar o mercado convergir:
* Pare de tentar calibrar Fibonacci para tempo de agente. Se a régua para de discriminar fácil de difícil, ajustar o número não resolve — o problema é a régua, não a calibração.
* Comece a nomear novidade separadamente de tamanho, mesmo informalmente. "Já fizemos isso antes" versus "ninguém do time nunca fez isso" é sinal mais forte de risco do que o tamanho da mudança em si.
* Se seu time usa agente com acesso a repositório, teste o dry-run antes de aprofundar em novo framework de pontuação. É a proposta com mais evidência prática por trás, e generaliza melhor que as outras três.
Story point não estava errado quando foi criado — estava certo para um mundo onde quem escrevia o código era sempre humano. Esse mundo já não é o único que existe, e a régua que usamos para planejar precisa admitir isso antes de fingir que só precisa de mais calibração.