Code humain de 2020 écrase les agents codés par vibe dans les tests agents

ChatGPT et d’autres outils de codage par vibe ont été mis à l’épreuve dans près de 40 000 matchs – et ont perdu face à du code écrit par des étudiants en master avant l’invention des modèles de langage grand public.

Dans une nouvelle étude menée au Royaume-Uni, les chercheurs ont opposé des agents codés par des humains à des agents codés par vibe développés avec les derniers modèles de langage grand public (LLM), tels que ChatGPT-5 et Claude, et ont constaté que les agents créés sans l’aide de l’IA ont facilement battu les versions facilitées par l’IA.

Les deux ensembles d’agents ont été créés par différentes générations d’étudiants du Laboratoire d’intelligence artificielle de l’Institut fédéral suisse de technologie de Lausanne. Les agents non-IA ont été développés dans le cadre d’un travail universitaire en 2020, deux ans avant la création de ChatGPT et le début de la révolution LLM, tandis que les nouveaux agents ont été créés par des étudiants actuels, aidés par les derniers et les meilleurs LLM disponibles.

Même avec un jeu truqué, les solutions codées par vibe n’ont pas pu gagner, et les cinq premières places ont été constamment occupées par des agents « bruts », avec la majorité des agents LLM (33 sur 40) battus sans effort par des agents de base « très simples », sur 38 304 défis dans un tournoi, sur un large éventail de variables et de circonstances.

Le document indique:

‘Nos travaux démontrent que, même si les LLM de pointe peuvent générer du code qui fonctionne (c’est-à-dire sans erreurs de syntaxe), la solution générée n’est pas compétitive par rapport aux solutions conçues par des humains en termes de planification stratégique, d’optimisation ou de concurrence multi-agents.

‘Ainsi, ce travail met en avant cette nouvelle frontière dans la génération de code, et vise à faciliter le développement de références, de jeux de données et de références open source qui mettent l’accent sur la synthèse de code basée sur la raison.’

Le défi conçu était de participer de manière créative aux enchères, sur une variété de stratégies, et d’organiser la logistique de livraison des articles gagnés aux gagnants.

Les auteurs notent qu’un certain nombre d’avantages ont été accordés aux LLM, tels que l’intervention dans leur code pour améliorer leurs performances – un avantage non autorisé pour le code de 2020. Malgré cela, même lorsqu’ils ont reçu du code correctif qui aurait certainement amélioré leurs résultats, les LLM n’ont pas pu l’accepter ou l’utiliser:

‘[Dans] notre référence, même lorsque nous exposons une bonne solution en contexte, le LLM est toujours incapable de l’utiliser.

‘Ce résultat soulève également des questions de recherche intéressantes sur les limites de l’apprentissage en contexte et de la résolution de problèmes augmentée dans des scénarios complexes.’

Les LLM utilisés dans le test étaient GPT-5 Thinking, Gemini 2.5 Pro, Claude Opus 4.1, et DeepSeek R1*.

Le nouvel article est intitulé Le codage par vibe peut-il battre les étudiants en master? Un tournoi LLM contre un codage humain sur la planification stratégique basée sur le marché, et provient d’un auteur de l’Université de Southampton et d’un autre de l’Université d’Oxford et de l’Institut Alan Turing. La référence sera, selon les auteurs, publiée prochainement.

Méthode

Les auteurs notent que les tests traditionnels dans ce domaine se concentrent sur des défis avec des solutions binaires clairement définies (correct ou non correct), vérifiées à l’aide de tests unitaires. En affirmant que cela n’est pas la façon idéale d’explorer les limites du codage aidé par LLM, les auteurs ont conçu un scénario de défi plus complexe, avec plusieurs références internes et jalons, dans lequel la victoire est possible, mais loin d’être simple:

Comparaison des approches standard basées sur les tests unitaires (ci-dessus) et le scénario de défi plus ouvert conçu par les auteurs (en bleu, ci-dessous). Source

Le problème d’enchères, de ramassage et de livraison (APDP) utilisé pour l’étude des auteurs a été en partie choisi en raison de la disponibilité d’un corpus de travaux d’étudiants de 2020 de l’université suisse; des travaux qui visaient à créer des agents automatisés pour la tâche APDP, avant toute capacité à renforcer le développement par l’IA. Par conséquent, il était relativement facile de demander aux étudiants modernes de réaliser la même tâche, mais avec les outils actuels.

Les auteurs ont cherché à éviter les cadres de test populaires tels que HumanEval, BigCodeBench et WebDev Arena (entre autres), car cette classe de procédures de test a tendance à souffrir de contamination de données (c’est-à-dire des instances où le système peut avoir formé sur les données de test au lieu de respecter une séparation).

Le APDP est un problème logistique à deux étapes basé sur les enchères inversées et la planification de véhicules. Dans la première étape, les agents concourent pour gagner des tâches de livraison en soumettant des offres pour le montant qu’ils devraient être payés pour chaque tâche. Faire une offre trop élevée signifie perdre la tâche; faire une offre trop basse peut signifier perdre de l’argent.

