Les agents de codage IA peinent à suivre le temps, selon une étude

Claude Code d’Anthropic et Codex d’OpenAI peuvent accomplir des tâches logicielles, mais une nouvelle étude suggère qu’ils ont une faible compréhension du temps nécessaire pour les réaliser — et une capacité encore plus faible à juger leurs propres performances. Cette découverte est importante à mesure que les agents de codage IA passent de courts prompts interactifs à des tâches exécutées de manière autonome pendant des dizaines de minutes ou des heures.

Deux chercheurs indépendants travaillant dans le cadre du programme de recherche MATS ont testé les assistants sur 200 tâches de ProgramBench et 18 benchmarks supplémentaires, selon le récit de The Decoder sur l’étude. Il leur a été demandé d’estimer la durée requise avant de commencer, puis d’indiquer le temps écoulé après avoir terminé le travail. Les deux systèmes surestimaient régulièrement la durée des tâches, tout en s’attribuant des notes bien plus élevées que ne le justifiaient les résultats des tests pour les travaux échoués.

L’étude ne montre pas que les modèles n’ont littéralement pas accès au temps dans tous les environnements logiciels. Elle met plutôt en évidence une faiblesse pratique dans la manière dont les agents IA actuels perçoivent le temps écoulé et utilisent cette information pour gérer le travail. Lorsque les chercheurs ont fourni un outil qui indiquait le temps écoulé, les agents sont apparemment devenus précis presque à chaque fois.

De grandes erreurs sur de courtes tâches de codage

Sur ProgramBench, les deux agents prédisaient généralement que les tâches prendraient environ 90 minutes, quelle que soit leur difficulté, a rapporté The Decoder. Dans une deuxième série de tests, les estimations de Claude Code étaient erronées d’environ un facteur trois en moyenne, tandis que celles de Codex l’étaient d’un facteur de six à dix.

Les plus grandes erreurs apparaissaient sur les tâches courtes. Selon le rapport, les prédictions ne se rapprochaient de la réalité que lorsque le travail s’étendait sur plusieurs heures. Ce schéma est important sur le plan opérationnel : un agent qui prévoit 90 minutes pour une tâche qu’il peut achever en quelques minutes peut prendre de mauvaises décisions quant au moment d’arrêter, de demander de l’aide ou de lancer une autre action.

Les résultats variaient également fortement selon l’environnement logiciel entourant chaque modèle. Claude Code continuait à travailler jusqu’à ce qu’il juge la tâche terminée, avec une durée d’exécution médiane rapportée d’environ 90 minutes. Codex s’arrêtait après environ une demi-heure dans de nombreux cas, même lorsque la difficulté de la tâche changeait.

Les chercheurs ont attribué une partie de la différence au « harness » de l’agent — c’est-à-dire aux outils, instructions, limites d’exécution et logique de contrôle entourant le modèle de langage. Le même modèle sous-jacent aurait nécessité en moyenne 2,5 fois plus d’étapes dans Claude Code que dans Codex. Cela suggère que le temps d’exécution n’est pas simplement une propriété du modèle ; il est aussi façonné par l’architecture du produit qui le déploie.

L’auto-évaluation était un autre point faible

Les tests ont révélé des problèmes au-delà des estimations de durée. Selon The Decoder, les modèles surestimaient la qualité de leur propre travail d’environ 20 points de pourcentage en moyenne. Ils s’attribuaient parfois de fortes notes même lorsque la tâche avait largement échoué.

Dans un exemple, les deux systèmes auraient évalué leur travail à environ 70 % de réussite, alors que les résultats mesurés étaient de 7 % et 14,5 %. La source décrit les modèles concernés comme Opus 4.8 et GPT-5.5. Étant donné que les éléments disponibles ici sont un compte rendu de l’étude et non l’article complet ni les données brutes, ces identifiants de modèles et les conditions exactes d’évaluation doivent être considérés comme des résultats rapportés plutôt que comme des faits vérifiés indépendamment.

L’auto-évaluation est centrale dans le travail logiciel autonome. Un agent de codage peut devoir décider s’il faut continuer à itérer, déclarer une tâche terminée, réviser un patch ou faire remonter un problème à un humain. Si sa confiance est déconnectée des résultats des tests, un flux de travail peut sembler sain tout en produisant du code incomplet ou défectueux.

Pourquoi le harness compte pour le déploiement

Pour les développeurs, la leçon principale n’est pas simplement que Claude Code et Codex font de mauvaises prédictions. C’est que le comportement de l’agent dépend fortement des contrôles autour du modèle. Une équipe produit choisissant un assistant de codage IA devrait évaluer non seulement les performances sur benchmark, mais aussi la manière dont le système gère les délais, les reprises, les échecs d’outils, les retours de tests et les conditions explicites d’arrêt.

