Conception d’un harness pour développer des applications de longue durée d’exécution

• Anthropic a développé une architecture multi-agents inspirée des GAN afin de résoudre simultanément deux problèmes : améliorer la qualité du design frontend et permettre un codage autonome sur une longue durée
• La structure sépare générateur (generator) et évaluateur (evaluator), ce qui permet de noter une qualité de design subjective à partir de critères concrets et de corriger le biais d’auto-évaluation des agents
• Avec une architecture à 3 agents — planificateur, générateur, évaluateur — l’ensemble parvient à finaliser une application full stack lors de sessions de codage autonomes sur de longues périodes, avec négociation d’un contrat de sprint et QA basée sur Playwright
• Le passage d’Opus 4.5 à Opus 4.6 a rendu possible plus de 2 heures de codage cohérent sans découpage en sprints, réduisant la complexité du harness tout en maintenant les performances
• Même si les performances des modèles progressent, l’espace des combinaisons de harness intéressantes ne se réduit pas : il se déplace ; la tâche centrale des ingénieurs IA consiste à découvrir ces nouvelles combinaisons

---

Pourquoi une implémentation simple atteint ses limites

• Lors d’expériences précédentes, un agent d’initialisation décomposait les spécifications produit en liste de tâches, puis un agent de codage implémentait chaque fonctionnalité une par une, en transmettant le contexte entre sessions via des artefacts
  • Dans la communauté développeur, des approches similaires sont également apparues, à la manière de « Ralph Wiggum », où des hooks ou scripts maintiennent les agents dans une boucle itérative persistante
• Sur les tâches complexes, les agents continuaient néanmoins à dériver de leur trajectoire au fil du temps, avec deux modes d’échec récurrents observés
• Premier mode d’échec : à mesure que la fenêtre de contexte se remplit, le modèle perd en cohérence ; certains modèles manifestent même une forme de « context anxiety » et, lorsqu’ils estiment avoir atteint leur limite de contexte, tendent à conclure prématurément le travail
  • Le context reset (vider entièrement la fenêtre de contexte puis lancer un nouvel agent avec un handoff structuré contenant l’état précédent et les étapes suivantes) résout ces deux problèmes
  • Cette approche diffère de la compaction, où l’on résume les parties précédentes de la conversation pour permettre au même agent de continuer ; la compaction conserve la continuité mais ne fournit pas de page blanche, ce qui peut laisser persister l’anxiété de contexte
  • Avec Claude Sonnet 4.5, cette anxiété de contexte était si marquée que la compaction seule ne suffisait pas à garantir la performance sur des tâches longues ; le context reset est donc devenu un élément central de la conception du harness
• Deuxième mode d’échec : le problème de l’auto-évaluation (self-evaluation) ; lorsqu’un agent évalue son propre résultat, il a tendance à le féliciter avec assurance même si la qualité est manifestement médiocre
  • Le problème est particulièrement grave pour des tâches subjectives comme le design, où il n’existe pas de vérification binaire comparable à un test logiciel vérifiable
  • Séparer l’agent de travail et l’agent d’évaluation est un levier puissant, et il est bien plus facile de régler un évaluateur indépendant pour qu’il soit sceptique que de rendre le générateur réellement autocritique

Design frontend : rendre une qualité subjective mesurable

• Sans intervention, Claude génère par défaut des layouts prudents et prévisibles, techniquement fonctionnels mais visuellement ordinaires
• Deux intuitions clés guident la conception du harness
  • Il est impossible de noter totalement l’esthétique, mais on peut améliorer les résultats grâce à des critères de notation encodant des principes et préférences de design — demander « ce design est-il beau ? » est moins fiable que « respecte-t-il de bons principes de design ? »
  • Séparer génération et notation côté frontend crée une boucle de feedback qui pousse le générateur vers des résultats plus solides
• Les 4 critères de notation fournis au générateur comme à l’évaluateur :
  • Qualité du design (Design quality) : cohérence de l’ensemble formé par couleurs, typographie, layout et images pour produire une ambiance et une identité nettes
  • Originalité (Originality) : présence de choix personnalisés ou, au contraire, recours à des layouts de template, valeurs par défaut de bibliothèques ou motifs typiques de génération IA — une carte blanche sur dégradé violet, par exemple, est considérée comme un signe d’échec
  • Finition (Craft) : hiérarchie typographique, cohérence des espacements, harmonie des couleurs, ratios de contraste, etc. — un contrôle de compétence plus que de créativité
  • Fonctionnalité (Functionality) : l’utilisabilité indépendamment de l’esthétique — l’utilisateur comprend-il ce que fait l’interface et trouve-t-il les actions principales ?
