3 sesgos que rompen tus estimaciones cuando la IA dice "lo hago en 10 minutos"

La semana pasada le pedí a Claude Code que agregara un endpoint nuevo. Un endpoint chico, lectura simple de la base, respuesta JSON. Le pregunté cuánto le tomaría. Me contestó “unos 10 minutos”.

Cuatro horas después seguía debuggeando por qué la respuesta llegaba vacía en un caso específico.

No es que el modelo mintió. Es que yo compré la estimación sin filtrar. Y ese acto de compra tiene tres sesgos cognitivos bien identificados detrás, todos conocidos desde antes de que existiera la IA generativa. La diferencia es que ahora los tres se disparan al mismo tiempo, y con más fuerza, porque el modelo suena seguro.

Este artículo es sobre esos tres sesgos, con ejemplos concretos y una manera práctica de medirlos en tu próximo sprint. No es sobre “no confíes en la IA”. Es sobre entender por qué la trampa se activa aunque uno se crea inmune.

Sesgo 1: Anclaje en la primera cifra del modelo

Este es el que hace que las estimaciones grupales se compriman.

Anclaje es lo que estudió Kahneman en su libro más conocido. Cuando escuchas un número primero (aunque sea arbitrario), tus decisiones posteriores se comprimen alrededor de ese número.

En una reunión de planning, si el primer estimador dice “3 días”, todo el resto se compacta en el rango de 2 a 4 días. Incluso quien pensaba “esto es una semana” ajusta hacia abajo, casi sin darse cuenta.

Con la IA en la mesa, el modelo ahora es el que habla primero. Y su estimación entra a la reunión con un peso implícito de “sistema neutral, sin ego, ya lo pensó”. El primer número del modelo se convierte en el ancla de todo el equipo.

Un caso concreto: en un planning de sprint, el modelo dijo “esta feature son 3 puntos”. Tres personas del equipo estaban entre 5 y 8 puntos antes de la reunión. Ninguno terminó votando arriba de 5. La feature llevó 8. La comparamos después con otras features que habíamos votado sin escuchar al modelo primero: nuestro margen de error grupal era de ±30%. Con el ancla del modelo, el margen colapsó a -20% (siempre por debajo de lo real).

Cómo cortarlo en tu equipo: cambiar el orden. Cada persona escribe su estimación en privado (Planning Poker sirve, pero también una nota en Slack), y después se muestra la del modelo como una tercera opinión, no como el punto de partida. El modelo sigue siendo útil como una voz más, pero deja de ser el ancla.

Sesgo 2: Falacia de planificación amplificada por la confianza del modelo

La falacia de planificación la nombraron Kahneman y Tversky en 1979. La idea es simple: cuando estimamos cuánto tarda una tarea, sistemáticamente subestimamos. No porque seamos torpes. Porque el cerebro planifica sobre el escenario donde todo sale bien.

Antes de la IA, ya éramos malos con esto. Estudios sobre planificación de proyectos (desde el clásico de Buehler, Griffin y Ross en 1994) mostraron que incluso pidiéndole a la gente que dijera “el peor caso realista”, cerca de la mitad de los participantes terminaba tardando más que su propia predicción pesimista.

Ahora agreguemos IA a la ecuación. Cuando Claude Code responde “unos 10 minutos”, pasan tres cosas en tu cabeza al mismo tiempo:

1. Escuchas una estimación de un sistema que se percibe como analítico y desapasionado.
2. Esa estimación reemplaza la que habrías hecho tú misma o tú mismo.
3. La sensación de “esto ya está pensado” reduce tu propia deliberación.

El resultado empírico, en mi caso: pedí que midieran conmigo un mes de tareas donde Claude Code daba una estimación inicial. De 47 tareas, la estimación del modelo se cumplió en 15. La mediana del tiempo real fue 2.3x la estimación inicial. Peor: cuando yo hacía mi propia estimación antes de preguntarle al modelo, mi estimación era, en promedio, un 40% más alta que la del modelo. Y también quedaba corta, pero menos.

La conclusión que saqué: la estimación del modelo funciona como un ancla optimista. Vale la pena verla, pero no comprarla sin descuento.

