Avant de laisser Codex écrire une ligne de code, forcez-le à écrire les tests : cette méthode bat plusieurs approches agentiques classiques

Le meilleur prompt pour vibe coder commence peut-être par une interdiction : « Ne code rien pour l’instant. » Une étude publiée le 17 août 2026 montre qu’obliger une IA à écrire des tests exécutables avant la solution améliore plusieurs modèles sur LiveCodeBench. Son framework complet, TDD-Agent, dépasse ensuite les approches agentiques et basées sur la récupération auxquelles il est comparé sur RepoEval.

Ce résultat ne prouve pas que Codex, Claude Code ou Cursor deviennent automatiquement meilleurs dès que l’on ajoute « tests d’abord » à une consigne. Ces trois produits n’ont pas été évalués par l’étude. Il fournit en revanche une méthode concrète à tester : transformer les attentes floues en comportements vérifiables avant d’autoriser l’agent à toucher au code.

TDD-Agent oblige l’IA à préciser le comportement avant l’implémentation

Dans un workflow habituel, l’utilisateur décrit une fonctionnalité et l’agent produit immédiatement des fichiers. Les tests arrivent ensuite, parfois uniquement pour confirmer une solution déjà écrite. Le risque est évident : si l’agent a mal compris le besoin, il peut fabriquer des tests qui valident sa propre interprétation au lieu de vérifier l’intention initiale.

Les auteurs de TDD-Agent: Test-Driven Reasoning for Code Generation inversent cet ordre. L’agent inspecte d’abord le dépôt, traduit la demande en tests exécutables, puis écrit l’implémentation. Il exécute ensuite les tests et affine conjointement la solution et les tests à partir des résultats. La boucle s’arrête au plus tard après dix itérations.

Cette nuance distingue TDD-Agent d’un TDD rigide où le test serait intouchable. Ici, le test devient un artefact de raisonnement évolutif. Si l’exécution révèle qu’il encode une mauvaise hypothèse, l’agent peut le corriger. Mais cette liberté crée aussi le principal danger : modifier un test légitime simplement parce que le code ne le satisfait pas.

Le framework utilise des outils simples mais décisifs : inspection de l’arborescence, lecture et recherche dans les fichiers, soumission d’artefacts et exécution de pytest. Il a été évalué avec GPT-5-mini, DeepSeek-V3.2 et Qwen3-Coder-30B-A3B-Instruct. Il ne s’agit donc pas d’un nouveau modèle, mais d’une orchestration qui change le moment où le modèle doit formaliser ses hypothèses.

Le simple prompt « tests d’abord » améliore les trois modèles testés

La première expérience isole l’effet du test-first sur LiveCodeBench, un benchmark de problèmes de programmation. Chaque problème est échantillonné dix fois et le tableau rapporte le pass@1. TDD-prompt bat toutes les baselines comparées pour chacun des trois modèles, même lorsque l’écart reste modeste.

L’ablation est instructive. Lorsque la génération de tests est retirée du prompt, les scores tombent à 68,39 %, 67,28 % et 43,84 %. Écrire un plan ou réfléchir plus longtemps ne produit donc pas exactement le même effet que matérialiser les attentes sous forme d’exécutions capables d’échouer.

Le test force l’agent à répondre à des questions concrètes : quelles entrées sont acceptées ? Quel résultat est observable ? Qu’arrive-t-il à la limite ? Quelle erreur doit être levée ? Une phrase comme « ajoute un filtre par date » peut sembler claire jusqu’au moment où il faut décider du fuseau horaire, des bornes inclusives et du comportement lorsque les dates sont inversées.

Sur RepoEval, la boucle complète prend une avance plus nette

La seconde expérience porte sur 455 tâches de complétion de fonctions issues de huit dépôts Python de RepoEval. TDD-Agent dispose cette fois du contexte du dépôt, de ses outils et de sa boucle d’exécution. Avec cinq itérations, il dépasse déjà mini-SWE-agent ; dix itérations améliorent encore légèrement le résultat.

Une autre ablation montre que le résultat ne vient pas seulement de la réflexion, ni seulement du premier lot de tests. La variante « Vanilla » obtient 68,35 %, 73,63 % et 52,97 %. Une seule passe test-first atteint 69,89 %, 76,48 % et 54,51 %. Le framework complet monte à 78,24 %, 90,77 % et 59,34 %. Le bénéfice principal semble donc venir de l’association entre tests préalables et raffinement itératif du code comme des tests.

Plus fiable ne veut pas dire plus rapide ni moins cher

