O migrare prea mare pentru un singur context, tăiată în bucăți care încap.
Un singur agent care face o migrare întreagă își umple contextul la jumătatea drumului și începe să piardă ce a decis la primul modul. Aici coordinatorul scrie regulile o dată, dă fiecare modul unui ajutor separat în propriul worktree, face merge la branch-uri și îi predă rezultatul unui reviewer care n-a atins nimic din el.
Gratuit și open sourceRulează pe Mac și LinuxCu propriile tale loginuri Claude și Codex
Înregistrat pe un calculator demo: ajutoarele raportează coordinatorului, care apoi face rezumatul.
La jumătatea unei migrări, un agent uită cum a început
Primele module sunt lucrate cu grijă. La ultimele, contextul e plin de diff-uri, deciziile de la început au dispărut la compactare, iar același tipar ajunge făcut în trei feluri diferite prin repo.
Un agent de unul singur
Un singur context care ține toate modulele
Deciziile de la început, pierdute până la final
Fiecare modul făcut puțin altfel
Un diff uriaș de verificat la final
Agenți unul lângă altul în Overvibe
Câte un ajutor pe modul, cu un brief scurt
Regulile scrise o dată, citite de fiecare ajutor
Un branch pe modul, cu merge pe rând
Un reviewer care citește cu ochi proaspeți rezultatul final
Împarți, faci mergeși review la final
Tu scrii
❯Mută src de pe vechiul client de db pe cel nou, câte un ajutor pe modul în worktree-ul lui, apoi pune-l pe Codex să verifice rezultatul după merge.
1Coordinatorul face harta
Listează modulele și scrie în MIGRATION.md regulile pe care le urmează fiecare ajutor.
2Câte un ajutor pe modul
Fiecare în propriul worktree sub coordinator, cu MIGRATION.md și folderul lui ca brief.
3Branch-urile se întorc
Când un ajutor se oprește, branch-ul lui și comanda de merge ajung la coordinator.
4Merge și teste
Câte un branch pe rând, cu suita de teste rulată între merge-uri.
5Un review proaspăt
Codex citește diff-ul final cu MIGRATION.md alături și raportează orice s-a abătut de la reguli.
În culise, un ajutor și reviewerul. Coordinatorul rulează prima comandă o dată pentru fiecare modul. Implicit, o sesiune poate rula 8 copii deodată, iar Settings > Spawn limits schimbă asta. Citește referința 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>\""
Rămâi la un singur agent dacă
modificarea se face dintr-o bucată: o redenumire în câteva fișiere, interiorul unui singur modul, un update de dependență. Împărțirea are costul ei. Fiecare ajutor are nevoie de un brief, iar branch-urile care ating cod comun pot intra în conflict la merge.
Întrebări
Ce faci cu codul folosit de toate modulele?
Schimbă-l primul, în coordinator sau într-un ajutor, și fă-i merge înainte să pornească celelalte. Altfel fiecare branch îl schimbă puțin, iar merge-urile se bat între ele.
Pot ajutoarele să fie tool-uri diferite?
Da. Amestecă ajutoare Claude Code și Codex cu --tool. Toate citesc același MIGRATION.md.
Și dacă un ajutor se blochează?
Când te așteaptă pe tine, rândul lui se face chihlimbariu. Coordinatorul îi poate vedea ecranul cu overvibe peek și îi poate da următorul pas cu overvibe send.
