Sessions parallèles et sous-agents

Un seul ingénieur peut piloter plusieurs flux de travail à la fois.

Une session parallèle est une autre instance complète de Claude Code, travaillant sur une tâche distincte dans son propre worktree Git. Chaque session indépendante ne sait rien des autres, et l'ingénieur qui les pilote est la seule chose qu'elles ont en commun.

Un sous-agent s'exécute à l'intérieur d'une seule session en tant qu'assistant ciblé disposant de sa propre fenêtre de contexte et de ses propres limites d'outils, et convient aux tâches qui reviennent dans plusieurs missions, comme vérifier que l'application fonctionne comme prévu.

Les sessions parallèles augmentent le nombre de tâches qu'un ingénieur peut mener de front, tandis que les sous-agents permettent à chaque session de rester concentrée sur sa propre tâche. Le travail de l'ingénieur consiste à piloter et à relire l'ensemble.

Ce qui change

Pour commencer

• Prérequis : Le fichier CLAUDE.md, puisque toutes les sessions le lisent. La boucle de rétroaction (Étape 4 : Tester) aide également ici, car une session capable de vérifier son propre travail nécessite moins de supervision de la part de l'ingénieur.
• Infrastructure : Un dépôt Git, puisque l'isolation provient des worktrees, ainsi que des paramètres de permissions ajustés pour que les sessions n'attendent pas d'invites d'approbation pour des commandes que l'organisation considère comme sûres.

Comment l'exécuter

1. L'ingénieur divise le travail en tâches qui touchent des fichiers différents, en utilisant le plan issu de l'exercice du mode plan (Étape 3 : Construire) pour repérer où le travail est indépendant. Les tâches qui partagent des fichiers s'exécutent dans une seule session, l'une après l'autre.
2. Chaque tâche parallèle obtient son propre worktree, par exemple claude --worktree feature-auth dans un terminal et claude --worktree fix-rate-limit dans un autre. Un worktree est un checkout distinct sur sa propre branche, ce qui empêche les sessions d'entrer en collision sur les fichiers.
3. Deux ou trois sessions constituent un point de départ raisonnable. Le plafond pratique dépend du nombre de flux qu'une seule personne peut relire correctement, donc n'ajoutez des sessions que tant que la relecture suit le rythme.
4. Transformez les tâches répétitives en sous-agents, définis dans des fichiers Markdown dans .claude/agents/, chacun avec un nom, une description du moment où l'utiliser, et les outils auxquels il peut accéder. Parmi les exemples figurent un simplificateur de code qui élimine la complexité inutile une fois l'agent principal terminé, un vérificateur qui exécute l'application et vérifie son comportement, et un chercheur qui explore la base de code et rend compte sans saturer le contexte principal. Versionnez les définitions dans Git afin que toute l'équipe les partage.

À quoi cela ressemble

.claude/agents/verifier.md :

---

name: verifier
description: Runs the app and checks the change works before the session reports done
tools: Bash, Read

---
Start the app with make run. Exercise the changed behavior and the two
nearest neighboring flows. Report what you ran, what you saw, and any
behavior that does not match plan.md. Do not fix anything; report only.

Considérations de gouvernance

Plus de sessions signifie plus de production, donc les contrôles doivent provenir de la configuration dans le dépôt. Les hooks et les paramètres de permissions qui s'y trouvent s'appliquent à toutes les sessions, et ce qu'une session fait est journalisé et attribué à l'ingénieur qui l'a exécutée.

Comment le mesurer

• Indicateur avancé : Sessions simultanées par ingénieur tant que la qualité de la relecture se maintient, comptées à partir de l'export OpenTelemetry, et la part de la journée passée à piloter plutôt qu'à attendre.
• Indicateur retardé : Modifications fusionnées par ingénieur par semaine, lues conjointement avec le taux de retouche déterminé à partir de l'historique des PR.