Ship while you sleep

Dejá objetivos grandes corriendo y volvé a algo 99% prod-ready. Este es el patrón que usamos en 021 para trabajar con agentes autónomos — y las respuestas a las preguntas que más me hicieron cuando lo compartí.

El problema: vos sos el loop

Le pedís algo grande al agente, vuelve a medias, le repetís el contexto. Dos agentes en paralelo se pisan archivos, ramas y puertos. Vos probás a mano, encontrás el bug, se lo explicás, y repetís. Te quedás de niñera mirando cada paso.

La salida no es un framework: es estructura. Cada pieza saca una decisión de tus manos y se la da al agente, con barreras para que no rompa nada.

El patrón: cuatro movimientos

• 1 · Iterar → prompt. El agente charla el objetivo con vos y genera el spec antes de tocar código.
• 2 · Partir → workspace. Si la tarea es grande, la divide y crea un workspace aislado por sub-tarea: un clon real de cada repo que toca y un bloque de puertos propio. Dos agentes en paralelo nunca comparten archivos, ramas ni puertos.
• 3 · Agente E2E. Prueba en el navegador, encuentra bugs, analiza la causa raíz (no el síntoma), aplica el fix y vuelve a probar. El E2E está completo recién con 3 conversaciones limpias seguidas — cualquier fix resetea la racha.
• 4 · Volvés listo. Capturas, feedback y fixes documentados en una carpeta de reportes por tarea.

¿Por qué clones y no worktrees?

La pregunta que más me hicieron. Arranqué con worktrees: con un agente andan, con varios autónomos corriendo a la vez empezaron los archivos corruptos y los cruces de rama. El problema de fondo es que los worktrees comparten el mismo .git:

• Un agente que se manda un gc --prune, reset --hard o branch -D puede afectar a todos los worktrees.
• Git no deja checkoutear la misma rama en dos worktrees → casos borde feos cuando dos agentes autónomos se cruzan.
• Config y hooks se heredan del padre: un agente que los toca afecta a todos.

Con clones reales desde un mirror bare local, clonar es instantáneo y cada tarea queda 100% aislada — incluido su propio hook anti-push a staging/main. Y nada de framework pesado: bash + git, una capa fina de helpers que en un comando clona, ramea, renderiza el env, asigna puertos e instala el hook.

El handoff importa más que la verbosidad

¿Qué tan detallado tiene que ser el prompt? No es la longitud: es darle al agente forma de verificar sus iteraciones, y un handoff específico en el QUÉ / POR QUÉ / criterios, suelto en el CÓMO. Lo que le doy por frente:

• Síntoma observable.
• Causa raíz verificada contra el código, con archivo:línea — lo más importante: le saca la ambigüedad, no re-descubre.
• Dirección del fix + constraints ("NO montes X", "reutilizá Y") — no línea por línea.
• Archivos exactos: principal + cuáles reusar / no tocar.
• Criterios de aceptación testeables.
• Convenciones del repo.

## Síntoma
checkout duplica el descuento con 2 cupones

## Causa raíz (verificada)
web/lib/cart.ts:142 — recalcula el total
sin limpiar el descuento previo

## Fix + constraints
acumular en una pasada.
NO montes un sistema de promos nuevo;
reutilizá applyDiscount()

## Criterios de aceptación
- 2 cupones → 1 descuento c/u
- test:e2e checkout verde

Y lo grande lo parto en frentes disjuntos — archivos que no se cruzan — para correrlos en paralelo, cada uno con su propio loop de verificación. Cada frente vive en su sesión (GUI de Claude / Codex) y roto entre sesiones como tabs: a revisar avances, no a hacer de niñera.

El resultado

Lo importante no son los comandos exactos — es la estructura: aislar para escalar, proteger lo crítico, y hacer que el agente cierre su propio loop de calidad.

Ver el patrón completo, interactivo →