Claude Code : une session vérifie, les autres codent

Ce qui se passe

asyncdot publie la méthode qu'il applique pour mener avec Claude Code des chantiers de plusieurs heures. Le constat de départ : une session unique fonctionne une heure, puis se dégrade, pour trois raisons.

1. Le contexte est compacté, et le résumé perd les détails qui comptaient.
2. Quand un agent annonce « les tests passent », il rapporte son intention et son souvenir, pas une observation fraîche. L'écart grandit avec la durée.
3. Rien ne s'accumule : ce qui a été appris à la deuxième heure disparaît avec la session, faute d'avoir été écrit quelque part.

Ajouter des agents multiplie ces défauts au lieu de les corriger.

Le schéma

Une session coordinatrice, longue, qui n'implémente rien ; des sessions d'exécution, courtes, qui font le travail. L'auteur l'appelle Chief of Staff, mais reconnaît un schéma établi : orchestrateur et ouvriers, coordinateur-implémenteur-vérificateur, maker-checker, ou l'integration manager des workflows Git distribués.

Le coordinateur tire la tâche suivante, rédige une consigne qu'un modèle moins capable pourrait suivre, vérifie, lit les diffs plutôt que les transcriptions et consigne les leçons. S'il se met à coder, il cesse de vérifier.

L'état vit hors du contexte, dans un tableau de tâches accessible par API ou MCP, qui survit à la compaction et à la mort d'une session. L'auteur utilise son propre produit, Plan Desk ; tout gestionnaire de tâches doté d'une API tient le rôle. Les sessions tournent dans des espaces de terminal pilotés par cmux.

La boucle

1. Tirer la prochaine tâche débloquée.
2. Lire le document de conception qui lui est lié.
3. Lancer d'abord la vérification : elle doit échouer. Un contrôle déjà vert ne prouve rien, et signale souvent une tâche déjà faite ailleurs.
4. Déléguer à une session d'exécution.
5. Relancer chaque commande annoncée : le code de sortie fait foi.
6. Relire le diff, morceau par morceau.
7. Trancher, en écrivant pourquoi.
8. Mettre à jour le statut et committer cette tâche seule.

Les pièges nommés

• Le contrôle qui annonce un succès pour un travail non fait : assertion vide, grep qui ne trouve rien et se lit comme « propre », commande qui n'a jamais tourné. Avant de croire à une absence, vérifier que l'outil sait trouver un cas présent.
• Vérifier la variable au lieu de l'artefact : relire la valeur dans le fichier écrit, pas dans le shell qui l'a écrit.
• --command de cmux tape du texte dans un shell, il ne démarre pas d'agent : appeler claude explicitement, avec un prompt court qui pointe vers une consigne commitée.
• Les messages entre sessions peuvent se perdre ou attendre une approbation : ce qui doit arriver passe par un fichier commité ou une carte du tableau.
• Dans un arbre de travail partagé, un git commit nu embarque tout l'index, y compris ce qu'une autre session a indexé. Nommer les chemins :

git commit -m "PLAN-42 : validation du formulaire" -- src/Form/ContactType.php

Quand s'en passer

Pour une modification bien délimitée, une seule session suffit. La vérification consomme des jetons sans produire de code : c'est le prix payé pour pouvoir croire le résultat.

Pour démarrer

Un tableau durable ; un fichier de règles commité, lu par chaque session au démarrage ; un coordinateur et un exécutant, pas six ; un fichier de passation mis à jour à la fin de chaque session ; un journal des leçons.

Source : le pattern Chief of Staff pour orchestrer des sessions Claude Code, asyncdot. Repéré via Human Coders News, 26 septembre 2026.