Dans la deuxième étape, chaque agent doit créer un plan efficace pour remplir uniquement les tâches qu’il a gagnées, en affectant des véhicules avec des capacités et des coûts différents, sous des contraintes de temps et de ressources:

Dans le APDP, les entreprises font des offres dans des enchères inversées pour des tâches de livraison, puis optimisent les itinéraires de véhicules pour remplir uniquement les tâches qu’elles gagnent, en visant à maximiser le profit.

L’objectif n’est pas simplement de compléter les tâches, mais de maximiser le profit global en anticipant quelles combinaisons de tâches fonctionneront le mieux ensemble, et en prédisant les stratégies des concurrents qui tentent tous de faire de même.

Le référence APDP augmente la difficulté des tâches de génération de code en introduisant une planification stratégique sur une séquence d’enchères interdépendantes, avec chaque offre qui redessine le paysage des choix futurs; et nécessite donc que les agents raisonnent non seulement sur les coûts immédiats, mais sur la position, le timing et les conséquences à long terme.

Le problème de livraison de base est NP-difficile, c’est-à-dire qu’aucun algorithme ne peut trouver la meilleure solution en un temps raisonnable à mesure que le nombre de tâches augmente. Cela rend la force brute une approche inapplicable, et oblige les agents à échanger la précision pour la vitesse.

La course est lancée

Les auteurs ont comparé 40 agents codés par LLM à 17 agents codés par des humains dans une série de tournois tête-à-tête. Chacun des 12 tournois a utilisé une combinaison différente de quatre topologies de réseau routier, et a consisté en des appariements tous contre tous, avec les agents affrontant chaque adversaire deux fois: une fois en contrôlant chaque entreprise, avec des spécifications de véhicules différentes.

Ce dispositif a donné lieu à 3 192 matchs par tournoi, pour un total de 38 304 matchs. Dans chaque match, 50 tâches de livraison ont été mises aux enchères, définies par leurs points de ramassage et de livraison et leur poids, et tirées au hasard sur des réseaux routiers modélisés sur la Suisse, la France, la Grande-Bretagne et les Pays-Bas:

Réseaux routiers simplifiés utilisés dans le tournoi: Grande-Bretagne (en haut à gauche), Suisse (en haut à droite), Pays-Bas (en bas à gauche) et France (en bas à droite). Les carrés bleus et rouges marquent les tâches de ramassage et de livraison. Les triangles colorés montrent les positions actuelles des véhicules des agents.

Les agents étudiants ont été tirés d’un tournoi de cours de 2020. Huit provenaient des meilleures performances dans une finale à élimination simple, et quatre autres ont été choisis pour leur forte performance contre les agents de base dans des matchs tête-à-tête.

Les agents de base suivaient des heuristiques fixes. Naive calculait la distance totale et faisait une offre en conséquence, en utilisant un seul véhicule et en ignorant le regroupement; ExpCostFixedBid simula 10 tâches aléatoires, et fit une offre du coût marginal moyen; Honest calcula le coût marginal réel de l’insertion de la tâche dans l’horaire; ModelOpponent fit de même, mais ajouta une estimation du coût de l’adversaire, en faisant une offre du maximum; et RiskSeeking combina un priori à décrément temporel avec une estimation du coût en temps réel et un modèle d’adversaire – faisant à nouveau une offre du plus élevé des deux.

L’évaluation comprenait 40 agents codés par LLM construits à l’aide de GPT-5 Thinking, Claude Opus 4.1, Gemini 2.5 Pro et DeepSeek R1. Chaque modèle a été invité avec cinq stratégies distinctes, appliquées deux fois par modèle.

Deux stratégies utilisaient des invites statiques écrites par différents auteurs, tandis qu’une troisième demandait au modèle de réfléchir et de réviser sa propre sortie; une autre impliquait une critique et une révision par un LLM distinct. La dernière stratégie a utilisé GPT-4 pour synthétiser une nouvelle invite en passant en revue les quatre approches précédentes.

L’invite de base reflétait l’affectation d’étudiant originale, décrivant l’environnement de livraison et invitant le modèle à faire une offre et à planifier pour maximiser le profit, sans recourir à des méthodes à haute complexité.

Tous les agents LLM ont été testés en auto-jouer et en tournoi jusqu’à ce que tous les bogues observables soient corrigés. La correction des bogues a été gérée de manière autonome par les LLM eux-mêmes, invités avec les informations d’erreur.

Les défaillances courantes des LLM, note le document, comprenaient des violations des limites de temps d’attente, des défaillances pour ramasser ou livrer des tâches attribuées, et des violations des contraintes de capacité de véhicule – des erreurs qui ont souvent résulté du non-respect d’instructions explicites, ou d’une logique de replanification défectueuse^†:

