Una sola frase del tech lead en el prompt alteró un 20% las estimaciones de tareas de ChatGPT y Claude

Antes de la planificación, alguien pega el backlog en un chat y pide una estimación en story points. En diez segundos, el modelo devuelve una pulcra columna de cifras. Pero en el prompt aparece de pasada: «el tech lead cree que esto ronda los 32 puntos». Sergey Proshchaev, Tech Lead en FinTech y comercio electrónico, comprobó qué ocurre con la estimación en ese caso.

Cómo se diseñó el experimento

Seleccionó 12 tareas del proyecto Spring XD de un dataset público con 23.313 incidencias de Jira: dos tareas para cada estimación de 1, 2, 3, 5, 8 y 13. El equipo las había estimado en un total de 64 SP. Los dos prompts se diferenciaban en una sola frase: en el segundo, el tech lead supuestamente había calculado 32 SP, exactamente la mitad. Los modelos fueron la versión gratuita de ChatGPT y Claude Opus 5.5. Cada prompt se ejecutó tres veces en un chat nuevo, con 12 ejecuciones en total.

El resultado: el total medio de ChatGPT bajó de 76,7 a 60,3 SP (−21%) y el de Claude, de 66,7 a 54,0 (−19%). Ningún modelo llegó a 32; la ejecución más baja dio 44. Es el clásico efecto de anclaje que Jorgensen ya describió en personas en 2010: las estimaciones se alejan de la pista, pero no lo suficiente. Los intervalos con y sin ancla no se solapan.

Qué se rompe exactamente

Las tareas pequeñas apenas cambiaron: la actualización de Groovy recibió un 1 en las doce ejecuciones. Las grandes bajaron de forma apreciable. Una tarea que el equipo había estimado en 13 pasó a 8 en las tres ejecuciones de ChatGPT con ancla. Los metadatos valorados en 8 se convirtieron en 5.

Surgió otro problema: con el ancla, los modelos se volvieron menos consistentes. Sin ella, la estimación varió entre ejecuciones en tres de las doce tareas para ChatGPT y en dos para Claude. Con el ancla, las cifras aumentaron a siete y cuatro, respectivamente.

El hallazgo más engañoso: con el ancla, el total de ChatGPT se acercó al del equipo (60,3 frente a 64), pero el error medio por tarea aumentó de 2,92 a 3,25 SP. Con Claude ocurrió lo contrario: el total se alejó, mientras que el error por tarea bajó de 1,75 a 1,42. El total compensa errores de distinto signo y oculta hacia dónde se desplazó la estimación.

Qué hacer en la práctica

El autor propone cinco reglas:

• No incluir en el prompt la capacidad del sprint, las expectativas del tech lead ni estimaciones de tareas similares.
• Mostrar la estimación del modelo solo después de que el equipo haya votado.
• Ejecutar el modelo al menos tres veces y observar la dispersión.
• Comparar el modelo con el equipo tarea por tarea y por posición, no por el total.
• Considerar una diferencia de dos o más posiciones en la escala como motivo para revisar la descripción de la tarea.

Los modelos funcionan mejor como detectores de tareas poco claras que como fuentes de una cifra. Por ejemplo, el equipo estimó en 8 el «procesador R», mientras que ChatGPT sin ancla le asignó 21 por la palabra «investigar» en la descripción. Conviene analizar estas discrepancias: quizá el equipo tenga contexto que no aparece en el texto.

Limitaciones

La muestra es pequeña: 12 tareas, un proyecto, dos modelos y tres ejecuciones por modelo. El dataset es público desde 2016 y podría haber formado parte de los datos de entrenamiento. La frase contiene tanto una cifra como la opinión del tech lead, y no se separó el efecto de cada elemento. No es un benchmark, sino la prueba de una práctica de trabajo concreta.

Puede comprobarse en 20 minutos: tome unas diez tareas completadas, ejecute cada una tres veces sin cifras y otras tres incluyendo la capacidad del sprint, y compare tanto los totales como las tareas individuales. Si las variantes difieren más entre sí que las repeticiones de una misma variante, la cifra del prompt está influyendo en el modelo y conviene mantenerla lejos de la estimación inicial. El autor publicó el código y las respuestas de los modelos en un repositorio abierto.