Ajouter une boucle d’exécution a un coût. Avec GPT-5-mini, mini-SWE-agent utilise en moyenne 11,95 appels, contre 18,62 pour TDD-Agent limité à cinq itérations et 22,92 pour dix itérations. Les tokens de prompt passent respectivement de 115 760 à 120 480 puis 155 610 en moyenne dans le protocole décrit.

Le temps mur n’a été mesuré que pour Qwen déployé localement : 26,71 secondes pour mini-SWE-agent, 42,47 secondes pour TDD-Agent à cinq itérations et 48,43 secondes à dix. Ces valeurs ne prédisent pas la durée d’une tâche dans Codex, Claude Code ou Cursor. Elles montrent simplement que la précision supplémentaire n’est pas gratuite.

La vraie question n’est donc pas « quel prompt répond le plus vite ? », mais « quel workflow atteint le plus vite une PR que l’on peut réellement accepter ? ». Dix minutes économisées pendant la génération n’ont aucun intérêt si un bug de régression exige ensuite deux heures de diagnostic.

Le test Okibata à reproduire avec Codex, Claude Code et Cursor

L’étude ne compare pas ces trois agents commerciaux. Pour vérifier si le résultat se transpose à votre environnement, il faut leur confier la même fonctionnalité, le même commit de départ, le même temps maximal et les mêmes outils. OpenAI présente Codex comme capable de comprendre un dépôt, construire et tester des fonctionnalités, exécuter des vérifications et relire un diff ; cela rend le protocole réalisable, mais ne constitue pas une validation officielle de TDD-Agent.

Choisissez une fonctionnalité assez petite pour être terminée, mais assez ambiguë pour exiger de vraies décisions. Exemple : « Dans la page des commandes, ajoute un filtre par période, persiste-le dans l’URL et conserve le résultat lors d’un rafraîchissement. » Préparez ensuite trois copies propres du dépôt.

Workflow A : implémenter immédiatement

Implémente cette fonctionnalité dans le dépôt.
Exécute les vérifications pertinentes et prépare un diff prêt à relire.

Workflow B : réfléchir puis implémenter

Analyse le besoin et le dépôt. Présente un plan court, puis implémente
la fonctionnalité. Exécute les vérifications pertinentes et prépare
un diff prêt à relire.

Workflow C : écrire les tests avant le code

Ne modifie encore aucun fichier d’implémentation.

1. Inspecte le dépôt et ses tests existants.
2. Traduis le comportement demandé en tests exécutables : cas nominal,
   limites, erreurs et régression.
3. Exécute ces tests et confirme qu’au moins l’un échoue pour la raison attendue.
4. Présente les hypothèses prises. N’implémente qu’ensuite le changement minimal.
5. Ne supprime, n’affaiblis et ne contourne jamais un test uniquement pour passer au vert.
6. Si un test est incorrect, explique précisément quelle exigence ou quel code existant
   le prouve avant de le modifier.
7. Exécute les tests ciblés puis la suite pertinente, et présente le diff.

Ce dernier prompt ne demande pas « tous les tests imaginables ». Il demande tous les comportements identifiés pour la fonctionnalité : scénario nominal, bornes, erreurs prévisibles, autorisations et régressions associées. Une suite gigantesque augmente le bruit sans garantir qu’elle teste la bonne chose.

Mesurez la PR acceptable, pas seulement le premier écran qui fonctionne

Pour chaque couple agent-workflow, consignez les mêmes données :

• réussite au premier lancement : la fonctionnalité fonctionne-t-elle sans intervention manuelle ?
• bugs découverts plus tard : combien de cas du cahier d’acceptation ont échoué après la réponse finale ?
• régressions : combien de tests préexistants ou de parcours voisins ont cassé ?
• tours avec l’agent : combien de relances humaines ont été nécessaires ?
• qualité des tests : les assertions échouent-elles si l’on réintroduit volontairement le bug ?
• durée totale : combien de minutes jusqu’à une PR acceptable après revue, et non jusqu’au premier code généré ?

Pour tester la qualité de la suite, introduisez après coup deux ou trois mutations simples : inversez une condition, retirez un contrôle d’autorisation, décalez une borne de date. Si les tests restent verts, leur couverture est peut-être décorative. Cette vérification protège contre le scénario où le code et les tests sont cohérents entre eux, mais faux par rapport au besoin.

Alternez aussi l’ordre des essais et repartez toujours du même commit. Sinon, l’expérience humaine acquise lors du premier workflow avantage les suivants. Gardez le modèle, son niveau de raisonnement, les règles du dépôt et la limite de temps constants.

