Ejecución sin supervisión
Este es el modo para "aquí está el plan, adelante": impleméntalo de principio a fin sin nadie en el teclado, y sé revisable cuando el humano regrese. No está ligado a una hora del día. Aplica a cualquier período donde nadie esté mirando para responder una pregunta.
Presupone un plan aprobado
Este modo no anula el principio de proponer antes de construir (ver coding-process). Es lo que sucede después de la aprobación. Dentro del plan aprobado, decide tú mismo los detalles de implementación reversibles y escribe cada suposición. Una suposición documentada es mejor que una sesión que pasó la noche esperando. Esa es toda la exención.
Cuatro puntos de control que nunca pasas solo
Estos siguen siendo puntos de control incluso cuando el paso es reversible. Ninguno de ellos es una decisión subjetiva.
- Alcance. Cualquier cosa que el plan aprobado no cubra ya: una nueva funcionalidad, una refactorización que nadie pidió, o omitir un paso porque resultó difícil. Configurar un test harness faltante cuenta como alcance.
- Cualquier cosa que salga de la máquina: mensajes externos, publicación, o llamadas a un servicio de terceros. El trabajo en el repositorio (ramas, commits, pushes, PRs) está dentro del plan; hablar con el mundo exterior no lo está.
- Cualquier cosa que gaste dinero: APIs de pago, infraestructura provisionada, cualquier cosa medida.
- Cualquier cosa destructiva o irreversible: pérdida de datos, force-pushes a ramas compartidas, producción.
Mantén el trabajo duradero
- Aísla primero. Usa un worktree a menos que el harness ya te haya dado uno. Una ejecución sin supervisión es exactamente cuando alguien más puede tocar el checkout principal.
- Haz commit y push después de cada unidad lógica, no solo al final. El trabajo no empujado se pierde si la sesión termina abruptamente. En este modo, esto anula la regla habitual de "preguntar antes de commit".
- Nunca entres en una pausa con trabajo sin commitear. Si tu agente expone límites de uso, haz una pausa cerca del límite, espera a que se reinicie, luego reanuda.
- Ejecuta las comprobaciones completas en los puntos de control, no después de cada edición. A mitad de edición, ejecuta la comprobación más estrecha que detectaría lo que acabas de cambiar: la verificación de tipos de un paquete, o un archivo de prueba. Ejecuta la compilación, el lint, la suite de pruebas completa y la compuerta equivalente a CI una vez que una unidad de trabajo esté completa y antes de empujarla para revisión. Volver a ejecutar una suite que pasó hace diez minutos, sobre código que no has tocado, gasta recursos para no aprender nada.
Delegación (si tu agente puede generar subagentes)
- Delega trabajo mecánico a modelos más baratos: clonar una estructura existente, código repetitivo, sincronizar documentación, ediciones repetitivas. Mantén el modelo principal para lógica crítica de corrección (esquemas, límites de seguridad, servicios centrales) y para decisiones subjetivas.
- Limita la concurrencia a aproximadamente cinco. Más allá, la auditoría deja de ser real y los agentes paralelos chocan en los mismos archivos.
- Audita todo lo delegado. Nunca integres la salida de un subagente sin leerla. Verifica que tenga sentido, siga las convenciones, y que compile y pase las pruebas en verde. Cuando está mal, evalúa la brecha: corrige una pequeña tú mismo, y devuelve una grande con la corrección.
Bloqueos
- Hazlos visibles; no adivines. Cuando un paso del plan tiene un punto de control explícito, o encuentra un bloqueo real (infraestructura faltante, una suposición fallida), márcalo claramente en lugar de inventar una solución alternativa que cambie el diseño.
- Primero haz todo lo que no dependa de la respuesta, para que el humano regrese a una pregunta más trabajo terminado, no solo a una pregunta.
- Una revisión de PR estancada también es un bloqueo. Márcala, y continúa construyendo las etapas superiores localmente donde no dependan de la respuesta.
La verificación de UI no es opcional cuando nadie mira
Conducir la UI en un navegador es el paso más fácil de omitir cuando nadie mira, y aquel cuya ausencia un revisor no puede ver en el diff. Sigue verify-ui. Si el entorno realmente no puede ejecutar la funcionalidad (credenciales faltantes, infraestructura que no posees), indícalo en la sección de Pruebas del PR: menciona qué lo bloqueó y qué se verificó en su lugar. El silencio se lee como "verificado".
Cuando termines
Reporta el estado del trabajo: qué se entregó (PRs y ramas), qué está esperando revisión, cada suposición hecha, y cada bloqueo marcado. Escríbelo en un documento de traspaso en docs/plans/ si la sesión está por terminar.