Anthropic montre comment faire coder Claude pendant des jours : une liste de 200+ tâches en JSON

Anthropic a publié une analyse d'ingénierie sur la manière de maintenir en état de marche des agents basés sur Claude Agent SDK à travers de nombreuses fenêtres de contexte. Point de départ : même Opus 4.5, lancé en boucle avec un seul prompt de haut niveau du type « construis un clone de claude.ai », n'amène pas l'application web à une qualité production. La compaction du contexte aide, mais ne règle pas le problème. L'auteur du texte, Justin Young, propose un schéma à deux rôles, avec un historique git et un fichier de progression. Il s'inspire du fonctionnement d'ingénieurs qui se passent le relais de poste en poste, sans aucun souvenir personnel de l'équipe précédente.

Où les agents longue durée déraillent

Anthropic a observé trois défaillances récurrentes. Première : l'agent tente de tout faire d'un seul coup, atteint la limite de contexte en pleine implémentation et laisse à la session suivante une fonction à moitié terminée et non documentée. Son successeur doit deviner ce qui s'est passé et perdre du temps à rétablir un fonctionnement de base. La compaction n'y remédie pas, car elle ne transmet pas toujours des instructions claires.

La deuxième défaillance apparaît plutôt vers le milieu du projet. Une nouvelle instance de l'agent regarde autour d'elle, constate que beaucoup de choses sont déjà construites et déclare le travail terminé. La troisième concerne la vérification : Claude marque une fonctionnalité comme achevée après des tests unitaires ou des requêtes curl sur le serveur de développement, alors que le scénario de bout en bout ne fonctionne pas dans le navigateur.

Comment fonctionne le harnais

La première session reçoit un prompt distinct et joue le rôle d'initialiseur. Le prompt système, l'ensemble d'outils et l'infrastructure sont identiques pour les deux « agents » ; seul le message utilisateur de départ diffère. L'initialiseur crée un script init.sh pour lancer le serveur de développement, un fichier claude-progress.txt qui tient le journal des actions, et un premier commit git. Surtout, il rédige la liste des exigences. Pour le clone de claude.ai, elle comptait plus de 200 éléments, par exemple « l'utilisateur ouvre un nouveau chat, saisit une requête, appuie sur Entrée et voit la réponse de l'IA ». Tous les éléments sont marqués au départ comme échoués.

Paramètres clés du schéma :

• Format de la liste de fonctionnalités : JSON avec les champs category, description, steps et passes. Le modèle réécrivait nettement plus souvent le Markdown.
• Droits de l'agent de codage : il ne peut modifier que le champ passes. La formulation du prompt est stricte : il est inacceptable de supprimer ou de modifier les tests.
• Volume de travail : une fonctionnalité par itération.
• Fin de session : un commit git avec un message descriptif et une entrée dans le fichier de progression, ce qui permet d'annuler les modifications ratées.
• Début de session : pwd, lecture du git log et du fichier de progression, choix de la fonctionnalité inachevée de plus haute priorité, lancement d'init.sh et test de base de bout en bout.

Tests et limites de l'approche

La vérification de départ est simple : l'agent démarre le serveur, ouvre un nouveau chat via Puppeteer MCP, envoie un message et attend la réponse. Si l'application est cassée, le bug est corrigé avant de commencer un nouveau travail, faute de quoi la fonctionnalité suivante ne ferait qu'aggraver la situation. Quand on demande explicitement au modèle de tester via l'automatisation du navigateur, comme le ferait un humain, il trouve des erreurs invisibles dans le code, et la qualité du résultat augmente nettement, selon Anthropic. Cela économise aussi des tokens : l'agent n'a pas besoin de redécouvrir à chaque fois comment lancer et vérifier l'application.

Des limites subsistent. Via Puppeteer MCP, Claude ne voit pas les fenêtres modales natives du navigateur comme alert ; les fonctions qui en dépendent se sont donc révélées plus instables. Par ailleurs, la vision du modèle et les capacités des outils ne permettent pas de détecter toutes les classes d'erreurs.

Ce qu'il faut retenir pour votre projet

Le minimum pratique peut être transposé dès maintenant dans n'importe quel pipeline d'agents. Prévoyez un prompt de démarrage distinct pour préparer l'environnement. Stockez les exigences dans un fichier lisible par machine avec un statut booléen, et interdisez à l'agent d'en modifier les formulations. Exigez un commit et une entrée dans le journal à la fin de chaque session. Commencez chaque session par un git log et un bref passage de l'application. Ajoutez des outils d'automatisation du navigateur si vous testez du web.

Deux questions restent ouvertes. On ignore encore si un seul agent de codage polyvalent fait mieux qu'un ensemble d'agents spécialisés : testeur, QA, agent de nettoyage du code. De plus, les résultats ont été obtenus sur du développement web full-stack, et Anthropic se contente de supposer qu'une partie des enseignements s'appliquera à la recherche scientifique ou à la modélisation financière. C'est une hypothèse, pas un résultat mesuré.