Los agentes de codificación con IA tienen problemas para seguir el tiempo, según un estudio
Pruebas de Claude Code y Codex encontraron errores importantes en las estimaciones de tiempo y en la autoevaluación, lo que plantea preocupaciones de supervisión para tareas de codificación de IA de larga duración.
Claude Code de Anthropic y Codex de OpenAI pueden completar tareas de software, pero un nuevo estudio sugiere que tienen una comprensión débil de cuánto tardan esas tareas, y una capacidad aún menor para juzgar su propio rendimiento. El hallazgo importa a medida que los agentes de codificación con IA pasan de indicaciones interactivas breves a trabajos que se ejecutan de forma autónoma durante decenas de minutos u horas.
Dos investigadores independientes que trabajaban en el programa de investigación MATS probaron los asistentes en 200 tareas de ProgramBench y 18 benchmarks adicionales, según el relato de The Decoder sobre el estudio. Se pidió a los agentes que estimaran la duración necesaria antes de empezar y luego que informaran cuánto tiempo había transcurrido después de completar el trabajo. Ambos sistemas sobreestimaron sistemáticamente la duración de las tareas y, además, se otorgaron calificaciones mucho más altas a trabajos fallidos de lo que justificaban los resultados de la prueba.
El estudio no demuestra que los modelos carezcan literalmente de acceso al tiempo en todos los entornos de software. En cambio, destaca una debilidad práctica en la forma en que los actuales agentes de IA perciben el tiempo transcurrido y usan esa información para gestionar el trabajo. Cuando los investigadores suministraron una herramienta que informaba del tiempo transcurrido, los agentes aparentemente se volvieron precisos casi siempre.
Grandes errores en tareas de codificación cortas
En ProgramBench, ambos agentes generalmente predijeron que las tareas tardarían unos 90 minutos, independientemente de la dificultad, informó The Decoder. En un segundo conjunto de pruebas, las estimaciones de Claude Code se desviaron en promedio en unas tres veces, mientras que las de Codex se desviaron entre seis y diez veces.
Los errores más grandes aparecieron en tareas cortas. Según el informe, las predicciones se acercaron a la realidad solo cuando el trabajo se extendía a rangos de varias horas. Ese patrón es importante operativamente: un agente que predice 90 minutos para una tarea que podría terminar en pocos minutos puede tomar malas decisiones sobre cuándo detenerse, pedir ayuda o iniciar otra acción.
Los resultados también variaron considerablemente según el entorno de software alrededor de cada modelo. Claude Code siguió trabajando hasta que juzgó que la tarea estaba completa, con una mediana de ejecución reportada de unos 90 minutos. Codex se detuvo después de aproximadamente media hora en muchos casos, incluso cuando cambiaba la dificultad de la tarea.
Los investigadores atribuyeron parte de la diferencia al “harness” del agente: las herramientas, instrucciones, límites de ejecución y lógica de control que rodean al modelo de lenguaje. Según los informes, el mismo modelo subyacente dio 2,5 veces más pasos en Claude Code que en Codex, en promedio. Eso sugiere que el tiempo de ejecución no es simplemente una propiedad del modelo; también está moldeado por la arquitectura del producto que lo despliega.
La autoevaluación fue otro punto débil
Las pruebas encontraron problemas más allá de las estimaciones de duración. Según The Decoder, los modelos sobreestimaron la calidad de su propio trabajo en unos 20 puntos porcentuales de media. A veces se dieron puntuaciones altas incluso cuando la tarea había fracasado en gran medida.
En un ejemplo, ambos sistemas aparentemente evaluaron su trabajo con alrededor de un 70 % de éxito, mientras que los resultados medidos fueron del 7 % y del 14,5 %. La fuente describe los modelos implicados como Opus 4.8 y GPT-5.5. Dado que la evidencia disponible aquí es un informe sobre el estudio y no el artículo completo ni los datos en bruto, esos identificadores de modelo y las condiciones exactas de evaluación deben considerarse hallazgos reportados y no hechos verificados de forma independiente.
La autoevaluación es central para el trabajo autónomo de software. Un agente de codificación puede tener que decidir si sigue iterando, declara una tarea terminada, revisa un parche o escala un problema a una persona. Si su confianza está desconectada de los resultados de las pruebas, un flujo de trabajo puede parecer saludable mientras produce código incompleto o defectuoso.
Por qué el harness importa para el despliegue
Para los desarrolladores, la lección central no es solo que Claude Code y Codex hagan malas predicciones. Es que el comportamiento del agente depende en gran medida de los controles alrededor del modelo. Un equipo de producto que elija un asistente de codificación con IA debería evaluar no solo el rendimiento en benchmarks, sino también cómo el sistema maneja plazos, reintentos, fallos de herramientas, retroalimentación de pruebas y condiciones explícitas de detención.
El resultado reportado del estudio con una herramienta de tiempo transcurrido ofrece una respuesta de ingeniería relativamente sencilla. No se debería esperar que un agente infiera el tiempo a partir del historial de conversación, la generación de tokens o el número de llamadas a herramientas. El tiempo de ejecución debería ser proporcionado por un reloj externo fiable y aplicado por la capa de orquestación.
Eso no resuelve todos los problemas de supervisión. Un temporizador puede decirle a un agente que han pasado dos horas, pero no puede determinar si el código resultante es seguro, completo o digno de desplegarse. Los equipos aún pueden necesitar pruebas independientes, revisiones de cambios, aislamiento, límites de gasto y reglas de escalado. Esos controles se vuelven más importantes cuando se permite a un agente trabajar sin supervisión continua.
El hallazgo también complica las comparaciones entre productos de codificación con IA. El menor tiempo de ejecución observado de Codex y la secuencia más larga de pasos de Claude Code pueden reflejar distintos valores predeterminados más que una simple diferencia en inteligencia o productividad. Los compradores que comparan productos deberían preguntar qué se le permite hacer al agente, cuánto tiempo puede ejecutar y cómo se verifica la finalización.
Evidencia y límites de la afirmación
La evidencia proviene de un estudio de dos investigadores independientes realizado como parte de MATS, según informó The Decoder. El conjunto de pruebas reportado combinó ProgramBench con una suite adicional de 18 tareas de benchmark. El relato proporciona resultados numéricos sobre estimación de tiempo, tiempo de ejecución, número de pasos y autoevaluación, pero el material disponible aquí no incluye la metodología completa, las definiciones de las tareas, el análisis estadístico ni una replicación independiente.
En consecuencia, los hallazgos deben leerse como evidencia de una debilidad de evaluación específica, no como una medición universal de todas las versiones de todos los agentes de IA. Los resultados pueden cambiar con las actualizaciones del modelo, los prompts del sistema, las herramientas disponibles, las ventanas de contexto, los tipos de tareas y el diseño del harness. La afirmación de que el acceso a una herramienta de tiempo transcurrido produjo una precisión casi universal es especialmente útil como señal de ingeniería, pero aun así procede del estudio reportado y requiere pruebas más amplias.
También existe una distinción importante entre estimar el tiempo y seguir el tiempo. Un agente puede ser capaz de leer un reloj cuando se le da la herramienta adecuada y aun así fallar al predecir cuánto tardará una tarea desconocida. Los equipos de producto deberían probar ambas capacidades por separado.
Qué vigilar a continuación
Según los informes, los investigadores planean probar si los agentes pueden seguir instrucciones como trabajar de forma continua durante una duración específica. Ese experimento podría mostrar si la información externa sobre el tiempo mejora no solo la información retrospectiva, sino también el control de tareas en tiempo real.
Las evaluaciones de seguimiento también deberían probar versiones más recientes de modelos, proyectos de software más largos, recuperación ante fallos y distintos harnesses. Un benchmark útil mediría si un agente se detiene en una fecha límite, produce un resultado utilizable antes de la fecha límite e informa con precisión de lo que queda sin terminar.
Para los compradores empresariales, las señales prácticas serán visibles en el diseño del producto: indicadores persistentes de tiempo transcurrido, presupuestos de ejecución estrictos, verificación independiente y mecanismos claros de traspaso. Los proveedores que publiquen datos reproducibles sobre estos controles facilitarán distinguir la autonomía genuina de los agentes que simplemente siguen operando hasta alcanzar un límite oculto.
Perspectiva de Creati.ai
El estudio apunta a un problema de control en el límite entre los modelos de lenguaje y el software autónomo. La conciencia del tiempo no es un rasgo humano abstracto que los productos deban imitar de algún modo; es una capacidad medible del sistema que puede ser proporcionada por la capa de orquestación y comprobada frente a eventos externos.
Para los creadores de IA, la conclusión es tratar las estimaciones de duración y el éxito autodeclarado como señales no confiables. Los agentes de larga duración deberían tener un reloj externo, presupuestos explícitos, pruebas independientes y vías de escalado. Hasta que esos mecanismos sean estándar, la codificación “autónoma” sigue siendo una afirmación de flujo de trabajo que debe validarse tarea por tarea.
