Session Escaleta: S4 - Autonomía Real (AFK)

Position in Journey

Phase: Fase 4 — Autonomía Real (AFK)
Key question: ¿Pueden los agentes funcionar sin que el humano esté en el bucle?
Terminal objective: Configurar un agente autónomo identificando los cuatro elementos (Prompt input, Trigger, Environment, Review) que complete una tarea real sin intervención humana

Key Concepts

In-loop vs out-of-loop — Los dos modos de trabajo agéntico. Hasta ahora todo ha sido in-loop (el humano presente, corrigiendo, iterando). Out-of-loop: lanzas, te vas, vuelves. Es el cambio que desbloquea la escalabilidad. Hasta ahora la orquestación éramos nosotros — lanzábamos las tareas a mano. Ahora esa orquestación está implementada en código.
ADW (AI Developer Workflow) — El artefacto concreto: un sistema que orquesta issue → clasificación → plan → implement → commit → PR sin intervención humana. La orquestación es código determinista (Ruby) — NO usa IA para decidir el flujo. Claude aparece solo DENTRO de cada paso (clasificar, planificar, implementar, commitear, crear PR). Cada invocación de Claude es un agente independiente con contexto fresco y propósito único. Compone las templates de S3 en un flujo autónomo end-to-end. Los alumnos van a ejecutar uno antes de entender cómo funciona.
Los cuatro elementos de un ADW — La lente para diseñar cualquier flujo autónomo. Cuatro elementos: Prompt input (qué alimenta el trabajo — un issue, un ticket), Trigger (qué lo arranca — manual, cron, webhook), Environment (dónde opera — rama dedicada para el issue), Review (cómo se valida — tests, PR, comentarios en el issue).
Confianza progresiva y flujo arbitrario — Empezar con trigger manual (bajo riesgo). Después automatizar el trigger (cron, webhook). Después escalar a bugs y features. El flujo classify→plan→implement→commit→PR es absolutamente arbitrario — es tarea del equipo decidir si este flujo vale o diseñar el suyo. Cuando falla: arreglar el template o el ADW, no el síntoma.
Más allá del código — La capa ADW no es solo para desarrollo. El mismo patrón de orquestación + agentes sirve para generar PRDs, historias de usuario, documentación. Ya no hacemos código — creamos sistemas que generan sistemas. La capa ADW es donde los equipos van a tener que centrarse.
Evolución de la orquestación — De comando a comando (nosotros), a código determinista (ADW), a IA dirigiendo el flujo (frontera). El código es rígido: supone que podemos prever todos los casos, pero el desarrollo de software es complejo e impredecible. El siguiente paso lógico: que una IA dirija la orquestación. Estado del arte emergente, muy verde. Los alumnos llegan a esta conclusión por reflexión guiada, no por explicación directa.
/prime:adw y la regla vibe/sistemático — El ADW es código que los equipos van a customizar. Para trabajar en él, el agente necesita contexto del codebase. /prime:adw provee ese contexto. Y en este trabajo exploratorio-arquitectural, el vibe coding está justificado: no buscamos consistencia, buscamos diseño. Regla: AFK para el código de la aplicación, vibe + /prime para diseñar la capa de orquestación. Es el ejemplo más concreto de por qué existen los comandos de tipo prime.

Session Flow

