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

[github88]

Même en faisant du TDD, au niveau actuel où les LLM manipulent les tests pour les faire passer, une revue humaine reste absolument nécessaire..

[GN⁺]

Avis Hacker News

• J’ai l’impression que les frameworks LLM qui sortent en ce moment rendent au contraire le développement plus difficile et plus coûteux
  On peut déjà aller très loin avec la configuration de base, donc construire une multitude de wrappers et de harnais alors que les modèles changent sans cesse me paraît inefficace
  Cette façon de faire, à laisser tourner toute la nuit en brûlant de l’argent, finira à mon avis comme un sujet de moquerie, un peu comme le mème sur PHP

  • Évidemment, c’est différent si on est du côté de ceux qui vendent des pelles pendant la ruée vers l’IA
    D’après l’article, « au cours des six derniers mois, plus de 100 ingénieurs ont participé à des ateliers Claude Code »
  • J’espère que les concurrents utiliseront le plus possible d’agents IA dans leur base de code
    Quand ils les auront fait tourner jour et nuit jusqu’à ce que la boîte d’IA fasse faillite, et qu’il ne reste plus que 80 % de spaghetti code généré par IA, on verra bien qui rira à la fin
  • Il n’y a pas lieu de se moquer de PHP. Certains de mes meilleurs projets ont encore aujourd’hui été faits en PHP
    J’ai même l’impression que ce qu’on faisait en PHP il y a 15 ans était meilleur que l’environnement full-stack JS/TS actuel
  • On voit seulement maintenant à quel point l’ancien mème anti-PHP était idiot
    PHP est toujours là et continue d’évoluer. Le tooling autour des LLM finira lui aussi par devenir un outillage de base de ce type
  • Ce n’est pas simplement une hausse de la charge de travail, c’est une fusion des rôles
    Les frontières entre BA, PO, QA et SWE deviennent floues. On voit émerger des rôles hybrides à mi-chemin entre le métier et le développement

• On dirait qu’en ce moment les gens utilisent des agents juste pour pouvoir dire qu’ils en utilisent
  Moi, je n’en fais tourner que deux, un pour l’écriture et un pour la revue, et ça me donne déjà facilement 5 à 7 fois plus de productivité
  Je passe plus de temps à revoir les specs, et l’agent termine le code en 10 à 30 minutes, donc il n’y a pas vraiment d’urgence

  • Le concept d’« agent qui tourne toute la nuit » ne me parle pas. Claude finit généralement en 5 à 20 minutes
    Et demain il y aura encore du travail, donc aucune raison de le laisser tourner toute la nuit
  • Moi aussi, au début, je faisais tourner plusieurs agents en parallèle, mais au final il était bien plus efficace de se concentrer sur un seul répertoire à la fois
  • Une grande partie de ce que faisait un SWE peut désormais être traitée par l’IA en mode brute force
    Du point de vue du client, que le bug vienne d’Inde, de San Francisco ou d’une IA ne change pas grand-chose
  • Moi aussi, je ne fais tourner que deux agents et je fais beaucoup de réglages fins
    C’est une approche bien plus contrôlée que les « orchestres d’agents » à la mode en ce moment
  • Je pense que la validation des specs est l’étape la plus importante
    C’est pour ça que j’ai créé moi-même la compétence verify, pour vérifier que Claude respecte bien les specs

• Si on fait appliquer à Claude le pattern red-green-refactor, la qualité des tests monte clairement d’un cran
  Et si on va plus loin en créant des sous-agents red/green/refactor qui se vérifient mutuellement, ça fonctionne plutôt bien
  L’essentiel, c’est de ne pas mélanger les contextes

  • Mais à mesure que le refactoring avance, les tests deviennent souvent inutiles ou disparaissent
    Le reward hacking existe bel et bien, et il est difficile de s’en protéger
  • Même en lui demandant de faire du TDD red/green, il écrit des tests qui ne peuvent pas échouer puis passe à autre chose en disant « c’est déjà résolu »
    Même en suivant ce guide, le problème des mauvais tests reste majeur
  • J’ai entièrement appliqué Outside-in TDD à Claude Code
    Les résultats étant bons, j’ai publié les principes et des exemples ainsi qu’un starter repo
  • J’aimerais en savoir plus sur la façon de mettre en œuvre le pattern green/red/refactor. Ce serait bien d’avoir des ressources de référence
  • Cette approche est aussi efficace pour la revue de PR
    Il est important de séparer l’auteur et le vérificateur, et même avec le même modèle, séparer les contextes améliore la qualité

