Garder la main sur un agent de code, sans le surveiller en permanence

Déléguer n’est pas abandonner

Deux excès guettent quiconque travaille avec un agent de code. Valider chacune de ses commandes, c’est faire son travail à sa place. Le laisser tout faire seul, c’est découvrir le résultat trop tard. Entre les deux, il existe une poignée de moments où votre avis change vraiment la suite : ce que vous voulez, le plan, le résultat et la livraison.

Treelab place vos décisions à ces moments-là, et seulement là. La page d’accueil publie le nombre minimal de gestes comptés sur un projet de démonstration ; le reste, plans, code, tests, revue et sessions suivantes, l’agent le mène.

Les moments où vous décidez

Le cadrage : vous répondez aux questions de grill-me et confirmez le résumé. C’est là que tout se joue, car un besoin bien cadré évite la plupart des corrections plus tard.

Le plan : avant chaque lot, l’agent propose son plan, avec l’objectif et les critères de fin ; vous l’approuvez ou le corrigez. Rien n’est codé avant votre accord.

L’essai : après le dernier lot, vous essayez le résultat vous-même. C’est la recette : lab acceptance note votre accord, lié à la révision que vous avez essayée ; si le code change ensuite, l’essai est à refaire.

La fermeture : lab close livre et retire le worktree seulement après votre confirmation explicite, qui nomme le worktree. Une commande tapée trop vite ne suffit pas à tout retirer.

$lab next project-1 feature-3LANE_PHASE=in acceptancelab: Work finished — to try together. The lane feature-3 stays open.$lab acceptance project-1 feature-3 --accept --evidence 'dark mode tried on every page'ACCEPTANCE=validPUSH=ok

Ce qui protège le travail entre-temps

Entre vos décisions, l’agent exécute des commandes. Avant chacune, un hook lit ce qu’il s’apprête à faire. Les gestes destructeurs courants sont refusés par défaut : git reset --hard, git clean -f, un push forcé sur une branche protégée, rm -rf hors du worktree, un commit sur la branche principale depuis le checkout principal, un déploiement brut.

Le refus n’est pas un mur : le hook nomme l’alternative sûre, et l’agent continue par là. Vous n’êtes pas dérangé pour un geste qu’il n’aurait pas dû faire.

C’est une liste fermée de gestes courants, pas une sandbox : les autorisations de votre agent restent les vôtres, et ses propres demandes de permission continuent selon vos réglages. La page sécurité détaille ce périmètre.

Exiger des preuves, pas des promesses

« C’est fait » ne suffit pas. Chaque lot se termine par des preuves : la commande lancée, son code de sortie, le résultat et, pour une correction, le test vu en échec avant d’être vert. Elles sont écrites dans la fiche du lot et dans son rapport de preuve, lisibles des semaines plus tard.

Une revue faite par un agent qui n’a pas écrit le code relit le diff contre la fiche. Elle ne juge pas le style : elle cherche ce qui est faux ou hors périmètre. Ses remarques sont corrigées, chacune avec son test, avant la livraison. Et quand un critère ne peut pas être tenu, l’agent le dit dans le journal, avec le motif, au lieu de le masquer.

Les écrans comptent aussi : quand un lot touche une interface, elle est vérifiée dans un vrai navigateur, aux tailles prévues par la fiche, et pas seulement par des tests automatiques.

Suivre sans surveiller

Vous n’avez pas besoin de regarder l’agent travailler. lab plan montre l’avancement de tous vos worktrees ; lab status détaille une branche, un lot, une session ou une demande de fusion. Les deux se recalculent à chaque affichage depuis les fiches. Aucune ne modifie quoi que ce soit : elles lisent seulement les fiches et le dépôt, vous pouvez les lancer aussi souvent que vous voulez, depuis n’importe quel onglet.

Quand une session s’interrompt, rien n’est perdu : la Reprise dit où repartir, et lab next relance l’agent au bon endroit, dans le même onglet.

Quand quelque chose ne va pas, lab doctor contrôle l’installation et le contexte, et dit quoi corriger. lab doctor --report prépare un diagnostic anonymisé, sans rien envoyer : vous choisissez de le partager.

Faire confiance par étapes

La confiance se construit lot après lot. Sur un premier besoin, lisez les fiches, regardez le journal, relisez la revue : vous verrez ce que l’agent prouve et ce qu’il laisse de côté. Ensuite, vous pouvez vous en tenir aux moments de décision et aux preuves.

Quand une preuve manque ou qu’un résultat vous surprend, dites-le à l’essai : un refus note vos retours, et le lot de correction suivant part de là, avec sa propre fiche et ses propres critères de fin.

Le levier le plus direct reste le cadrage : ce qui est précisé au début n’a pas à être corrigé à la fin, ni réexpliqué à chaque nouvelle session.

Ce que la méthode ne fait pas

Elle ne remplace pas votre jugement : un critère de fin mal choisi sera prouvé quand même. Elle ne garantit pas un code sans défaut : les contrôles dépendent de ce que votre dépôt teste. Et elle ne fournit pas l’agent : il faut un accès à Claude Code ou à Codex, choisi pour chaque worktree, sans affiliation de Treelab avec l’un ou l’autre.

Ce qu’elle fait, c’est rendre chaque décision explicite et chaque livraison vérifiable. Pour le découpage en lots, lisez le guide sur la méthode par lots ; pour travailler sur plusieurs besoins à la fois, celui sur les worktrees ; pour le vocabulaire, le glossaire.