Le principal piège : l’agent peut écrire un mauvais test très convaincant

TDD-Agent traite code et tests comme deux pistes ajustables. Cette souplesse aide à corriger une hypothèse erronée, mais complique l’attribution de l’erreur. Quand un test échoue, est-ce l’implémentation qui est fausse ou le test ? L’agent peut modifier le bon côté, ou « réparer » une solution correcte pour satisfaire un test halluciné.

Dans l’analyse des échecs rapportée par les auteurs, les cas où le code et les tests générés se contredisent restent sous 10 % : 3,03 % pour GPT-5-mini, 4,76 % pour DeepSeek-V3.2 et 8,10 % pour Qwen. Le problème dominant est plus discret : l’implémentation passe les tests générés, mais échoue aux tests du dépôt conservés hors de la boucle. Autrement dit, la suite produite n’est pas assez discriminante.

Trois garde-fous deviennent indispensables :

1. conserver des critères d’acceptation rédigés par un humain que l’agent ne peut pas réécrire ;
2. exiger une justification avant tout affaiblissement d’assertion ou suppression de test ;
3. valider la solution avec des tests préexistants, des tests cachés ou une revue indépendante.

Le test-first ne transfère donc pas la vérité à l’IA. Il rend ses hypothèses observables plus tôt, ce qui permet de les contester avant qu’elles ne se dispersent dans plusieurs fichiers.

Inscrire la règle dans AGENTS.md évite de répéter le prompt

Si le workflow fonctionne pour votre équipe, vous pouvez l’ajouter à vos instructions permanentes. Le guide Okibata explique comment utiliser un fichier AGENTS.md commun à Codex, Claude, Cursor et Gemini. Une règle courte vaut mieux qu’un manifeste impraticable :

Pour toute fonctionnalité ou correction :
- inspecter les tests existants ;
- ajouter ou modifier d’abord un test de régression qui échoue ;
- exécuter ce test et consigner la cause attendue de l’échec ;
- produire l’implémentation minimale ;
- exécuter les tests ciblés puis la suite pertinente ;
- ne jamais affaiblir une assertion sans expliquer l’exigence qui le justifie.

Cette consigne complète bien une boucle agentique longue comme Gauntlet Loop : avant chaque modification, l’agent ajoute une preuve exécutable du comportement qu’il cherche à obtenir. Elle donne aussi un cadre plus précis au workflow d’un agent de programmation comme Codex, au-delà du simple « continue jusqu’à ce que cela fonctionne ».

Ce que l’étude ne permet pas de conclure

TDD-Agent est une prépublication arXiv v1 déposée le 17 août 2026, pas une étude évaluée par les pairs. RepoEval ne couvre ici que 455 complétions de fonctions issues de huit dépôts Python. Il ne mesure ni la création d’une application complète, ni l’expérience utilisateur, ni la sécurité en production, ni la maintenance d’une PR plusieurs mois plus tard.

Les trois backbones testés ne sont pas les interfaces Codex, Claude Code et Cursor. Le nom GPT-5-mini dans un tableau ne suffit pas à attribuer les mêmes gains à Codex, qui ajoute son propre environnement, ses outils et ses instructions. Les résultats ne prouvent pas non plus que le test-first gagne pour toutes les tâches : une modification purement visuelle, un prototype jetable ou une exploration de données peuvent justifier un protocole plus léger.

Enfin, un benchmark récompense la réussite à des tests de référence. Une équipe doit aussi mesurer la lisibilité, la portée du diff, les dépendances ajoutées, la sécurité, la performance et la facilité de retour arrière. Des tests verts sont une condition utile, jamais une définition complète de la qualité.

Alors, faut-il vraiment interdire à l’IA de coder immédiatement ?

Pour une fonctionnalité métier, une correction de bug, une migration ou tout changement susceptible de régresser, oui : demander d’abord des tests exécutables est une expérience peu coûteuse et fondée sur des résultats prometteurs. Pour une esquisse sans comportement stable, la règle peut être prématurée.

Le message important n’est pas que l’IA doit produire davantage de code de test. C’est qu’elle doit rendre son interprétation vérifiable avant de construire dessus. Un plan reste du texte ; un test qui échoue pour la bonne raison transforme une intention en contrat observable.

Le meilleur prompt pour vibe coder ne commence donc peut-être pas par « réfléchis davantage », mais par « ne code rien : prouve d’abord que tu sais ce qui doit fonctionner ».