• La qualité du design et l’originalité sont davantage pondérées que la finition et la fonctionnalité — Claude obtenait déjà de bons scores de base sur la finition et la fonctionnalité, mais produisait des résultats banals sur le design et l’originalité
  • Les critères pénalisent explicitement les motifs très génériques de type « AI slop », afin d’encourager le modèle à prendre davantage de risques esthétiques
• L’orchestration a été construite avec le Claude Agent SDK : le générateur produit un frontend HTML/CSS/JS, tandis que l’évaluateur interagit directement avec la page en direct via Playwright MCP, prend des captures d’écran, inspecte minutieusement l’implémentation, puis attribue une note et rédige une critique détaillée
  • 5 à 15 itérations par génération, le générateur répondant à chaque fois à la critique de l’évaluateur pour évoluer vers une direction plus singulière
  • Une exécution complète peut durer jusqu’à 4 heures
  • Après chaque évaluation, le générateur doit prendre une décision stratégique : améliorer la direction actuelle si la tendance des scores est bonne, ou basculer vers une esthétique totalement différente si l’approche ne fonctionne pas
• La formulation des critères a influencé le générateur de façon inattendue : des phrases comme « les meilleurs designs sont de qualité muséale » ont provoqué certaines convergences visuelles, montrant que les prompts associés aux critères façonnent directement le caractère de la production
• Les scores s’amélioraient généralement au fil des itérations, mais pas toujours de façon linéaire ; il arrivait fréquemment que des itérations intermédiaires soient préférées à la dernière
  • La complexité de l’implémentation avait tendance à croître au fil des itérations, le générateur poursuivant des solutions plus ambitieuses en réponse au feedback de l’évaluateur
  • Dès la première itération, les résultats étaient déjà nettement meilleurs que le niveau de base sans prompting ; les critères et leur langage suffisaient à éloigner le modèle de ses choix par défaut trop génériques, même avant le feedback de l’évaluateur
• Cas du site web d’un musée néerlandais : jusqu’à la 9e itération, le système avait produit une landing page dark soignée ; à la 10e, il a abandonné l’approche pour la repenser comme une expérience spatiale avec une pièce 3D rendue en perspective CSS, un sol en damier, des œuvres accrochées librement aux murs et une navigation entre galeries via des portes — un saut créatif du type qu’on n’observe pas dans une génération en un seul passage

Extension au codage full stack

Architecture

• Un précédent harness long-running avait déjà permis de gérer un codage cohérent sur plusieurs sessions grâce à un agent d’initialisation, des agents de codage par fonctionnalité et des context resets entre sessions
  • Avec Sonnet 4.5, le context reset était crucial à cause de l’anxiété de contexte ; mais dans Opus 4.5, ce comportement a été en grande partie supprimé, ce qui a permis d’effectuer tout le build en une seule session continue sans context reset
  • La compaction automatique du Claude Agent SDK prenait en charge la croissance du contexte
• Le système est organisé en 3 agents :
  • Planner : transforme un prompt court de 1 à 4 phrases en spécification produit complète — le prompting l’oriente vers le contexte produit et l’architecture technique de haut niveau plutôt que vers les détails d’implémentation, pour éviter que des choix techniques prématurés ne propagent des erreurs en aval
    • Il reçoit aussi pour consigne de repérer des occasions de tisser (weave) des fonctionnalités IA dans la spécification produit
  • Generator : prélève une fonctionnalité à la fois dans la spécification, sprint par sprint, puis l’implémente avec une stack React/Vite/FastAPI/SQLite (puis PostgreSQL), procède à une auto-évaluation en fin de sprint avant handoff vers la QA, et versionne le travail avec git
  • Evaluator : utilise Playwright MCP pour cliquer dans l’application en cours d’exécution comme un véritable utilisateur, tester les fonctionnalités UI, les endpoints API et l’état de la base de données — il note la profondeur produit, la fonctionnalité, le design visuel et la qualité du code, avec des seuils minimaux stricts par critère ; si un seuil n’est pas atteint, le sprint échoue