Cómo medirlo en tu sprint: anota dos estimaciones por tarea. La tuya (antes de preguntarle al modelo) y la del modelo. Al terminar la tarea, calcula el ratio tiempo_real / estimacion para las dos. Después de 20 tareas, vas a tener tu multiplicador personal. En mi caso el mío es 2.3x para las del modelo y 1.6x para las mías. Eso me dice que multiplico ambas antes de comprometerme con alguien.

Sesgo 3: Costo hundido al iterar prompts

Este es el que menos se discute y el que más tiempo me come.

Escenario típico: el modelo generó una solución, no funciona. La corriges con un prompt. Sigue sin funcionar. Iteras de nuevo. La cuarta vez que iteras, ya invertiste 40 minutos, y estás psicológicamente en la posición de “ya casi está, un ajuste más”.

Esa posición se llama sesgo de costo hundido. Es la misma razón por la cual la gente termina de ver una película mala hasta el final “porque ya invertí una hora”. El tiempo que invertiste no vuelve por seguir invirtiendo más.

Con IA, el costo hundido es particularmente traicionero por dos razones:

• Cada iteración es barata individualmente. Un prompt nuevo son 30 segundos de tu tiempo, no 30 minutos como un experimento de código propio. Eso disfraza el total.
• La relación entre longitud del prompt y calidad del output no es lineal. Después de tres iteraciones, mi experiencia es que agregar contexto al prompt raramente mejora la respuesta. Lo que sí mejora es empezar de cero con un prompt nuevo o resolverlo a mano.

Un ejemplo concreto de mi mes pasado: le pedí a Claude Code que arreglara un test flaky en Playwright. Primer intento, no. Segundo, no. Tercero, “casi, pero rompió otros dos tests”. Cuarto, “ahora sí, pero el fix es horrible”. Total: 55 minutos. Cuando lo abordé yo directamente el día siguiente (con la cabeza fría), 12 minutos para diagnosticar y 8 para arreglar. 20 minutos. Perdí 35 minutos por no cortar antes.

La regla que uso ahora: si a la tercera iteración el resultado no funciona, cerrar la conversación y empezar de cero, o hacerlo a mano. No agregar la cuarta corrección al mismo hilo. Es un límite artificial pero rompe el costo hundido.

El efecto combinado

Los tres sesgos rara vez aparecen aislados. El caso típico es esto:

1. Le preguntas al modelo cuánto tarda una tarea (ancla: entra a tu cabeza el primer número).
2. Tu propia estimación se compacta hacia ese número (falacia de planificación: el número parece plausible porque estás pensando en el mejor caso).
3. Empiezas a trabajar. La primera implementación falla. Iteras con el modelo (costo hundido: cada iteración cuesta poco, el total se te escapa).

Al final la tarea tarda 4 horas en vez de 10 minutos. La sensación es “esto se me fue de las manos”, pero en realidad el error empezó en el minuto cero, cuando aceptaste una estimación sin descuento.

Un mecanismo simple para el próximo sprint

Después de tres meses medí conmigo mismo lo que funcionaba mejor. Terminé con un checklist de tres líneas que uso antes de comprometerme con cualquier estimación asistida por IA:

1. Escribo mi estimación en privado antes de preguntarle al modelo. Aunque sea una cifra rápida en mi cuaderno. Bloquea el anclaje.
2. Multiplico la estimación del modelo por mi factor personal (en mi caso, 2.3x; probablemente el tuyo esté entre 1.5x y 3x). Bloquea la falacia de planificación.
3. Si a la tercera iteración con el modelo no sale, cierro la conversación. Bloquea el costo hundido.

Estos tres pasos suman quizás 30 segundos por tarea. En mi caso, cortaron el sobre-esfuerzo semanal en cerca del 40% (medido durante 6 semanas). Es una intervención barata para un problema caro.

La IA generativa no inventó estos tres sesgos. Sólo los amplifica porque suena más segura que un compañero de equipo dubitativo. Saber esto no los elimina, pero al menos te devuelve la posibilidad de descontarlos antes de comprometerte.

Si quieres el contexto en inglés sobre cómo se comportan los dos agentes oficiales que hoy uso a diario, tengo un artículo previo que los compara en 47 PRs a lo largo de 31 días y desglosa dónde gana cada uno: Claude Code vs ChatGPT Codex: official agents comparison. Está en inglés porque las fuentes que cito ahí no tienen traducción disponible.

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