Programación y vibe coding
Trabajar con varios agentes de código sin que se pisen: «hecho cuando», revisor y worktrees
Cada tarea empieza con una lista «hecho cuando» que un programa puede comprobar. Un agente reparte trozos acotados, cada uno en su git worktree. Un revisor compara cada informe con la lista y la revisión crece cuanto más difícil es deshacer el cambio. Método de @tracheopteryx, sin prueba propia.
| Herramientas | Claude Code (principal)OpenClaw |
|---|---|
| Qué necesitas |
|
| Coste aprox. | Sin dato. El autor no publica cuánto paga por los modelos ni por su equipo. git worktree es parte de git y no cuesta nada aparte; el coste real es el de los agentes que lances en paralelo. |
| Tiempo de montaje | 90 min (primera vez) |
| Nivel | Avanzada |
| Plan gratis | Suele requerir plan de pago |
Prompt listo para usar
Vamos a repartir la tarea [TAREA] del repositorio [REPO] entre varios agentes. 1. Antes de dividir nada, escribe la lista «hecho cuando»: condiciones que se puedan comprobar con [COMPROBACION]. 2. Divide el trabajo en trozos que no toquen los mismos ficheros. Para cada trozo indica qué ficheros puede tocar, su rama y su carpeta de git worktree. 3. Cuando vuelva un trozo, compara su informe con la lista y ejecuta las comprobaciones de verdad. No te fíes solo del informe. 4. Si un trozo no avanza en dos intentos, para y propón otro plan en vez de reintentar. 5. Clasifica cada cambio por lo difícil que es deshacerlo. Lo rutinario puede ir a PR con CI en verde. Lo que toque [ZONA SENSIBLE] espera mi revisión. No hagas merge a la rama principal ni push forzado.
| Variable | Qué poner | Ejemplo |
|---|---|---|
[TAREA] | El trabajo que quieres repartir | añadir exportación a CSV en el panel de informes |
[REPO] | Nombre o ruta del repositorio | panel-clientes |
[COMPROBACION] | Comando que valida el trabajo | npm test y npm run build |
[ZONA SENSIBLE] | Lo que nunca entra sin revisión humana | pagos, autenticación y migraciones de base de datos |
Pégalo en: Claude Code, Cursor
Prompt propio, resumido del flujo publicado. El autor no comparte su texto. Funciona mejor si el agente puede ejecutar git y los tests en tu máquina.
Cómo funciona
- Escribe primero la lista «hecho cuando». Antes de repartir, cada tarea lleva una lista de condiciones que un programa puede comprobar: tests que pasan, un build limpio, un endpoint que responde. Sin esa lista no hay forma de saber si un agente ha terminado o solo dice que ha terminado.
- Reparte trozos acotados. El agente principal divide el trabajo y entrega piezas pequeñas a otros agentes o subagentes. El autor usa Claude Code como principal y manda trozos a Codex, a DeepSeek o a subagentes. La clave es que cada trozo tenga límites claros de ficheros.
- Un git worktree por agente. Cada agente trabaja en su propio git worktree: una carpeta aparte con su rama, sobre el mismo repositorio. Se crea con git worktree add y una ruta nueva. Así dos agentes no editan la misma copia de los ficheros, y cada trozo vuelve como una rama que se revisa sola.
- Compara cada informe con la lista. Cuando un agente termina, un modelo rápido compara su informe con la lista «hecho cuando» y señala qué revisar primero. El autor insiste en que las comprobaciones de verdad se ejecutan igualmente: el revisor orienta, no aprueba.
- Corta los bucles que no avanzan. Si un bucle no progresa tras dos intentos, se para y se replantea el plan en lugar de reintentar lo mismo. Evita que un agente gaste tiempo y cupo dando vueltas sobre un error que viene del planteamiento.
- Revisa según lo difícil que sea deshacer. Los cambios rutinarios se fusionan cuando la CI pasa. Los críticos esperan una revisión independiente. Los sistemas en producción siguen un protocolo escrito. Todo cambio pasa por un pull request con CI.
- Convierte cada incidente en un check. Cada fallo real se convierte en una comprobación automática pequeña, para que no se repita. Una retrospectiva semanal lee las sesiones de la semana y los guardados del autor y propone cambios al sistema.
Qué resultado esperar
Varios trozos de una tarea que vuelven como ramas separadas, cada uno contrastado con la misma lista «hecho cuando» y con un nivel de revisión acorde al riesgo. No hay cifra de tiempo ahorrado: el autor no la publica.
- Qué se hizo
- @tracheopteryx, que dice trabajar casi a diario con agentes desde febrero, publicó en X su configuración completa: modelos, herramientas y, sobre todo, cómo fluye el trabajo entre agentes de código.
- Cómo fue
- Claude Code es su agente principal y llama a otros: Codex para revisiones independientes y trabajos largos, DeepSeek para encargos pequeños en un entorno aislado y un modelo rápido para decisiones de sí o no. Cada trozo va en su git worktree y todo cambio pasa por PR y CI.
- A tener en cuenta
- No publica métricas ni el texto de sus instrucciones. Parte del post promociona un producto suyo, que aquí no se trata. Sin prueba propia todavía.
Límites y precauciones
- Es el sistema de una persona que trabaja a tiempo completo con agentes desde febrero, según él. No hay métricas de resultados ni repositorio con la configuración.
- Los worktrees evitan que dos agentes editen la misma copia, pero no los conflictos al juntar ramas que tocan lo mismo. Por eso el reparto debe separar ficheros.
- El post nombra modelos y herramientas concretos que cambian rápido. Lo que se copia aquí es el método, no la lista de productos.
- Parte del post promociona un producto del autor. Esta ficha no lo trata.
- Sin prueba propia todavía.
- No dejes que los agentes fusionen en la rama principal lo que toque pagos, autenticación o datos. Esa parte espera revisión humana.
- Varios agentes en paralelo multiplican el gasto de cupo o de API. Empieza con dos.
- El post tenía poca difusión al leerlo el 17 oct 2026 (unas 2.200 visualizaciones y 56 respuestas). Es un método de un practicante, no un estándar.
Variantes
- cursor: El mismo reparto sirve con agentes de Cursor si cada uno trabaja en su rama y su PR. El post no menciona Cursor; esta variante es una adaptación de la ficha.
- openclaw: El autor tiene un asistente con OpenClaw en un servidor casero que corre compilaciones y agentes mientras él no está, y al que escribe desde el móvil.
Fuente: el post de @tracheopteryx del 15 oct 2026. El autor dice que trabaja casi a diario con agentes desde febrero, para programar y para organizar su vida, y publica su configuración completa. Aquí interesa una parte: cómo reparte el código entre varios agentes sin que se pisen. Sin prueba propia todavía.
Su agente principal es Claude Code. Desde ahí llama a otros: Codex para revisiones independientes, segundas opiniones y trabajos largos, DeepSeek para encargos pequeños y cerrados en un entorno aislado, y un modelo rápido para decisiones de sí o no en puntos concretos del flujo. Los nombres de modelos cambian cada pocos meses. El método es lo que se puede copiar.
Todo empieza con una lista «hecho cuando» que un programa puede comprobar. Con esa lista, el agente principal divide el trabajo y entrega trozos acotados, cada uno en su propio git worktree: una carpeta aparte con su rama, sobre el mismo repositorio. Cuando un agente vuelve, el modelo rápido compara su informe con la lista y señala qué mirar primero, pero las comprobaciones reales se ejecutan siempre. Si un bucle no avanza en dos intentos, se para y se replantea el plan.
La revisión depende de lo difícil que sea deshacer el cambio. Lo rutinario entra cuando la CI pasa. Lo crítico espera una revisión independiente. Lo que está en producción sigue un protocolo escrito. Todo pasa por un pull request con CI. Cada incidente real se convierte en un check automático, y una retrospectiva semanal lee las sesiones y propone mejoras. El autor añade dos detalles útiles: sus agentes en paralelo ven qué ficheros están editando los demás, y Claude Code y Codex comparten un solo fichero de instrucciones y una biblioteca de skills.
Lo que no hay: métricas, el texto de sus instrucciones ni un repositorio con la configuración. Parte del post promociona un producto propio, que esta ficha no trata. El prompt de la cabecera es propio y resume el flujo en cinco pasos.
Si empiezas con un solo agente, mira primero programar con un agente en tu repositorio. Para ver el mismo patrón de PRs revisados en un proyecto real, está el caso de un micronegocio web que mantiene un agente. Y si quieres modelos en tu propia máquina, como hace el autor con un ordenador en casa, tienes un modelo local con Ollama. La versión de esto con bots no programadores está en la miniguía de equipo de bots con coordinador.
Preguntas frecuentes
¿Lo habéis probado?
No. Sin prueba propia todavía. La ficha resume el post de @tracheopteryx del 15 oct 2026. El prompt es propio y no se ha ejecutado aquí.
¿Cómo evito que dos agentes editen lo mismo?
Con dos medidas que propone el método: repartir trozos acotados y dar a cada agente su propio git worktree, una carpeta aparte con su rama. El autor añade que sus agentes en paralelo ven qué ficheros están editando los demás.
¿Qué es una lista «hecho cuando»?
Las condiciones que tiene que cumplir la tarea para darla por terminada, escritas de forma que un programa las pueda comprobar: tests, build, una respuesta concreta. El revisor compara cada informe con esa lista y luego se ejecutan las comprobaciones.
¿Hace falta usar Codex o DeepSeek?
No para copiar el método. El autor reparte entre varios modelos, pero el reparto, los worktrees y la revisión por riesgo funcionan igual con subagentes del mismo agente principal.
¿Cuánta revisión necesita cada cambio?
Depende de lo difícil que sea deshacerlo. En el método, lo rutinario se fusiona con la CI en verde, lo crítico espera una revisión independiente y lo que está en producción sigue un protocolo escrito.
Telegram. Suscríbete al canal de Telegram para no perderte nada y estar al loro de todo lo nuevo en automatización y agentes de IA.Unirme al canal