• Avant chaque sprint, le générateur et l’évaluateur négocient un contrat de sprint (sprint contract) — ils s’accordent sur la définition de « terminé » pour ce bloc de travail avant l’écriture du code
  • Comme la spécification produit restait volontairement de haut niveau, cette étape permettait de combler l’écart entre user stories et implémentation testable
  • La communication était basée sur des fichiers — un agent écrit un fichier, l’autre le lit puis répond

Résultats d’exécution du harness : créateur de jeux rétro

• Test effectué avec le prompt : « Crée un créateur de jeux rétro 2D avec éditeur de niveaux, éditeur de sprites, comportements d’entités et mode de test jouable »
• Agent solo : 20 minutes / 9 $ vs harness complet : 6 heures / 200 $ — le harness coûtait plus de 20 fois plus cher, mais la différence de qualité du résultat était immédiatement évidente
• Résultat en solo : l’écran initial était conforme aux attentes, mais les problèmes apparaissaient dès qu’on cliquait — layout gaspillant l’espace, workflow rigide, nécessité de créer d’abord sprites et entités sans que l’UI ne le guide, et surtout le vrai jeu ne fonctionnait pas (les entités apparaissaient à l’écran mais ne répondaient pas aux entrées, la connexion entre définition des entités et runtime du jeu étant rompue)
• Résultat avec harness : le planner a développé un prompt d’une phrase en 16 spécifications de fonctionnalités sur 10 sprints — avec notamment système d’animation de sprites, templates de comportements, effets sonores et musique, générateur de sprites assisté par IA, level designer assisté par IA, et export des jeux via lien partageable
  • En s’appuyant sur les capacités de design frontend, il a également généré le langage visuel de design de l’application comme partie intégrante de la spécification
  • Le canvas exploitait tout le viewport, les tailles de panneaux étaient raisonnables et l’identité visuelle restait cohérente avec la direction de design définie dans la spécification
  • L’éditeur de sprites était plus riche et plus complet, avec une palette d’outils plus propre, un meilleur sélecteur de couleurs et des contrôles de zoom plus utilisables
  • L’intégration de l’IA accélérait le workflow en générant différentes parties du jeu à partir de prompts
• Différence clé en mode jeu : l’exécution solo ne produisait pas un jeu fonctionnel, alors qu’avec le harness il était réellement possible de déplacer les entités et de jouer — malgré quelques aspérités dans le moteur physique (chevauchement plateforme/personnage) et des limites dans la composition de niveaux par IA (grands murs infranchissables), la fonctionnalité essentielle était bien présente
• L’évaluateur maintenait l’implémentation alignée sur la spécification — dès le Sprint 3, le contrat du level editor couvrait déjà 27 critères détaillés
  • Exemples de problèmes détectés : l’outil de remplissage rectangulaire ne plaçait des tuiles qu’aux points de début et de fin du glisser-déposer, erreur de condition dans le gestionnaire de touche de suppression d’entité, problème d’ordre des routes FastAPI provoquant l’analyse de reorder comme entier et un retour d’erreur 422
• Le réglage de l’évaluateur a demandé un effort considérable — à l’état brut, Claude est un mauvais agent QA : même lorsqu’il détecte un vrai problème, il a tendance à se convaincre lui-même que « ce n’est pas si grave » et à valider malgré tout, tandis que des tests superficiels lui font manquer des bugs subtils
  • Il a fallu répéter plusieurs fois la boucle de développement consistant à lire les logs de l’évaluateur, repérer les cas où son jugement divergeait de l’attendu, puis mettre à jour le prompt QA avant d’obtenir une notation raisonnable

Amélioration itérative du harness

• Les premiers résultats étaient encourageants, mais le système restait gros, lent et coûteux ; l’étape suivante consistait donc à simplifier le harness sans perte de performance
  • Chaque composant du harness encode une hypothèse sur ce que le modèle ne peut pas faire seul, et ces hypothèses méritent d’être stress-testées — car elles peuvent devenir rapidement obsolètes à mesure que le modèle progresse
  • Principe retenu : « chercher la solution la plus simple possible, puis n’augmenter la complexité qu’en cas de besoin »
• Les tentatives de simplification radicale n’ont pas permis de reproduire les performances d’origine, et comme il était difficile d’identifier les pièces réellement porteuses, l’équipe a opté pour une approche systématique consistant à retirer un composant à la fois
• La sortie d’Opus 4.6 a fourni une motivation supplémentaire pour réduire la complexité du harness : meilleure planification, maintien plus long sur les tâches agentiques, fonctionnement plus stable sur de grosses codebases, meilleures compétences en code review/debugging pour détecter ses propres erreurs, et amélioration majeure de la récupération dans les longs contextes

