Uma única frase do tech lead no prompt alterou em 20% as estimativas de tarefas do ChatGPT e do Claude

Antes do planejamento, alguém cola o backlog em um chat e pede uma estimativa em story points. Em dez segundos, o modelo devolve uma coluna organizada de números. Só que o prompt menciona de passagem: “o tech lead acha que isso dá algo em torno de 32 pontos”. Sergey Proshchaev, Tech Lead em FinTech e e-commerce, verificou o que acontece com a estimativa nesse cenário.

Como o experimento foi estruturado

Ele selecionou 12 tarefas do projeto Spring XD em um dataset aberto com 23.313 issues do Jira, duas para cada estimativa: 1, 2, 3, 5, 8 e 13. A equipe havia estimado um total de 64 SP. Os dois prompts diferiam em uma única frase: no segundo, o tech lead supostamente havia calculado 32 SP, exatamente a metade. Os modelos usados foram a versão gratuita do ChatGPT e o Claude Opus 5.5. Cada prompt foi executado três vezes em um chat novo, totalizando 12 execuções.

O resultado: a soma média do ChatGPT caiu de 76,7 para 60,3 SP (−21%), enquanto a do Claude passou de 66,7 para 54,0 (−19%). Nenhum dos modelos chegou a 32; a execução mais baixa produziu 44. Esse é o clássico efeito de ancoragem que Jorgensen já havia descrito em pessoas em 2010: as estimativas se afastam da sugestão, mas não o suficiente. Os intervalos com e sem a âncora não se sobrepõem.

O que exatamente deixa de funcionar

As tarefas pequenas quase não mudaram: a atualização do Groovy recebeu 1 em todas as 12 execuções. As grandes caíram de forma perceptível. Uma tarefa que a equipe havia estimado em 13 passou a 8 nas três execuções do ChatGPT com âncora. Os metadados avaliados em 8 viraram 5.

Surgiu outro problema: com a âncora, os modelos ficaram menos consistentes. Sem ela, a estimativa variou entre execuções em três das 12 tarefas no ChatGPT e em duas no Claude. Com a âncora, esses números subiram para sete e quatro, respectivamente.

O resultado mais traiçoeiro: com a âncora, o total do ChatGPT se aproximou do valor da equipe (60,3 contra 64), mas o erro médio por tarefa aumentou de 2,92 para 3,25 SP. No Claude aconteceu o contrário: o total se afastou, enquanto o erro por tarefa caiu de 1,75 para 1,42. A soma compensa erros em direções opostas e esconde para onde a estimativa se deslocou.

O que fazer na prática

O autor propõe cinco regras:

• Não incluir no prompt a capacidade da sprint, as expectativas do tech lead nem estimativas de tarefas semelhantes.
• Mostrar a estimativa do modelo somente depois da votação da equipe.
• Executar o modelo pelo menos três vezes e observar a dispersão.
• Comparar o modelo com a equipe tarefa por tarefa e por posição no ranking, não pelo total.
• Tratar uma divergência de duas ou mais posições na escala como motivo para revisar a descrição da tarefa.

Os modelos funcionam melhor como detectores de tarefas pouco claras do que como fontes de um número. Por exemplo, a equipe estimou o “processador R” em 8, enquanto o ChatGPT sem âncora atribuiu 21 por causa da palavra “pesquisar” na descrição. Vale a pena investigar essas divergências: talvez a equipe tenha um contexto que não aparece no texto.

Limitações

A amostra é pequena: 12 tarefas, um projeto, dois modelos e três execuções de cada. O dataset é público desde 2016 e pode ter entrado nos dados de treinamento. A frase contém tanto um número quanto a opinião do tech lead, e as contribuições desses elementos não foram separadas. Não se trata de um benchmark, mas do teste de uma prática de trabalho específica.

É possível verificar isso em 20 minutos: pegue cerca de dez tarefas concluídas, execute cada uma três vezes sem números e outras três incluindo a capacidade da sprint, e compare não apenas os totais, mas também as tarefas individuais. Se as variantes divergirem mais entre si do que as repetições da mesma variante, o número no prompt está influenciando o modelo, e é melhor mantê-lo longe da estimativa inicial. O autor publicou o código e as respostas dos modelos em um repositório aberto.