Je construis des agents qui travaillent pendant que je dors

• Les agents d’IA d’écriture de code génèrent du code et appliquent des modifications sur une branche pendant que les développeurs dorment, mais il est difficile de vérifier la précision et la fiabilité du résultat
• Si l’IA qui a écrit le code le teste aussi, elle devient une machine à s’auto-congratuler et ne détecte pas les malentendus par rapport à l’intention d’origine
• En reprenant le principe central du TDD, on rédige d’abord les critères d’acceptation avant d’écrire le code, puis l’agent implémente en s’y conformant avant une vérification séparée
• Une pipeline en 4 étapes a été construite en combinant le mode headless de Claude Code (claude -p) et Playwright MCP comme outil de vérification, sans backend séparé
• Pour faire confiance aux livrables d’un agent, il faut définir clairement ce que signifie « terminé » avant de commencer ; c’est plus difficile que d’écrire un prompt, mais indispensable

---

Le problème de la vérification du code des agents autonomes

• Avec des outils d’IA comme Gastown, des agents peuvent écrire du code pendant des heures et appliquer des changements sur une branche, mais il n’existe aucune méthode de vérification fiable pour savoir si le résultat est réellement correct
• Après avoir animé des ateliers Claude Code auprès de plus de 100 ingénieurs au cours des 6 derniers mois, le même problème a été constaté dans toutes les équipes
• Les équipes qui utilisent Claude pour leurs PR au quotidien voient le volume de PR fusionnées passer de 10 par semaine à 40 ou 50, ce qui fait exploser le temps consacré à la revue de code
• Plus le système fonctionne de manière autonome, plus le problème s’aggrave : à un certain point, on ne relit même plus les diffs, on regarde le déploiement en espérant qu’il n’y ait pas de problème, puis on ne découvre les erreurs qu’après coup

Les limites des solutions existantes

• Embaucher davantage de reviewers ne suffit pas à suivre le rythme, et faire lire du code généré par l’IA toute la journée à des ingénieurs seniors est inefficace
• Quand Claude écrit les tests du code qu’il a lui-même produit, la vérification porte sur ce que Claude pense que l’utilisateur veut, et non sur ce que l’utilisateur voulait réellement
  • Cela peut attraper des bugs de régression, mais pas le malentendu initial (misunderstanding)
• Si la même IA écrit et vérifie en même temps, on obtient une « machine à s’auto-congratuler (self-congratulation machine) »
• Le but originel de la revue de code est d’apporter un second regard ; une revue croisée entre IA venant de la même source rate les mêmes choses

Ce que le TDD a bien compris

• Principe du TDD : écrire d’abord les tests, puis le code, puis s’arrêter quand les tests passent (sans en implémenter davantage)
• Si la plupart des équipes ne font pas de TDD, c’est parce que réfléchir à l’avance à ce que doit faire le code prend du temps
• L’IA résout le problème de vitesse, donc cette excuse disparaît — désormais, la partie lente consiste à juger si le code est correct
• Au lieu de tests unitaires, il est plus simple de décrire en langage clair ce que la fonctionnalité doit faire
  • Exemple : « L’utilisateur s’authentifie avec une adresse e-mail et un mot de passe. Si les identifiants sont invalides, afficher “Invalid email or password”. En cas de succès, rediriger vers /dashboard. Le jeton de session expire après 24 heures. »
• Ces critères peuvent être rédigés avant même d’ouvrir l’éditeur de code, puis l’agent implémente et autre chose effectue la vérification

Cas d’usage réel

• Modifications frontend

  • Génération de critères d’acceptation (Acceptance Criteria) à partir d’un fichier de spécification
    • AC-1 : en accédant à /login avec des identifiants valides, redirection vers /dashboard et définition d’un cookie de session
    • AC-2 : si un mot de passe invalide est saisi, afficher exactement « Invalid email or password » et rester sur la page /login
    • AC-3 : si des champs sont vides, le bouton d’envoi est désactivé ou une erreur inline s’affiche
    • AC-4 : après 5 échecs, bloquer la connexion pendant 60 secondes et afficher un message indiquant le temps d’attente
  • Chaque critère peut être évalué clairement en succès ou en échec
  • Une fois la fonctionnalité construite par l’agent, un agent navigateur Playwright exécute la vérification pour chaque AC, prend des captures d’écran et génère un rapport de verdict pour chaque critère
  • En cas d’échec, il est possible de voir précisément quel critère a échoué et ce qui apparaissait dans le navigateur

• Modifications backend

  • Le même schéma s’applique sans navigateur
  • On décrit le comportement observable de l’API (code de statut, en-têtes de réponse, messages d’erreur) et on vérifie avec des commandes curl

• Limites

  • Cela ne détecte pas une mauvaise compréhension de la spécification elle-même — si la spec est erronée dès le départ, la vérification peut réussir alors que la fonctionnalité reste incorrecte
  • Ce que Playwright détecte : échecs d’intégration, bugs d’affichage, comportements cassés dans un vrai navigateur
  • C’est une affirmation plus étroite que « précision vérifiée », mais cela attrape davantage de choses que ce qu’une revue de code attrapait de manière fiable

• Résumé du workflow

  • Rédiger les critères d’acceptation avant le prompt → l’agent implémente selon ces critères → lancer la vérification → ne relire que ce qui a échoué (revue des échecs, pas du diff)

Mise en place : une pipeline en 4 étapes

• Implémentée comme Claude Skill (github.com/opslane/verify), en utilisant claude -p (mode headless de Claude Code) et Playwright MCP
• Aucun backend custom ni clé d’API supplémentaire requis, uniquement le jeton OAuth Claude existant

• Étape 1 : Pre-flight

  • Bash pur, aucun appel LLM
  • Vérifie si le serveur de développement est lancé, si la session d’authentification est valide et si le fichier de spécification existe
  • Permet d’échouer rapidement avant de consommer des tokens

• Étape 2 : Planner

  • Un appel Opus
  • Lit la spec et les fichiers modifiés, puis détermine ce qui est nécessaire pour chaque vérification et comment l’exécuter
  • Lit le code pour trouver les bons sélecteurs, sans deviner les noms de classes

• Étape 3 : Browser Agents

  • Un appel Sonnet par AC, tous exécutés en parallèle
  • Avec 5 AC, 5 agents naviguent indépendamment et prennent des captures d’écran
  • Sonnet est 3 à 4 fois moins cher qu’Opus tout en offrant des performances équivalentes sur les tâches basées sur les clics

• Étape 4 : Judge

  • Un appel final à Opus lit toutes les preuves et renvoie un verdict par critère : pass, fail ou needs-human-review

• Installation

  • Installation possible comme plugin Claude Code : /plugin marketplace add opslane/verify
  • Ou bien cloner le dépôt pour le personnaliser — chaque étape correspond à un unique appel claude -p avec des entrées claires et une sortie structurée
  • Remplacement de modèle, ajout d’étapes et intégration CI possibles avec l’option --dangerously-skip-permissions

Leçon essentielle

• Le point clé est le suivant : « si la définition de “terminé” n’est pas explicitée à l’avance, on ne peut pas faire confiance au résultat »
• Rédiger les critères d’acceptation est plus difficile que d’écrire un prompt, mais cela force à prendre en compte les edge cases en amont et améliore la qualité
• Les ingénieurs y résistent pour la même raison qu’ils ont rejeté le TDD : cela semble plus lent au départ
  • Sans critères d’acceptation, il ne reste qu’à lire le résultat et espérer qu’il soit correct
• C’est une procédure indispensable pour garantir la fiabilité dans un environnement de développement piloté par l’IA