Eine Migration, zu groß für einen Kontext, in Stücke geschnitten, die hineinpassen.
Ein Agent, der eine ganze Migration allein macht, hat seinen Kontext auf halber Strecke voll und verliert dann, was er im ersten Modul entschieden hat. Hier schreibt der Koordinator die Regeln einmal auf, gibt jedes Modul einem eigenen Helfer in einem eigenen Worktree, führt die Branches wieder zusammen und übergibt das Ergebnis einem Prüfer, der nichts davon angefasst hat.
Kostenlos und Open SourceLäuft auf Mac und LinuxDeine eigenen Logins für Claude und Codex
Aufgenommen auf einem Demo-Rechner: Helfer melden sich beim Koordinator zurück, der dann zusammenfasst.
Mitten in einer Migration vergisst ein einzelner Agent, wie er angefangen hat
Die ersten Module bekommen sorgfältige Arbeit. Bei den späteren ist der Kontext voller Diffs, die frühen Entscheidungen sind wegkomprimiert, und dasselbe Muster wird im Repo auf drei verschiedene Arten umgesetzt.
Ein Agent für sich allein
Ein Kontext, der jedes Modul halten muss
Frühe Entscheidungen sind am Ende weg
Jedes Modul ein bisschen anders gemacht
Ein riesiger Diff zum Prüfen am Schluss
Agenten nebeneinander in Overvibe
Ein Helfer pro Modul, mit einem kurzen Briefing
Die Regeln einmal aufgeschrieben, von jedem Helfer gelesen
Ein Branch pro Modul, einer nach dem anderen gemergt
Ein Prüfer, der das gemergte Ergebnis frisch liest
Aufteilen, mergenund am Ende prüfen
Du tippst
❯Stell src vom alten db-Client auf den neuen um, ein Helfer pro Modul in seinem eigenen Worktree, und lass Codex danach das gemergte Ergebnis prüfen.
1Der Koordinator plant es durch
Er listet die Module auf und schreibt die Regeln, denen jeder Helfer folgt, in MIGRATION.md.
2Ein Helfer pro Modul
Jeder in seinem eigenen Worktree unter dem Koordinator, gebrieft mit MIGRATION.md und seinem Ordner.
3Branches kommen zurück
Wenn ein Helfer stoppt, kommen sein Branch und der Merge-Befehl beim Koordinator an.
4Mergen und testen
Ein Branch nach dem anderen, mit deiner Testsuite zwischen den Merges.
5Ein frisches Review
Codex liest den gemergten Diff gegen MIGRATION.md und meldet alles, was davon abweicht.
Dahinter stecken ein Helfer und der Prüfer. Der Koordinator führt den ersten Befehl einmal pro Modul aus. Standardmäßig kann eine Session 8 Kinder gleichzeitig laufen lassen, und unter Settings > Spawn limits änderst du das. Zur CLI-Referenz
$ 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>\""
Bleib bei einem Agenten, wenn
die Änderung in einen Rutsch passt: eine Umbenennung über eine Handvoll Dateien, das Innenleben eines Moduls, ein Dependency-Update. Aufteilen hat seinen eigenen Preis. Jeder Helfer braucht ein Briefing, und Branches, die gemeinsamen Code berühren, können beim Mergen kollidieren.
Fragen
Was ist mit Code, den alle Module teilen?
Ändere ihn zuerst, im Koordinator oder in einem Helfer, und merge ihn, bevor die anderen anfangen. Sonst ändert ihn jeder Branch ein bisschen, und die Merges geraten sich in die Haare.
Können Helfer verschiedene Tools sein?
Ja. Misch Helfer von Claude Code und Codex mit --tool. Alle lesen dieselbe MIGRATION.md.
Was, wenn ein Helfer hängen bleibt?
Wartet er auf dich, wird seine Zeile bernsteinfarben. Der Koordinator kann mit overvibe peek seinen Bildschirm sehen und ihm mit overvibe send den nächsten Schritt geben.
