Un nuevo estudio concluye que los asistentes de programación más usados no pueden predecir cuánto demorará una tarea, y tampoco logran decir con precisión cuánto tiempo llevan trabajando en ella. Es un problema para los trabajos de larga duración.

Cuando un asistente de IA trabaja en una tarea, a menudo no tiene idea de cuánto tiempo está pasando. Esa es la conclusión de un estudio realizado por dos investigadores independientes en IA, hecho como parte del programa de investigación MATS. La dupla puso a prueba a dos asistentes de programación ampliamente usados, Claude Code de Anthropic y Codex de OpenAI, en su sentido del tiempo.

¿Cuánto se equivocan al estimar la duración?

Antes de cada tarea de programación, los agentes debían estimar cuánto tiempo necesitarían. Luego resolvían la tarea y, mirando hacia atrás, informaban cuánto tiempo había transcurrido. El material de prueba salió de 200 tareas de una colección llamada ProgramBench, más una suite propia de 18 pruebas de referencia elaborada por los investigadores.

En los ensayos, los agentes sobreestimaron de manera consistente el tiempo que iban a necesitar. En ProgramBench, ambos modelos respondieron casi siempre alrededor de 90 minutos, sin importar la dificultad. En la segunda ronda, Claude se equivocó por un factor de tres en promedio y Codex por un factor de entre seis y diez. Las estimaciones fueron peores en las tareas cortas, y solo en el rango de varias horas algunas predicciones se acercaron a la realidad.

Según los datos publicados, Fable 5 quedó unas tres veces por sobre el tiempo de ejecución real en promedio, y GPT-5.6 Sol unas siete veces por sobre. La brecha es especialmente ancha en las tareas breves.

El mismo modelo se comporta distinto según su entorno

Los resultados cambian según la configuración de software en la que corren los modelos. Claude Code sigue trabajando hasta que cree que la tarea está lista, con una mediana cercana a los 90 minutos. Codex, en cambio, se detiene tras unos 30 minutos, casi con independencia de la tarea.

De acuerdo con el estudio, el mismo modelo de lenguaje da 2,5 veces más pasos dentro de Claude Code que dentro de Codex, en promedio. Es decir, el tiempo de ejecución depende del modelo, pero mucho más del software que lo rodea, lo que en la jerga se llama el arnés.

¿Saben evaluar su propio trabajo?

Los agentes resultan igual de poco confiables al juzgar la calidad de lo que produjeron. Los modelos más antiguos, Opus 4.8 y GPT-5.5, sobrevaloraron sus resultados en 20 puntos en promedio y se pusieron notas altas incluso en tareas fallidas.

En un caso puntual, ambos calcularon que su trabajo había sido exitoso en torno al 70 por ciento. Los puntajes reales fueron de 7 y 14,5 por ciento.

Claude y Codex se califican a sí mismos con demasiada generosidad. En promedio, ambos sistemas se puntúan unos 20 puntos porcentuales por encima de los resultados que efectivamente alcanzan en las pruebas.

Por qué esto complica la supervisión

Los investigadores sostienen que esta capacidad de autoevaluación importa. Para que un agente trabaje de forma confiable en tareas largas, que se extienden por horas, tiene que poder seguir instrucciones del tipo "itera sobre esta tarea durante dos horas". Un agente que se equivoca constantemente sobre el tiempo es difícil de controlar.

Como paso siguiente, los autores quieren probar si los agentes pueden ajustarse a una duración de trabajo fijada de antemano.

Hay un hallazgo que apunta a la solución más simple: cuando los agentes recibieron acceso a una herramienta que informa el tiempo transcurrido, acertaron casi siempre.

¿Qué se puede hacer hoy con esto?

La brecha entre los dos comportamientos observados es el dato accionable. Si el mismo modelo da 2,5 veces más pasos en un entorno que en otro, y si uno se detiene a los 30 minutos y el otro a los 90, entonces la elección de herramienta pesa más que la elección de modelo cuando lo que importa es cuánto va a durar el trabajo y cuánto va a costar.

Y la corrección resulta barata: exponerle al agente un reloj. Que el error casi desaparezca al entregar una herramienta que reporta el tiempo transcurrido sugiere que no se trata de una limitación profunda del razonamiento, sino de la falta de un sensor. Es la misma lección que la robótica aprendió hace décadas, cuando dejó de estimar la posición contando vueltas de rueda y empezó a medirla.