Une migration trop grosse pour un seul contexte, découpée en morceaux qui y tiennent.
Un agent seul sur toute une migration remplit son contexte à mi-chemin et commence à oublier ce qu'il a décidé dans le premier module. Ici, le coordinateur écrit les règles une fois, confie chaque module à son propre assistant dans son propre worktree, refusionne les branches et passe le résultat à un relecteur qui n'a touché à rien.
Gratuit et open sourceTourne sur Mac et LinuxVos propres connexions Claude et Codex
Enregistré sur une machine de démo : les assistants rendent compte au coordinateur, qui fait ensuite la synthèse.
À mi-chemin d'une migration, un agent seul oublie comment il a commencé
Les premiers modules ont droit à un travail soigné. Arrivé aux suivants, le contexte est plein de diffs, les décisions du début ont disparu à la compaction, et le même motif se retrouve fait de trois façons différentes dans le dépôt.
Un agent tout seul
Un seul contexte qui porte tous les modules
Les décisions du début perdues en route
Chaque module fait un peu différemment
Un diff énorme à relire à la fin
Des agents côte à côte dans Overvibe
Un assistant par module, avec un brief court
Les règles écrites une fois, lues par chaque assistant
Une branche par module, fusionnée une à la fois
Un relecteur qui lit le résultat fusionné avec un regard neuf
Découper, fusionner et relire à la fin
Vous tapez
❯Migre src de l'ancien client de base de données vers le nouveau, un assistant par module dans son propre worktree, puis fais relire le résultat fusionné par Codex.
1Le coordinateur dresse la carte
Il liste les modules et écrit dans MIGRATION.md les règles que chaque assistant suit.
2Un assistant par module
Chacun dans son propre worktree sous le coordinateur, briefé avec MIGRATION.md et son dossier.
3Les branches reviennent
Quand un assistant s'arrête, sa branche et la commande de fusion arrivent chez le coordinateur.
4Fusionner et tester
Une branche à la fois, en lançant votre suite de tests entre deux fusions.
5Une relecture à froid
Codex lit le diff fusionné au regard de MIGRATION.md et signale tout ce qui a dérivé.
En coulisses, un assistant et le relecteur. Le coordinateur lance la première commande une fois par module. Par défaut, une session peut faire tourner 8 enfants à la fois, ce que Settings > Spawn limits permet de changer. Lire la référence CLI
$ overvibe new --attach --worktree --cwd . --name "db: billing" \
--prompt "Migrate src/billing to the new db client, following MIGRATION.md, and commit. When done, run: overvibe send \"$OVERVIBE_SESSION\" \"<summary>\""
$ overvibe new --attach --tool codex --cwd . --name "db: review" \
--prompt "Review git diff main against MIGRATION.md. Report drift and bugs. Do not edit. When done, run: overvibe send \"$OVERVIBE_SESSION\" \"<review>\""
Restez à un seul agent si
la modification tient en une séance : un renommage sur quelques fichiers, l'intérieur d'un seul module, une montée de version de dépendance. Découper a son propre coût. Chaque assistant a besoin d'un brief, et des branches qui touchent du code partagé peuvent entrer en conflit à la fusion.
Questions
Et le code que tous les modules partagent ?
Modifiez-le d'abord, dans le coordinateur ou dans un assistant, et fusionnez-le avant que les autres commencent. Sinon chaque branche le change un peu et les fusions se battent.
Les assistants peuvent-ils être des outils différents ?
Oui. Mélangez des assistants Claude Code et Codex avec --tool ; ils lisent tous le même MIGRATION.md.
Et si un assistant reste bloqué ?
Quand il vous attend, sa ligne passe en ambre. Le coordinateur peut voir son écran avec overvibe peek et lui donner l'étape suivante avec overvibe send.
D'autres façons de faire travailler les agents à deux
