Ship while you sleep

Read this post in English →

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, sino la estructura: aislar para escalar, proteger lo crítico, y hacer que el agente cierre su propio loop de calidad.

Preguntas frecuentes

Ver el patrón completo, interactivo →