Cómo leer: las primeras cuatro etapas (módulo 6.1) son de preparación: en ellas no se escribe ninguna línea de código de producción. Las cuatro siguientes (módulo 6.2, en cian) son de ejecución y verificación. Si la preparación es buena, la ejecución es rápida; si te saltas la preparación, reconocerás todos los problemas descritos en el recorrido 4.
🧰 Antes de empezar
Qué necesitas
- • Un repositorio tu, pequeño, con pruebas que se ejecutan.
- • Un agente de código (Claude Code, Codex, Cursor — da igual).
- • Una rama nueva. Nada de esto ocurre en la rama principal.
- • De 2 a 3 horas sin interrupciones, o dos sesiones de 90 minutos.
Cómo elegir la tarea
- • Pequeña: cabe en 3 a 5 archivos.
- • Verificable: se puede demostrar con una prueba que quedó lista.
- • Real: algo que de verdad estaba en tu lista.
- • Reversible: nada de migraciones de base de datos ni cambios en el contrato público.
Mapa de la ruta
Contenido detallado
🧱 Ejercicio: spec, harness y loop
Etapas 1 a 4 del proyecto final: elegir el problema, escribir la especificación completa, configurar el harness con límites y diseñar el loop de ejecución, todo antes de la primera línea de código.
La selección de una funcionalidad, un error o un módulo heredado de tu propio repositorio para usarlo como caso del ejercicio.
Elegir mal es la forma más común de que el ejercicio falle: una tarea demasiado grande impide cerrar el ciclo y no ves el método en funcionamiento.
3 a 5 archivos · verificable mediante pruebas · reversible · algo que ya estaba en tu lista.
La aplicación del módulo 1.2 a tu caso: problema, objetivo, alcance, fuera de alcance, entradas, salidas, contratos, errores, restricciones, criterios, pruebas y definición de terminado.
Aquí es donde el ejercicio rinde frutos: descubrirás, todavía sobre el papel, decisiones que habrías delegado sin darte cuenta.
Criterio verificable · alcance negativo explícito · toda suposición se convierte en una pregunta respondida antes de programar.
Definir las herramientas, el contexto, los permisos y los límites: el AGENTS.md del módulo 2.1, la branch/worktree aislada y el comando de prueba rápida.
Sin esto, pasarás todo el ejercicio repitiendo restricciones en el chat, y algunas se te escaparán.
El permiso implícito es total · el aislamiento hace que el error cueste poco · comando de prueba documentado.
El ciclo de ejecución, prueba y corrección con un objetivo verificable, un límite de intentos, una condición de parada por falta de progreso y un punto de aprobación humana.
El ciclo escrito de antemano es lo que impide que la sesión se convierta en «inténtalo de nuevo» hasta el cansancio.
Objetivo = comando · máximo de intentos · mismo error 2 veces → detenerse · pruebas intocables.
Un archivo sencillo donde anotas el tiempo invertido, los intentos, el costo, lo que el agente supuso y dónde tuviste que intervenir.
Sin registro, el ejercicio se convierte en una impresión. Con registro, se convierte en el argumento que llevas al equipo.
Medir la propia práctica · La intervención humana es un dato · Comparación antes/después.
La verificación final antes de liberar al agente: spec con criterios verificables, PREGUNTAS respondidas, AGENTS.md en su lugar, branch aislada, comando de prueba funcionando y límites definidos.
Cada elemento que falte aquí se convierte en una corrección costosa en el módulo 6.2, o en un resultado que pasa las pruebas pero está mal.
Una buena preparación = ejecución rápida · todavía sin código · listo significa listo.
🏁 Ejercicio: ejecución, gates, revisión y entrega
Etapas 5 a 8: ejecutar el cambio más pequeño posible, aplicar build, lint, pruebas y seguridad, hacer la revisión independiente y preparar el pull request con evidencia.
Ejecuta el ciclo definido en la etapa 4, exigiendo el plan antes de la implementación y el cambio más pequeño que cumpla los criterios.
Aprobar el plan cuesta dos minutos y evita rehacer una hora de implementación en la dirección equivocada.
Plan aprobado de antemano · cambio mínimo · salida real de las pruebas pegada, nunca resumida.
Ejecuta la batería completa del módulo 3.3 sobre el cambio y registra el resultado de cada puerta.
Es donde descubres qué gates aún no tiene tu repositorio, y esa lista es un producto valioso del ejercicio.
La ausencia de un gate también es un resultado · ningún secreto ni dependencia nueva sin aprobación · evidencia adjunta.
Abrir una sesión limpia y revisar el cambio con el prompt del módulo 3.2, recibiendo solo la especificación y el diff.
Es la etapa que más sorprende a quienes hacen el ejercicio: el revisor encuentra cosas que quien implementó defendía con confianza.
Independencia de contexto · hallazgos con nivel de gravedad · tú decides qué se convierte en cambio.
Prepara el pull request con la spec, el diff, la salida real de las pruebas, el resultado de los gates, los hallazgos de la revisión y lo que quedó fuera del alcance.
Un PR con evidencia se revisa en minutos; un PR sin evidencia se revisa de boca en boca, o se aprueba sin leerlo.
Evidencia adjunta > narrativa · también se declara lo que quedó fuera · aprobación humana registrada.
La revisión del propio proceso: dónde tuviste que intervenir, qué suposiciones hizo el agente, qué gates faltaron y cuánto costó.
Cada intervención tuya puede convertirse en una rule, un gate o un elemento del AGENTS.md; así es como el sistema mejora por sí solo en la próxima tarea.
Intervención → regla · gate ausente → backlog · aprendizaje registrado, no recordado.
La recopilación de los artefactos producidos: modelo de spec, AGENTS.md, modelo de loop, rules, skills, checklist de gates, flujo de review, playbooks y checklist de gobernanza.
Este kit es lo que transforma un taller de dos días en un cambio permanente en la práctica, porque vuelve al repositorio contigo.
Artefacto versionado > anotación · empieza por lo que ya usaste en el ejercicio · compártelo con el equipo.