• Avec les limites actuelles de contexte des LLM, de vrais agents restent impossibles pour le moment
  Au-delà de 500 lignes de code, les erreurs explosent, et autour de 200 lignes on atteint déjà la limite
  Au final, un LLM n’est qu’un outil à utiliser de manière répétée comme une calculatrice

• J’appelle ce phénomène le « Test Theatre »
  J’ai écrit un article à ce sujet ici. Il faut activement l’éviter

  • Les agents écrivent parfois 600 lignes de tests pour 100 lignes de code, mais ce sont le plus souvent des tests dénués de sens
    De bons tests doivent vérifier les design patterns et les dépendances, et aider au débogage
  • En utilisant le property testing, on obtient de bien meilleurs résultats
    Par exemple, avec Schemathesis on vérifie automatiquement les permissions utilisateur ou la présence de réponses 5xx
  • Test Theatre est une expression très juste. Les tests passent, mais en réalité ils ne prouvent rien du tout
  • La meilleure méthode consiste à imposer Outside-in TDD + mutation testing
    J’ai publié un POC à ce sujet ici
  • En réalité, ce genre de tests purement formels existait déjà avant. Dans la plupart des cas, ils testent simplement l’implémentation elle-même

• J’expérimente en ce moment l’orchestration d’agents
  L’idée centrale est de réduire les appels au LLM et de les relier via un pipeline de scripts déterministe
  J’ai détaillé le sujet dans cet article

  • Je tente quelque chose de similaire avec une orchestration centrée sur les scripts
    Comme dans ce compte-rendu d’expérimentation, le cœur du système est davantage dans les scripts que dans le LLM

• Je fais tourner six agents pour les opérations métier
  Ils s’occupent d’études de marché, de rédaction de contenu, de scripts vidéo et d’autres tâches variées
  Le fait de « les laisser tourner toute la nuit » est un concept exagéré ; en pratique, ce qui fonctionne, ce sont des objectifs clairs et un périmètre restreint
  Le vrai goulot d’étranglement n’est pas l’exécution, mais la gestion du contexte

  • Approche intéressante. Je serais curieux de savoir quel produit est en cours de développement, et si la recherche basée sur Reddit reste encore pertinente

• Je ne comprends pas vraiment ce que cette personne construit concrètement
  Sur LinkedIn, je ne vois que des posts sur Claude

  • Déployer du code qu’on n’est même pas capable de valider représente un risque sérieux
    Pour une entreprise sérieuse, ce serait impensable
  • En 25 ans de carrière, je n’ai jamais vu une entreprise avoir besoin de code à une telle vitesse
    Au final, le code finit par attendre qu’on trouve comment le vendre

• C’est le même problème que lorsqu’on embauche quelqu’un qui ne fait qu’écrire des tests
  Au final, on ne fait que vérifier que « le code fonctionne comme le code fonctionne »
  Une définition claire des specs est bien plus importante

  • Les tests écrits après coup ne sont le plus souvent qu’une vérification tautologique
    Il est étonnant que les autres disciplines d’ingénierie ne répètent pas cette erreur, alors qu’en logiciel elle reste si répandue
  • La vraie valeur des tests est d’éviter les régressions
    Même si la première version est erronée, ils garantissent qu’ensuite le comportement ne change pas
  • Le but des tests, au fond, c’est surtout la vérification des mocks
  • L’essentiel est de définir d’abord les specs puis de vérifier la conformité par rapport à elles
    Beaucoup de sociétés de conseil travaillent déjà avec une validation fondée sur des critères d’acceptation

• L’IA actuelle n’est plus seulement un outil qui aide au développement, elle est arrivée à un niveau où elle remplace les développeurs
  Le fait que nous ne puissions plus vraiment contrôler ou valider le code est un problème grave
  Cela ressemble moins à une nouvelle manière de développer qu’à une conversion quasi religieuse, où la confiance remplace la compréhension

  • Je ne déploie jamais de code que je ne comprends pas
    Même avec peu d’autonomie, je ne merge que du code vérifiable
  • Ou alors il faut aller vers des outils comme les méthodes formelles (formal methods) pour garantir la sécurité du code