Sans développeur, un product manager publie une extension construite par des agents IA et la protège avec 89 tests-gardiens

L'agent écrit : « C'est fait, tous les tests passent. » Quand le projet n'a pas de développeur et que vous ne lisez pas le code vous-même, il reste deux options : croire l'agent sur parole ou inventer une méthode de vérification. Un product manager qui développe depuis janvier une extension Chrome avec deux agents IA, Claude Code et Codex, a choisi la seconde.

Au 28 octobre, son projet compte 593 commits, 78 478 lignes de code, 177 511 lignes de tests et une version 1.0.1 sur le Chrome Web Store.

Mais les tests ont été écrits par le même agent que le code : leur nombre ne prouve donc rien en soi. Par exemple, le produit promet de relire le fichier de réglages au moins une fois par heure. L'agent fait passer l'intervalle à un jour ; le test reprend la nouvelle valeur dans le même code, la compare à elle-même et reste vert.

L'utilisateur, lui, attend un jour. Contre ce risque, l'auteur a mis en place des « gardiens » (guard en anglais) : des tests qui protègent une promesse précise du produit et échouent si elle est rompue. Il y en a aujourd'hui 89.

Si vous confiez à un agent une tâche de plusieurs heures, vous pouvez reprendre cette approche.

Le produit et le terrain d'essai

L'extension s'appelle Chat with Multiple AI et envoie une même requête à 15 chats IA à la fois, dont ChatGPT, Claude et Gemini. Ce sont des sites tiers, qui changent sans prévenir. La description de la façon de travailler avec chaque chat est donc placée dans un fichier de configuration distinct. Quand un chat change, l'auteur corrige ce fichier, et le correctif parvient aux utilisateurs sans nouvelle version sur le store. Cela s'est produit deux fois : le 19 octobre et le 1er novembre. Avant la version 1.0.1, l'agent a lui-même déroulé 70 scénarios de recette dans le navigateur.

L'auteur répartit la vérification en plusieurs couches. Le build, les tests et les gardiens veillent à ce que les règles du code et celles des documents ne divergent pas. L'agent, dans le navigateur, montre ce que le produit fait réellement. Un relecteur indépendant examine les modifications qu'il n'a pas écrites lui-même. Le product manager, enfin, valide le comportement visible à partir d'une liste figurant dans le rapport : ce qui se passe après un clic, si le résultat apparaît, ce qui arrive en cas d'échec.

Le gardien : une promesse du produit inscrite dans un test

Le gardien de l'exemple vérifie deux conditions : l'intervalle de relecture est supérieur à zéro et ne dépasse pas une heure. Si l'agent le fixe à un jour, la seconde condition n'est pas remplie et le test échoue. Le nom du fichier du gardien est la promesse elle-même, formulée en langage courant, par exemple « le correctif publié parvient à l'utilisateur en moins d'une heure » ou « le rappel n'est pas envoyé tant qu'on n'a pas enregistré qu'on s'apprête à l'envoyer ». Sans cette trace, après un redémarrage, le produit ne saurait pas qu'il a déjà envoyé le rappel et l'enverrait une seconde fois. La liste des fichiers se lit ainsi comme la liste des promesses du produit.

Les gardiens ont été ajoutés de façon irrégulière : 2 en mai, 9 en juillet, 33 en août, 40 en septembre et 5 en octobre. Le modèle pratique de demande à l'agent est le suivant : décrivez la promesse avec les mots de l'utilisateur, demandez à l'agent de trouver ce qui la garantit dans le code, d'écrire un gardien au nom explicite et de montrer qu'il échoue lorsque la promesse est violée.

Un build vert et deux copies des règles

Un build vert peut ne rien vérifier. Le 27 juillet, le compteur d'erreurs de types (quand le code confond des types de données, par exemple en traitant du texte comme un nombre) est tombé à zéro. On peut arriver à zéro de deux façons : corriger les erreurs ou cesser de les chercher, par exemple en désactivant le mode strict ou en excluant un dossier de la vérification.

L'auteur a deux parades. La première est un seuil minimum : le contrôle compte les fichiers lus et échoue s'ils sont trop peu nombreux. La seconde est la casse volontaire : on enfreint exprès une règle dans une copie du projet, et le gardien doit échouer.

En développement, on parle de test de mutation. Le modèle casse une copie du projet de 42 façons et montre quel contrôle a détecté chaque panne ; sur l'ordinateur de l'auteur, la démonstration prend moins d'une minute.

Un autre problème tient à la duplication des règles. Claude Code et Codex lisaient leurs règles dans des fichiers différents, CLAUDE.md et AGENTS.md, qui devaient être identiques. Les écarts se sont accumulés : 9 lignes en mars, 12 en juin et 21 en août, alors que les fichiers comptaient 102 et 85 lignes. Le fichier de règles est passé de 61 lignes en février à 179 en octobre. Depuis le 25 septembre, il ne reste qu'un seul AGENTS.md, et un gardien échoue si un autre fichier de règles apparaît à côté. Les skills (instructions pour des actions répétables, comme un commit) se trouvent dans les dossiers de chaque agent ; le gardien compare donc chaque paire.

L'auteur reconnaît lui-même qu'il n'a pas mesuré la part d'amélioration due à son dispositif et celle due à des modèles plus performants. Il a publié ce dispositif sous forme de modèle ouvert sur GitHub (yesgenius/agent-harness).