#	Block	Type	Description	Key Concepts	~Duration
1	Check-in	—	Ritual: cómo se encuentra cada persona	—	~5 min
2	Pregunta provocativa	—	“¿Cuántas horas a la semana pasáis supervisando lo que un agente ya sabe hacer?”	—	~3 min
3	Recap	—	Puente desde S3: tenéis templates (chore/bug/feature) que sistematizan el trabajo. Pero seguís ahí, mirando. “Ahora vamos a hacer que funcionen sin vosotros.”	—	~5 min
4	De in-loop a out-of-loop	MODELAR	Los dos modos de trabajo agéntico. In-loop: estás presente, corriges, iteras. Out-of-loop: lanzas, te vas, vuelves. Pregunta al grupo: “¿Qué necesita el agente para funcionar sin vosotros?” Recogida de ideas → “Vamos a probarlo. Ahora.”	1	~10 min
5	Lanzamos ADWs	PRACTICAR	Dos demos en los forks de cada participante. Demo A (manual, ~12 min): todos lanzan `adws/bin/adw_plan_build <issue>` con el issue “Diálogo de confirmación al borrar tarea”. Primer AFK colectivo. Mientras ejecuta, el facilitador narra las fases del pipeline (classify → branch → plan → implement → commit → PR). Verifican el PR. Demo B (cron, ~12 min): todos arrancan `adws/bin/trigger_cron` en su fork. Activan el issue “Tareas completadas al final con separador y estilos” (comment “adw”). El cron lo detecta (~20s) y lanza el pipeline automáticamente — nadie lanza nada esta vez. Verifican el segundo PR. Post-verificación (~3 min): dos PRs, mismo pipeline, diferente trigger. “¿Qué cambió? Solo quién lo arranca.” + “El PR es una propuesta. El flujo es arbitrario — nosotros decidimos si vale.”	2	~25 min
6	Anatomía de un ADW	MODELAR	Con la experiencia fresca de ambos triggers, el facilitador recorre el código del ADW (`adw_plan_build` + `trigger_cron`) y lo descompone en los 4 elementos. “Habéis usado dos triggers distintos. Mismo pipeline. ¿Qué cambió? Solo el Trigger.” Observaciones durante el code walkthrough: “¿Dónde está la IA? Solo en los agentes — la orquestación es Ruby puro.” “Cada instancia de Claude es un agente diferente con contexto fresco — ya estáis haciendo multi-agente.” “Este flujo es arbitrario — vuestro equipo decide si vale o diseña otro.” Pregunta: “¿Cuáles de las templates de S3 reconocéis dentro del ADW?” → Descubren que /chore, /bug, /feature y /implement están embebidos. Cierre del bloque — el facilitador nombra los tres niveles de orquestación que han vivido: comando a comando (S1-S3), nosotros como orquestadores (Demo A), código como orquestador (Demo B). Señala la limitación: el código es rígido, supone que prevemos cada caso. Pregunta: “¿Cuál sería el siguiente paso lógico?” Reflexión guiada → el grupo llega a: orquestación dirigida por IA. Cierre: estado del arte emergente, prácticas muy verdes — ahí se mueve la frontera.	2, 3, 6	~27 min
7	/prime:adw — trabajar EN el ADW	MODELAR	Insight de cierre del bloque de orquestación: el ADW es código que el equipo va a customizar. Para que el agente entienda su estructura, `/prime:adw` da ese contexto. Y aquí el vibe coding está bien — es el único trabajo de la sesión donde no queremos AFK. Regla: AFK para el código de la aplicación, vibe + prime para diseñar la capa de orquestación. Ejemplo más concreto de por qué existen los comandos de tipo prime.	7	~7 min
8	AFK en tu proyecto	APLICAR	Los equipos diseñan y ejecutan su primer flujo AFK para un chore real de su backlog. Paso a paso: (1) Eligen un chore de Jira, (2) Configuran Prompt input: adaptan las templates de S3 si necesitan, (3) Trigger manual: lanzan el flujo plan→build, (4) Environment: rama dedicada para el issue, (5) Review: tests + MR en GitLab. Primera experiencia AFK en su contexto real.	2, 3, 4	~30 min
9	Reflexión / Resumen	REFLEXIONAR	Puesta en común: ¿funcionó? ¿Cómo se siente soltar el control? Identidad: “Ya no hacemos código — creamos sistemas que generan sistemas. La capa ADW es donde los equipos van a centrarse.” Amplitud: “Y no solo para desarrollo — el mismo patrón sirve para PRDs, historias de usuario, documentación.” Semilla S5: “El agente trabaja solo, pero ¿cómo sabéis que lo ha hecho bien? ¿Y si falla un test y no os enteráis?” → bucles cerrados de retroalimentación.	4, 5, 6	~15 min
10	Check-out	—	Ritual: cómo se va cada persona	—	~5 min

Lab Demo

Sí. El corazón de la sesión son dos demos colectivas hands-on con la demo app (TODO app Rails+React), rama S4. Cada participante tiene su propio fork del repo:

Demo A — trigger manual (bloque 5, primera mitad): todos lanzan adws/bin/adw_plan_build <issue> con el issue “Diálogo de confirmación al borrar tarea”. Ven el flujo completo end-to-end: classify → branch → plan → implement → commit → PR. Sin intervención humana. Momento “wow” colectivo.
Demo B — trigger cron (bloque 5, segunda mitad): todos arrancan adws/bin/trigger_cron y activan el issue “Tareas completadas al final con separador y estilos”. El cron lo detecta (~20s) y lanza el pipeline automáticamente. Nadie lanza nada esta vez — la progresión de manual a cron se VIVE.
Análisis del código (bloque 6): con la experiencia de ambos triggers, el facilitador recorre el código del ADW señalando cada elemento. Los alumnos descubren que las templates de S3 (/chore, /bug, /feature, /implement) están embebidas en el ADW y que la orquestación es código determinista sin IA.

Practica en Proyecto

Sí. Los equipos diseñan y ejecutan su primer flujo AFK con un chore real de su backlog Jira (bloque 7). Versión simplificada: trigger manual, un solo chore, rama dedicada en GitLab. Aplican los cuatro elementos: Prompt input (templates de S3 adaptadas), Trigger (manual), Environment (rama dedicada para el issue), Review (tests + MR). Primera experiencia de autonomía real en su contexto de trabajo.

Notes

La secuencia PRACTICAR→MODELAR (bloques 5→6) es deliberada: discovery-based learning. Los alumnos EJECUTAN el ADW antes de entender cómo funciona. La teoría (los cuatro elementos) emerge del análisis de lo que acaban de vivir. Más efectivo que teoría→práctica para el objetivo emocional (asombro) y cognitivo (comprensión anclada en experiencia).
El momento definitorio (del journey) ocurre en el bloque 5: todos lanzan un ADW, nadie toca nada, y al verificar el PR comprueban que el agente completó trabajo real sin intervención. Es un “wow” colectivo. La Demo B refuerza el impacto: esta vez ni siquiera lanzan — el cron lo hace.
Progresión de triggers: Demo A = manual (adw_plan_build), Demo B = cron (trigger_cron). La progresión se VIVE, no se explica. Al final del bloque 6, la evolución de la orquestación (manual → código → IA) se aborda como concepto fundamental. Cada participante trabaja en su propio fork del repo.
Conexión S3→S4: las templates /chore, /bug, /feature de S3 están DENTRO del ADW. Los alumnos lo descubren en el bloque 6 (pregunta del facilitador). El ADW no reemplaza las templates — las compone en un flujo autónomo.
Orquestación determinista vs IA: el pipeline del ADW es Ruby puro, determinista. Claude solo aparece dentro de cada paso (classify, plan, implement, commit, PR). Cada invocación = agente independiente con contexto fresco. Esta observación emerge en el code walkthrough del bloque 6, y se contrasta explícitamente con la orquestación por IA al cierre del bloque: el código es rígido → el siguiente paso lógico es orquestación dirigida por IA (frontera, muy verde).
GitLab/Jira vs GitHub: la demo usa GitHub (demo app, forks). La práctica en proyecto usa GitLab/Jira (su stack real). Los cuatro elementos son agnósticos de plataforma — funcionan igual.
El arco emocional va de vértigo (soltar el control) a asombro (funcionó sin mí). La pregunta provocativa y el bloque 4 generan tensión; Demo A la resuelve con impacto, Demo B la amplifica (el cron lo hace solo).
Talking points de reflexión (bloque 8): “Ya no hacemos código, creamos sistemas que generan sistemas.” “No solo para desarrollo: PRDs, historias de usuario, documentación.” Son observaciones breves — una frase cada una — que cierran la sesión con visión amplia. La orquestación por IA ya se cubrió como concepto completo en el bloque 6.
Si falta tiempo, comprimir bloque 4 (fusionándolo con el inicio del bloque 5) antes que recortar bloques 6 o 7 — la experiencia + análisis + transferencia son el corazón.
Margen de ~32 min disponible, especialmente para extender el bloque 7 (AFK en proyecto) que previsiblemente necesitará más tiempo.