Dire « fais du TDD » à un agent ne suffit pas

Ce qui se passe

L'idée circule qu'il suffit d'indiquer une bonne technique de test à un agent codeur pour relever la qualité de ce qu'il produit. Dan Luu l'a mesuré, dans la posture de quelqu'un « sans expertise en test, qui a entendu dire qu'il fallait utiliser telle méthode ».

Le protocole est simple et sévère. Même tâche à chaque fois — implémenter Zstandard en Rust — jugée sur une suite de tests cachée, l'indicateur étant la proportion d'exécutions qui passent 100 % des tests. Vingt-six consignes ont été comparées :

ACL2, Alloy, « audit et fuzz des zones risquées », « audit d'abord », Creusot, Default (aucune instruction), tests différentiels, fuzzing, Hegel, Insta, « choisis toi-même », Kani, Lean 4, « ne fais pas d'erreur », tests métamorphiques, tests de mutation, tests basés sur les propriétés, Proptest, QuickCheck, rstest, framework de test intégré à Rust, solveurs SMT (Z3, cvc5, Yices), Spin, TDD, TLA+, Verus.

S'y ajoutent 4 skills publiques, dont celle d'un dépôt à 250 000 étoiles et 38 000 forks, celle de Trail of Bits, celle de Hegel, et une écrite par l'auteur. Chaque condition tourne 80 fois par niveau d'effort, avec codex sur GPT-5.6 Sol en efforts medium et xhigh.

Le résultat

Rien ne surpasse nettement le reste — et la condition sans aucune consigne se classe au-dessus de la moyenne.

Dans le détail : à effort xhigh, les conditions fuzzing et tests par propriétés font un peu mieux que les méthodes formelles en moyenne ; à effort medium, c'est beaucoup plus mêlé. Les skills de test recommandées sous-performent, alors que la skill improvisée par l'auteur s'en tire correctement — la différence qu'il pointe étant que la sienne cherche à écarter l'agent de son comportement par défaut, là où les autres ressemblent à des tutoriels. Le TDD sous-performe, comme prévu.

Le résultat tient sur une seconde tâche : 40 exécutions par condition sur la RFC IMAP donnent la même image, et quelques essais sur d'autres RFC aussi.

Pourquoi : la technique est imitée, pas appliquée

C'est la partie qui vaut la lecture. En regardant ce que les agents font réellement, un schéma revient : ils écrivent les tests qu'ils auraient écrits de toute façon, mais dans le vocabulaire de la technique demandée — ou bien ils appliquent la technique en surface, sans faire ce qui en produit la valeur.

• En vérification formelle, ils prouvent des propriétés hors sujet, et souvent peu nombreuses. Verus n'a jamais servi à vérifier le code lui-même, seulement à raisonner dans l'abstrait. Certaines preuves sont littéralement tautologiques :

  requires 0 < a <= window, 0 < b <= window, 0 < c <= window,
  ensures  0 < c <= window, 0 < a <= window, 0 < b <= window,

• En tests par propriétés, ils s'appuient massivement sur des entrées aléatoires qui tombent surtout dans les cas rejetés, ou vérifient une propriété triviale avec beaucoup de tirages sans valeur.

• En tests classiques, ils passent leurs propres tests — mais les tests sont mauvais. L'exemple donné est net : sur une fonctionnalité qui manipule quatre flux binaires distincts, ils soumettent quatre flux identiques, ce qui rend indétectable toute erreur d'ordre entre eux. Une inversion du sens de lecture du flux entre encodage et décodage échappe pour la même raison : les tests sont palindromiques.

Fait amusant et instructif : sur cette fonctionnalité, les agents « Verus » ont écrit un test dans 89 cas sur 160, exactement le même nombre que les agents « Default ». Ils l'ont simplement écrit moins bien.

Ce que ça change pour vos consignes

1. Une instruction qui nomme une technique ne vaut rien. « Utilise du property-based testing » produit du vocabulaire, pas de la couverture.
2. Décrivez le comportement attendu, pas l'étiquette. C'est ce qui distingue la skill efficace des skills-tutoriels : elle pousse l'agent hors de son réflexe.
3. Méfiez-vous des skills populaires. 250 000 étoiles ne mesurent pas un effet. Celle-ci recommande le TDD, qui sous-performe ici.
4. L'effort compte plus que la méthode. Une boucle naïve à faible effort donne de moins bons résultats, quelle que soit la consigne.

À retenir

Une réserve honnête pour finir, que l'auteur pose lui-même : ces échecs sont souvent idiosyncrasiques et difficiles à expliquer de l'extérieur. Il n'y a pas de motif clair, sinon que les agents ne savent pas tirer parti d'une technique dont on ne leur a donné que le nom. Sa remarque en creux est peut-être la plus utile : personne ne semble avoir construit d'environnements d'apprentissage par renforcement pour apprendre aux agents à bien tester, alors qu'on l'a fait pour l'optimisation.

Source : Dan Luu