Un patrón que cualquier builder puede armar: el agente itera con vos, parte las tareas grandes en workspaces aislados, y un agente de E2E corrige sus propios errores hasta cumplir el objetivo. Acá está cómo lo hacemos en 021.
No es magia: 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 agente charla el objetivo con vos y genera el spec/prompt antes de tocar código.
Si la tarea es grande, la divide y crea un workspace aislado por sub-tarea.
Prueba en el navegador, encuentra bugs, analiza causa raíz y se auto-corrige.
Capturas, feedback y fixes documentados. 99% prod-ready con ajustes menores.
Cada tarea recibe un clon real de cada repo que toca (no un worktree compartido) y un bloque de puertos propio. Dos agentes corriendo en paralelo nunca comparten archivos, ramas ni puertos — y si uno se manda una macana, solo rompe su tarea.
$ task-new checkout-v2 web agents ▸ slot 0 → bloque 21000 (web=21000 agents=21001) → web clon aislado · rama checkout-v2 · env ✓ → agents clon aislado · rama checkout-v2 · env ✓ ✓ workspace listo: tasks/checkout-v2/ $ task-start checkout-v2 web → http://localhost:21000 agents → http://localhost:21001 # otro agente en paralelo arranca en el slot siguiente, sin cruzarse:
$ git push origin staging ✗ Push directo a 'staging' BLOQUEADO. Abrí un PR. # el agente trabaja libre en su rama; lo importante queda protegido
Y arranca solo: escribís feat: … o describís la feature, y el agente infiere nombre + repos, te confirma, y crea el workspace. Cero ceremonia.
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: los worktrees comparten el mismo .git.
Nada de framework pesado — bash + git. Una capa fina de helpers que en un comando: clona del mirror, ramea desde la base, hace el pull/render del env, asigna el bloque de puertos, instala el hook y crea la carpeta de reportes E2E.
No alcanza con reportar bugs. El agente reproduce en el navegador, cruza las trazas y los logs, encuentra la causa raíz (no el síntoma), aplica el fix y vuelve a probar. Repite hasta que sale limpio.
¿Qué tan detallado tiene que ser el prompt para que vuelva 99% prod-ready? 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 checkout duplica el descuento con 2 cupones ## Causa raíz (verificada) web/lib/cart.ts:142 — recalcula total sin limpiar el descuento previo ## Fix + constraints acumular en una pasada. NO montes sistema de promos nuevo; reutilizá applyDiscount() ## Criterios - 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.
Dos carpetas hacen toda la diferencia: una que el agente lee primero para saber cómo es el proyecto, y otra donde deja evidencia de cada prueba que hizo.
toolbox/ AGENT_CONTEXT.md qué hace cada repo, cuándo usar cuál E2E_TESTING.md cómo testear (target, loop, reportes) ENVIRONMENTS.md dev / staging / prod …docs de orientación… scripts/ checks read-only (contexto, env, deploys) start.sh levanta los servicios
toolbox/ = el hub de orientación del proyecto (no es un repo). El agente —Claude, Codex o Cursor— lo lee antes de tocar nada: docs de cómo funciona cada parte, scripts que verifican sin romper ni exponer secretos, y un start. Así cualquier agente arranca con el mismo mapa.
tasks/checkout-v2/ web/ agents/ clones aislados e2e-reports/ conv-1.md bug → causa raíz → fix conv-2.md limpia (racha 1/3) conv-3.md limpia (racha 2/3) conv-4.md limpia (racha 3/3) 🏁 screenshots/ conv-1/ 01-login.png … conv-1/ bug-precio.png conv-4/ final.png
Después de cada E2E, por feature, el agente deja un reporte por conversación y capturas de los pasos clave, el bug y el estado final. Volvés y ves qué probó, qué encontró y cómo se corrigió — sin reconstruir nada.
prod-ready de entrada, con ajustes menores tuyos al final.
capturas de las pruebas que hizo, feedback, y cómo se auto-corrigió.
varios objetivos en paralelo, cada uno en su workspace, sin cruzarse.
Cada proyecto tiene su stack y su forma de E2E — pero el esqueleto es el mismo. Cuatro piezas:
# 1. describís el objetivo > feat: rehacer el checkout con cupones # 2. el agente lo parte y aísla ✓ tasks/checkout-v2/ (web + agents) # 3. construye + corre el loop E2E … conv 1: bug → causa raíz → fix … conv 2: limpia (racha 1/3) … conv 3: limpia (racha 2/3) … conv 4: limpia (racha 3/3) 🏁 E2E completo · 99% prod-ready
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.