Suppression de la structure en sprints

• La structure en sprints a été complètement supprimée — avec les capacités renforcées d’Opus 4.6, le modèle pouvait traiter le travail de manière cohérente sans décomposition
• Le planner et l’évaluateur ont été conservés — sans planner, le générateur manque de portée, lance un build à partir d’un prompt brut sans véritable spécification et produit des applications moins riches en fonctionnalités
• L’évaluateur est passé d’une notation par sprint à un passage unique en fin d’exécution
  • Lorsque la tâche entre dans le champ de capacité autonome du modèle, l’évaluateur devient un surcoût inutile ; mais sur les tâches à la frontière des capacités du modèle, il apporte encore une amélioration tangible
  • L’évaluateur n’est donc pas une réponse fixe oui/non : son coût se justifie surtout lorsque l’on dépasse ce que le modèle actuel peut exécuter seul de manière fiable
• Des prompts ont aussi été ajoutés pour améliorer la construction de fonctionnalités IA — il a fallu beaucoup d’itérations pour amener le générateur à construire des agents appropriés, pilotés via des outils, pour les fonctionnalités de l’application elle-même, un domaine encore récent et donc peu couvert dans les données d’entraînement de Claude

Résultats du harness mis à jour : DAW dans le navigateur

• Test réalisé avec le prompt : « Construis dans le navigateur une DAW complète à l’aide de la Web Audio API »
• Coût total : environ 4 heures et 124,70 $
  • Planner : 4,7 min / 0,46 $ ; Build round 1 : 2 h 7 min / 71,08 $ ; QA round 1 : 8,8 min / 3,24 $ ; Build round 2 : 1 h 2 min / 36,89 $ ; QA round 2 : 6,8 min / 3,09 $ ; Build round 3 : 10,9 min / 5,88 $ ; QA round 3 : 9,6 min / 4,06 $
• Le builder a fonctionné de façon cohérente pendant plus de 2 heures sans décomposition en sprints
• Premier retour de l’agent QA : bonne fidélité du design, bons agents IA et bon backend, mais la complétude fonctionnelle constituait le principal point d’échec — impossible de faire glisser/déplacer des clips dans la timeline, absence de panneau UI d’instruments (potards de synthé, pads de batterie), absence d’éditeur visuel d’effets (courbe d’EQ, indicateurs de compresseur)
• Deuxième retour QA : enregistrement audio encore à l’état de stub, redimensionnement et découpe des clips non implémentés, visualisation des effets réduite à des sliders numériques plutôt qu’à de vrais graphismes
• Application finale : encore loin d’un logiciel professionnel de production musicale et nécessitant une amélioration des capacités de composition des agents, d’autant que Claude ne peut pas réellement entendre le son, ce qui rend la boucle de QA moins efficace sur le plan du goût musical
  • Elle dispose néanmoins des éléments centraux d’un logiciel de création musicale fonctionnel, avec arrangement view, mixer et transport opérationnels
  • Il était possible de produire de courts extraits musicaux par simple prompting — l’agent définissait le tempo et la tonalité, plaçait une mélodie, créait une piste de batterie, ajustait les niveaux du mixer et ajoutait de la réverbération

Perspectives

• À mesure que les modèles progressent, on peut s’attendre à ce qu’ils prennent en charge des tâches plus longues et plus complexes ; dans certains cas, l’importance du scaffold autour du modèle diminuera, si bien qu’attendre la génération suivante pourra suffire à résoudre naturellement certains problèmes
• Mais à l’inverse, plus les modèles s’améliorent, plus l’espace de conception des harness capables d’aller au-delà du niveau de base s’élargit
• Enseignements clés :
  • Expérimenter avec le modèle cible, lire les traces sur des problèmes réels et ajuster les performances en fonction du résultat souhaité reste toujours une bonne pratique
  • Pour des tâches plus complexes, décomposer le travail et appliquer des agents spécialisés à chaque aspect permet de dégager plus de marge
  • À chaque sortie d’un nouveau modèle, il est utile de réexaminer le harness afin de supprimer les parties qui ne portent plus réellement la performance et d’en ajouter de nouvelles pour atteindre des capacités plus vastes jusque-là impossibles
• Même si les modèles progressent, l’espace des combinaisons de harness intéressantes ne se réduit pas : il se déplace, et le défi des ingénieurs IA est de continuer à découvrir les nouvelles combinaisons suivantes