Le test d'abord, et malheur à l'agent qui le retouche : le TDD imposé aux machines

TDFlow atteint 88,8 % sur SWE-Bench Lite quand les tests sont fournis avant le code. Chez Maestro, les tests sont écrits AVANT chaque story depuis juillet, avec une règle simple : un agent qui modifie un test, même préexistant, est signalé.

Un papier de recherche récent montre que TDFlow atteint 88,8 % de réussite sur SWE-Bench Lite quand les tests humains sont fournis avant l'écriture du code (arxiv.org/pdf/2510.23761). Chez Maestro, les contrats de vérification de chaque story sont figés avant le développement depuis juillet, avec une règle stricte : un agent qui modifie un test, même préexistant, est signalé.

L'IA qui triche à l'examen

Le problème documenté par les développeurs qui travaillent avec des agents est précis. Sur Hacker News : « it's impossible for a coding agent to restrain itself from delivering a fully-formed implementation FIRST, in one fell swoop. And THEN it generates the test afterward » (burnerToBetOut, news.ycombinator.com/item?id=46580108). Et un autre, sur l'ordre qui compte : « if you don't do this, it will churn out tests that pass but don't actually identify when things break » (0xbadcafebee, news.ycombinator.com/item?id=48416641). Un test écrit après le code se plie au code ; un test écrit avant lui impose une contrainte que le code doit satisfaire.

Pourquoi l'ordre compte, et pas seulement la présence de tests

Un agent qui écrit d'abord une implémentation, puis génère des tests pour la couvrir, note son propre devoir. Le contrat inversé (le test avant le code, figé dès le découpage en stories) empêche cette dérive : le code doit satisfaire une exigence posée en amont, indépendante de ce que l'implémentation finira par faire. C'est le même principe qui répond à la troisième critique du fil « le waterfall contre-attaque » sur le LLM comme compilateur non déterministe : le modèle reste probabiliste, ce qu'il doit satisfaire ne l'est plus.

Ce qu'un test altéré révèle

La partie la plus délicate n'est pas d'écrire le test avant, c'est d'empêcher qu'une réparation ultérieure ne le réécrive discrètement pour le faire passer. Un test modifié en cours de correction, même s'il existait déjà avant que l'agent n'y touche, déclenche un signalement explicite. C'est un détail d'implémentation, mais c'est lui qui rend la garantie réelle : sans ce signalement, rien n'empêche un agent bloqué de simplement assouplir l'exigence plutôt que de corriger le code.

Ce que ça a coûté chez nous

Mettre cette règle en place a fait remonter 13 défauts réels lors de la contre-vérification qui a suivi, des défauts qui seraient sinon restés invisibles jusqu'à ce qu'un vrai utilisateur les découvre en production. Le prix se paie aussi en sobriété : le régime express, le plus rapide, consomme un budget de méthode multiplié par 1,000 (la référence), le régime standard par 1,075 seulement, un surcoût mesuré et volontairement contenu plutôt que laissé filer. Toute la profondeur supplémentaire que le TDD exige va dans les régimes standard et complet, jamais dans l'express, qui reste taillé pour un prototype qu'on jette sans regret.

Ce que vous voyez, vous : des voyants verts, pas du code

Vous n'avez jamais à lire une ligne de test, ni à savoir ce qu'est un test. Ce que la validation humaine vous demande, c'est de juger si la story fait ce que vous vouliez, pas de vérifier la mécanique technique qui le prouve derrière. Le TDD imposé aux agents est une police d'assurance : vous ne lisez pas le contrat ligne à ligne, vous vérifiez qu'il est signé avant le sinistre, pas après. La beta de Maestro est gratuite, sur invitation : bemaestro.fr.