Una migración demasiado grande para un contexto, cortada en piezas que caben.
Un agente que hace una migración entera llena su contexto a mitad de camino y empieza a perder lo que decidió en el primer módulo. Aquí el coordinador escribe las reglas una vez, da cada módulo a su propio ayudante en su propio worktree, fusiona las ramas de vuelta y entrega el resultado a un revisor que no tocó nada de eso.
Gratis y de código abiertoCorre en Mac y LinuxCon tus propias cuentas de Claude y Codex
Grabado en una máquina de demo: los ayudantes informan al coordinador, que luego hace el resumen.
A mitad de una migración, un agente olvida cómo empezó
Los primeros módulos reciben un trabajo cuidadoso. En los últimos, el contexto está lleno de diffs, las decisiones del principio se han compactado y el mismo patrón acaba hecho de tres formas distintas por todo el repo.
Un agente por su cuenta
Un solo contexto con todos los módulos
Las decisiones del principio, perdidas al final
Cada módulo hecho de una forma un poco distinta
Un diff enorme que revisar al final
Agentes lado a lado en Overvibe
Un ayudante por módulo, con un encargo breve
Las reglas escritas una vez y leídas por todos los ayudantes
Una rama por módulo, fusionadas de una en una
Un revisor que lee el resultado fusionado sin ideas previas
Repartir, fusionar y revisar al final
Tú escribes
❯Migra src del cliente de base de datos antiguo al nuevo, un ayudante por módulo en su propio worktree, y luego haz que Codex revise el resultado fusionado.
1El coordinador traza el mapa
Lista los módulos y escribe en MIGRATION.md las reglas que sigue cada ayudante.
2Un ayudante por módulo
Cada uno en su propio worktree bajo el coordinador, con MIGRATION.md y su carpeta como encargo.
3Vuelven las ramas
Cuando un ayudante para, su rama y el comando para fusionarla llegan al coordinador.
4Fusiona y prueba
De rama en rama, con tu suite de tests entre una fusión y otra.
5Una revisión en fresco
Codex lee el diff fusionado contra MIGRATION.md e informa de todo lo que se haya desviado.
Detrás de todo, un ayudante y el revisor. El coordinador ejecuta el primer comando una vez por módulo. Por defecto, una sesión puede llevar 8 hijos a la vez, y Settings > Spawn limits lo cambia. Lee la referencia de la 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>\""
Quédate con un agente si
el cambio cabe en una sentada: un renombrado en un puñado de archivos, las tripas de un módulo, subir una dependencia. Repartir tiene su propio coste. Cada ayudante necesita un encargo, y las ramas que tocan código compartido pueden chocar al fusionarlas.
Preguntas
¿Y el código que comparten todos los módulos?
Cámbialo primero, en el coordinador o en un ayudante, y fusiónalo antes de que empiecen los demás. Si no, cada rama lo cambia un poco y las fusiones se pelean.
¿Pueden los ayudantes ser herramientas distintas?
Sí. Mezcla ayudantes de Claude Code y Codex con --tool; todos leen el mismo MIGRATION.md.
¿Y si un ayudante se atasca?
Cuando te está esperando, su fila se pone en ámbar. El coordinador puede ver su pantalla con overvibe peek y darle el siguiente paso con overvibe send.
