Ce que les tests et les contrôles de bogues révèlent sur les agents logiciels

Un agent peut livrer un paquet qui réussit de nombreux tests ou une correction qui arrête un plantage connu. Ces résultats sont utiles, mais les contrôles peuvent ne porter que sur une interface fournie, une entrée précise ou un défaut connu.

Dans quatre études, l’exécution aide les agents à réviser le code et à exposer des défaillances, tandis que le protocole de test détermine ce que le résultat consigne comme une réussite.

La conclusion étayée reste limitée : chaque résultat concerne les comportements observés dans sa propre tâche et son évaluation.

Imaginons qu’un agent doive reconstruire un paquet Python à partir de son interface publique. Les fichiers doivent pouvoir être importés ensemble, utiliser les mêmes données de façon cohérente et réussir les tests du paquet.

Une exécution des tests donne à l’agent un échec concret à examiner, et un score final peut indiquer quelle part du comportement testé a été reconstituée. Pourtant, le paquet peut avoir des comportements que les tests fournis n’exercent jamais.

Avant de se fier au résultat, il faut savoir quels tests ont été exécutés et ce que le score compare.

Considérons maintenant un agent qui corrige une faille. Après la modification, l’entrée connue qui révèle le bogue peut ne plus provoquer de plantage, alors même que la correction change un comportement que les développeurs du projet voulaient conserver.

Un benchmark peut exécuter cette entrée, la suite de régression existante et les tests ajoutés avec le correctif amont ; chacun de ces contrôles répond à une question différente sur la correction. Un taux de réussite n’a de sens qu’avec le contrôle qui l’a produit et les conditions dans lesquelles l’agent a travaillé.

Un bogue de concurrence pose une autre difficulté : un plantage peut n’apparaître que lorsque deux fils d’exécution effectuent certaines opérations dans un ordre rare. Pour une personne qui examine le code, le problème peut encore être différent : le défaut peut dépendre de connaissances sur le projet qui dépassent les lignes modifiées.

Ces cas précisent la question commune. Quand des agents logiciels s’appuient sur des tests, une exécution contrôlée ou des archives de bogues connus, qu’ont-ils établi sur une modification, et qu’est-ce qui reste hors du champ des preuves ?