Anthropic a appris à Claude à construire des applications pendant des heures : trois agents et 4 critères

Anthropic a publié une analyse technique sur la façon de construire un harness pour de longues sessions de codage autonomes. Son auteur, Prithvi Rajasekaran, de l'équipe Labs, a passé plusieurs mois sur deux problèmes liés : amener Claude à produire un frontend de haut niveau et lui faire assembler des applications entières sans intervention humaine. Résultat : une architecture à trois agents, planner–generator–evaluator, qui livre des produits full-stack riches au fil de sessions de plusieurs heures. Le principe est emprunté aux réseaux antagonistes génératifs (GAN).

Où les agents seuls atteignent leurs limites

La version précédente du harness reposait sur un agent d'initialisation, qui découpait la spécification en tâches, et sur un agent de codage, qui traitait une fonctionnalité à la fois. Elle a buté sur un plafond, pour deux raisons.

Première raison : sur les tâches longues, le modèle perd en cohérence à mesure que le contexte se remplit. Certains modèles montrent en plus une « anxiété de contexte » : ils bâclent leur travail avant l'heure dès qu'ils sentent la limite approcher. La compaction (résumé sur place de la partie ancienne de la conversation) ne repart pas d'une page blanche, et l'anxiété persiste. Pour Sonnet 4.5, il a donc fallu des resets complets du contexte, avec transmission structurée de l'état. Le prix à payer : une orchestration plus complexe, plus de tokens, une latence plus élevée.

Seconde raison : l'auto-évaluation. Un agent à qui l'on demande de juger son propre travail le salue avec assurance, même quand un humain y voit de la médiocrité. C'est particulièrement visible en design, où il n'existe pas de test binaire comme un test unitaire. Séparer l'« exécutant » du « juge » ne supprime pas complètement l'indulgence : l'évaluateur reste un LLM et favorise les textes écrits par un LLM. Mais régler un évaluateur distinct et sceptique est nettement plus simple que d'apprendre au générateur à se critiquer.

Conception : quatre critères plutôt que « beau »

La question « ce design est-il beau ? » produit des notes instables, alors que « respecte-t-il nos principes de bon design ? » se prête déjà à l'évaluation. Rajasekaran a formulé quatre critères et les a présentés aux deux agents :

• Design quality : cohérence de l'ambiance et de l'identité, et non une simple somme de détails.
• Originality : choix d'auteur assumés plutôt que gabarits, réglages par défaut des bibliothèques et « AI slop », comme les dégradés violets sur cartes blanches.
• Craft : hiérarchie typographique, espacements, contraste. Claude excelle déjà dans ce domaine.
• Functionality : facilité d'usage, indépendamment de l'esthétique.

Les pondérations favorisent la qualité et l'originalité, car c'est là que le modèle produisait des résultats fades. L'évaluateur a été calibré avec des exemples few-shot accompagnés d'une explication des notes, pour éviter que les scores dérivent. La boucle a été construite avec le Claude Agent SDK. L'évaluateur disposait de Playwright MCP : il naviguait lui-même sur la page en ligne, faisait des captures d'écran et rédigeait sa critique. Un run comptait de 5 à 15 itérations et durait jusqu'à quatre heures.

Chose curieuse, la formulation des critères pesait plus que prévu sur le résultat. L'expression « les meilleurs designs de niveau musée » ramenait les travaux vers un style visuel précis. L'amélioration n'était pas strictement linéaire, et l'auteur préférait souvent une itération intermédiaire à la version finale. Dans l'exemple du site d'un musée néerlandais, la neuvième itération donnait une landing page sombre et soignée. À la dixième, le modèle l'a abandonnée pour créer une salle en 3D, avec un sol en damier en CSS perspective, des tableaux aux murs et une navigation par les encadrements de portes.

Trois agents pour le full-stack

Pour le développement d'applications, le QA et la revue de code ont pris le rôle de l'évaluateur de design. Opus 4.5 a en grande partie supprimé l'« anxiété de contexte » : les resets ont donc été retirés. La session se déroule en continu, et la compaction automatique du SDK absorbe la croissance du contexte.

Le planner transforme une requête de 1 à 4 phrases en spécification produit complète. Il a été volontairement cantonné au niveau du produit et de l'architecture de haut niveau : une erreur dans des détails techniques granulaires se propagerait en cascade dans l'implémentation. Le generator travaille par sprints, une fonctionnalité à la fois, avec React, Vite, FastAPI et SQLite (puis PostgreSQL), sous git, et s'auto-vérifie avant de passer la main au QA.

L'evaluator, via Playwright MCP, clique dans l'application lancée comme un utilisateur et vérifie l'UI, l'API et l'état de la base de données. Il évalue les bugs et des critères : profondeur du produit, fonctionnalité, design, qualité du code. Chaque critère a un seuil strict, et l'échec sur un seul d'entre eux fait échouer le sprint.

Avant chaque sprint, le générateur et l'évaluateur conviennent d'un « contrat » : ce qui sera considéré comme terminé, avant même l'écriture du code. C'est un pont entre les user stories de haut niveau et une implémentation vérifiable.

Pour les équipes qui construisent des agents, les enseignements sont concrets. Confiez l'évaluation à un agent distinct et calibrez-le avec des exemples. Traduisez les exigences subjectives en critères explicites et pondérés. À chaque mise à niveau du modèle, vérifiez si vous avez encore besoin d'un appareillage lourd comme les resets de contexte : Opus 4.5 a montré qu'une partie de ces béquilles devient obsolète.