‘Un autre problème courant que nous avons trouvé (la plupart du temps avec Gemini, Claude et DeepSeek, et pas autant avec GPT) est que le LLM a souvent échoué de manière répétée pour résoudre un bogue.

‘Par exemple, un agent a échoué de manière répétée, malgré de multiples (par exemple, 5 à 15) cycles d’invitation du LLM avec l’erreur et de réception de la version mise à jour du code.

‘La seule solution que nous avons trouvée pour de telles situations (où le LLM échoue à plusieurs reprises à résoudre le même bogue) est de re-commencer à zéro. Dans l’ensemble, nous avons observé la nécessité d’un effort manuel important pour atteindre un code sans bogues. Nous avons dû générer nettement plus d’agents pour obtenir les 40 agents sans bogues que nous avons évalués.’

Les résultats présentés ci-dessous résument les résultats de 12 tournois de double round-robin, couvrant quatre topologies de réseau et trois tournois par topologie, pour un total de près de 40 000 matchs:

Pour contexte, chaque agent a joué 112 matchs par tournoi, donc la moyenne maximale possible pour les victoires ou les défaites par agent est de 112. L’écart-type (SD) reflète la variabilité entre les tournois. Les agents codés par des humains apparaissent en gras. Les agents codés par LLM sont étiquetés par modèle (O = GPT-5 Thinking, G = Gemini 2.5 Pro, A = Claude Opus 4.1, D = DeepSeek R1), suivi d’un code de stratégie à deux lettres et d’un chiffre indiquant si l’agent est le premier ou le deuxième généré avec cette invite. Source

En ce qui concerne les résultats présentés ci-dessus, les auteurs déclarent^†:

‘Les LLM n’ont pas généré de code attendu/compétitif, même dans les variantes plus simples du problème APDP (malgré le code étant largement exempt de bogues de syntaxe). Cela souligne l’importance des références d’évaluation de code basées sur la raison qui vont au-delà de l’auto-complétion et identifient de nouvelles faiblesses des LLM.’

‘Nos résultats démontrent une supériorité claire des agents codés par des humains: (i) les cinq premières places sont constamment occupées par des agents étudiants, et (ii) la majorité des agents LLM (33 sur 40) sont battus par des agents de base très simples (tels que l’offre de coût fixe attendue).

‘Importamment, nous n’avons pas débogué le code étudiant (alors que nous avons soigneusement testé/débogué le code LLM, à la fois en auto-jouer et en tournoi). Chaque fois qu’un agent étudiant a planté, nous avons automatiquement accordé la victoire au LLM. Un grand nombre de ces plantages auraient été faciles à corriger (par exemple, les agents ont dépassé le temps d’attente), les agents étudiants pourraient donc potentiellement classer encore plus haut.’

Comme expérience supplémentaire, GPT-5 Thinking a été invité à améliorer le code de l’agent humain ayant obtenu les meilleurs résultats, Student 1; mais l’agent modifié par LLM a ensuite chuté à la dixième place, maintenant la pire des scores humains. Au lieu d’améliorer la solution, les modifications apportées par les LLM l’ont dégradée d’environ 20 %.

Les auteurs concluent:

‘[Nos] résultats mettent en évidence des limites importantes de la génération de code LLM, notamment leurs capacités de raisonnement et de planification limitées lors de la génération [de code]. Les LLM modernes sont capables de fournir du code exempt de bogues de syntaxe qui fonctionne, mais ce n’est pas la référence que nous devrions utiliser pour mesurer les progrès vers une IA générale avancée.’

Conclusion

Les auteurs eux-mêmes observent vers la fin de l’article que le codage par vibe a donné du pouvoir aux personnes de tous les niveaux de compétence technique, et le caractérisent de manière positive, comme une force nivelante. Cependant, ils impliquent également que, puisque le codage par vibe n’a fait que commencer, ses limites ne sont pas connues, et peuvent être supposées être plutôt plus élevées que ce à quoi on peut raisonnablement s’attendre.

Ils terminent leur offre en appelant à un changement d’objectif ‘du code qui compile au code qui concourt’.

Une question que le lecteur occasionnel de cet article intéressant peut se poser est de savoir si les auteurs frappent trop fort ou trop bas, puisque la tâche agente en question est considérablement plus complexe et plus impliquée que de simplement produire des scripts PowerShell et d’autres formes de fonctionnalités mineures et de corrections pour lesquelles le codage par vibe est bien adapté.

* Veuillez noter que le document fait référence en continu à ‘DeepThink R1′, qui semble être inexistante, ne se trouvant que dans un petit nombre de références sur Internet (présumément d’autres auteurs qui ont mal orthographié ‘DeepSeek R1)’. Si c’est mon erreur, veuillez me contacter via mes détails de profil, et je ferai les corrections.

^† Insistance des auteurs, pas la mienne.

Publié pour la première fois mercredi 26 novembre 2025. Modifié 17h35 est pour la mise en page.