Le résultat rapporté de l’étude avec un outil de temps écoulé offre une réponse d’ingénierie relativement simple. On ne devrait pas attendre d’un agent qu’il infère le temps à partir de l’historique des conversations, de la génération de tokens ou du nombre d’appels d’outils. Le temps d’exécution devrait être fourni par une horloge externe fiable et appliqué par la couche d’orchestration.

Cela ne résout pas tous les problèmes de supervision. Un minuteur peut dire à un agent que deux heures se sont écoulées, mais il ne peut pas déterminer si le code obtenu est sûr, complet ou digne d’être déployé. Les équipes peuvent encore avoir besoin de tests indépendants, de revues de changements, d’un cloisonnement, de plafonds de dépenses et de règles d’escalade. Ces contrôles deviennent plus importants lorsqu’un agent est autorisé à travailler sans supervision continue.

La découverte complique également les comparaisons entre produits de codage IA. La durée d’exécution plus courte observée pour Codex et la plus longue séquence d’étapes de Claude Code peuvent refléter des valeurs par défaut différentes plutôt qu’une simple différence d’intelligence ou de productivité. Les acheteurs qui comparent des produits devraient demander ce que l’agent est autorisé à faire, combien de temps il peut fonctionner et comment l’achèvement est vérifié.

Preuves et limites de l’affirmation

Les preuves proviennent d’une étude menée par deux chercheurs indépendants dans le cadre de MATS, comme l’a rapporté The Decoder. L’ensemble de test rapporté combinait ProgramBench avec une suite supplémentaire de 18 tâches de benchmark. Le compte rendu fournit des résultats numériques sur l’estimation du temps, la durée d’exécution, le nombre d’étapes et l’auto-évaluation, mais les éléments disponibles ici n’incluent pas la méthodologie complète, les définitions des tâches, l’analyse statistique ni une réplication indépendante.

En conséquence, ces conclusions doivent être lues comme la preuve d’une faiblesse d’évaluation spécifique, et non comme une mesure universelle de toutes les versions de tous les agents IA. Les résultats peuvent changer avec les mises à jour du modèle, les prompts système, les outils disponibles, les fenêtres de contexte, les types de tâches et la conception du harness. L’affirmation selon laquelle l’accès à un outil de temps écoulé a produit une précision quasi universelle est particulièrement utile comme signal d’ingénierie, mais elle provient tout de même de l’étude rapportée et nécessite des tests plus larges.

Il existe également une distinction importante entre estimer le temps et suivre le temps. Un agent peut être capable de lire une horloge lorsqu’on lui fournit l’outil approprié tout en échouant à prévoir combien de temps prendra une tâche inconnue. Les équipes produit devraient tester séparément ces deux capacités.

Ce qu’il faut surveiller ensuite

Les chercheurs prévoient apparemment de tester si les agents peuvent suivre des instructions telles que travailler en continu pendant une durée déterminée. Cette expérience pourrait montrer si l’information temporelle externe améliore non seulement les rapports rétrospectifs, mais aussi le contrôle des tâches en temps réel.

Les évaluations de suivi devraient également tester des versions de modèles plus récentes, des projets logiciels plus longs, la récupération après échec et différents harness. Un benchmark utile mesurerait si un agent s’arrête à l’échéance, produit un résultat exploitable avant celle-ci et indique avec précision ce qui reste inachevé.

Pour les acheteurs d’entreprise, les signaux pratiques seront visibles dans la conception du produit : affichage persistant du temps écoulé, budgets d’exécution stricts, vérification indépendante et mécanismes de relais clairs. Les fournisseurs qui publient des données reproductibles sur ces contrôles rendront plus facile la distinction entre une véritable autonomie et des agents qui continuent simplement de fonctionner jusqu’à ce qu’une limite cachée soit atteinte.

Point de vue de Creati.ai

L’étude met en lumière un problème de contrôle à la frontière entre les modèles de langage et les logiciels autonomes. La conscience du temps n’est pas un trait humain abstrait que les produits doivent imiter d’une manière ou d’une autre ; c’est une capacité mesurable du système qui peut être fournie par la couche d’orchestration et vérifiée par rapport à des événements externes.

Pour les créateurs d’IA, le message est de traiter les estimations de durée et les auto-évaluations de réussite comme des signaux non fiables. Les agents de longue durée devraient disposer d’une horloge externe, de budgets explicites, de tests indépendants et de voies d’escalade. Tant que ces mécanismes ne seront pas la norme, le codage « autonome » restera une affirmation de flux de travail qui devra être validée tâche par tâche.