Session Design: S5 - Auto-corrección

Position in Journey

Phase: Fase 5 — Auto-corrección
Emotional goal: Confianza. El sistema no solo ejecuta — se corrige. La supervisión humana se reemplaza con diseño.
Cognitive goal: Bucles cerrados de retroalimentación. Tests técnicos vs. validaciones de comportamiento como dos capas distintas. Request-Validate-Resolve como framework para escribir prompts que se autocorrigen. Auto-documentación como feedback loop asincrónico: el agente narra lo que hizo para humanos y agentes futuros.
Key question: ¿Cómo hago que el sistema mejore por sí mismo?

Terminal Objective

Implementar un bucle cerrado de retroalimentación donde el agente testea, detecta errores y se corrige sin supervisión, añadiendo al menos una capa de validación al ADW de S4.

Learning Objectives

O1 (COMPRENDER): Dado un escenario donde el código pasa todos los tests técnicos pero la feature no funciona como se pidió, el participante distinguirá tests técnicos (linter, unit tests, compilación) de validaciones de comportamiento (E2E, Playwright), explicando por qué ambas capas son necesarias en un prompt agéntico y qué problema captura cada una.
O2 (COMPRENDER): Tras observar la comparación entre un ADW sin bucle (S4) y un ADW con bucle cerrado, el participante describirá el patrón ejecuta→valida→refleja→corrige→re-valida, identificando en qué paso el ADW “ciego” falla y qué aporta cada paso del bucle.
O3 (APLICAR): Dado un tipo de tarea real de su stack (Rails/React), el participante aplicará el framework Request-Validate-Resolve escribiendo un prompt con al menos dos comandos de validación ordenados (top-to-bottom, stop-on-fail) y una instrucción de resolución explícita cuando fallen.
O4 (CREAR): Partiendo del ADW funcional de S4, el participante integrará al menos una capa de validación (linter, unit tests o E2E) consiguiendo que el ADW detecte y corrija al menos un tipo de error sin intervención humana.
O5 (APLICAR): Dado el prompt R-V-R de un ADW, el participante añadirá instrucciones de auto-documentación en la sección Request (commit messages descriptivos, PR description con contexto) y verificará que el agente produce documentación que explique qué cambió y por qué, evaluando si un reviewer podría entender el PR sin leer el diff completo.

Activities

Check-in

Duration: 5 min
Description: Ritual de apertura. “¿Cómo llegáis?” Ronda rápida — cómo se encuentra cada persona. Sin relación con el contenido de la sesión.
Materials needed: —

Pregunta provocativa

Duration: 3 min
Description: “El agente terminó. Los tests pasan. ¿Hizo lo que le pedisteis?” Dejar que la incomodidad aterrice en silencio. No responderla — la sesión la responde progresivamente. Apunta al gap entre tests técnicos y validación de comportamiento: visceral para cualquier dev que haya vivido que los tests pasen pero la feature esté mal.
Materials needed: —

Recap

Duration: 5 min
Description: Puente desde S4: “Tenéis ADWs que trabajan solos — Prompt input, Trigger, Environment, Review. Pero están ciegos: no saben si rompieron algo. Hoy les damos ojos.” Pregunta directa al grupo: “¿Qué pasaría si vuestro ADW de S4 completara 50 tareas incorrectamente sin que os enteraseis?” Recogida rápida de respuestas. Activa la necesidad antes de ofrecer la solución.
Materials needed: —

Tests vs. Validaciones (MODELAR)

Objective: O1
Duration: 10 min
Description: El facilitador presenta la distinción que los devs no tienen en sus prompts agénticos. Ejemplo concreto: el diálogo de confirmación de borrado (feature implementada en S4 con el comando adw_plan_build). El linter pasa, los unit tests pasan, la compilación es OK — pero el diálogo no aparece. Solo el Playwright test lo detecta. Pregunta al grupo: “¿Dónde está el bug? ¿Qué test lo habría pillado?” Cierre: ambas capas son necesarias y van en el bloque Validate del R-V-R. Enunciado: “Tests y validaciones son la ley del codebase — nunca se ignoran, siempre se arreglan.”
Materials needed: Slides con la distinción tests técnicos (linter/unit/compilación) vs. validaciones de comportamiento (E2E/Playwright)

El bucle cerrado (MODELAR)

Objective: O2
Duration: 10 min
Description: Demo conceptual (diagrama en slides): ADW de S4 sin bucle → ciego, puede completar mil tareas incorrectamente. ADW con bucle cerrado → ejecuta → valida → refleja sobre el error → corrige → re-valida. El segundo sabe si lo hizo bien. El facilitador recorre los 5 pasos del patrón: (1) ejecuta, (2) valida, (3) refleja sobre el error en el output, (4) corrige, (5) re-valida. Pregunta al grupo: “¿Cuántas ejecuciones AFK han tenido donde el agente ‘terminó’ pero no estaban seguros del resultado?” Cierre: “La fiabilidad no se supervisa — se diseña.”
Materials needed: Slides con diagrama del bucle cerrado (5 pasos), comparación ADW ciego vs. ADW con bucle

Request-Validate-Resolve (MODELAR)

Objective: O3
Duration: 12 min
Description: El framework en tres partes para escribir prompts con bucles integrados. El facilitador escribe un prompt R-V-R en vivo para un chore simple de la demo app. Request: qué construir. Validate: comandos de validación — “encode validation as commands”: si lo puedes hacer a mano, el agente lo puede hacer. Ejemplos en Rails: rubocop, rspec, rake assets:precompile. En React: eslint, jest. Resolve: qué hacer cuando falla — “arregla el código, no el test; si el test está mal, arréglalo primero.” Ordering explícito: “run top-to-bottom, stop on fail, rerun all steps from start.” El facilitador muestra el contraste: prompt sin R-V-R (una instrucción) vs. prompt con R-V-R (las tres secciones).
Materials needed: Slides con anatomía del R-V-R, editor de código visible para escribir el prompt en vivo

Auto-documentación (MODELAR)

Objective: O5
Duration: 7 min
Description: El facilitador introduce la tercera capa de feedback. Tests validan que el código funciona (feedback sincrónico — para el agente actual). Documentación valida que el trabajo se entiende (feedback asincrónico — para quien viene después). “¿Quién viene después?” Tres perfiles: (1) el reviewer que abre el PR, (2) el agente que procesa el siguiente issue y necesita contexto de lo que se hizo antes, (3) el dev que llega al equipo en 3 meses. El mecanismo es el mismo que para tests: se codifica en el prompt. La sección Request del R-V-R incluye qué documentar: commit messages descriptivos, PR description con contexto y validaciones ejecutadas, comments en el issue. Ejemplo concreto en pantalla: commit message genérico (“fix issue #123”) vs. commit message auto-documentado (“Restore confirmation dialog on task deletion. The JS click handler was commented out, causing the modal to not appear. Fixed by uncommenting the handler in TaskList.jsx. Validated: ESLint pass, Jest pass, Playwright E2E confirms dialog appears on delete click.”). Pregunta: “¿Cuál de estos dos commits queréis que produzca vuestro ADW?” Cierre: “No es más trabajo — es una instrucción más en el Request.”
Materials needed: Slide con las 3 capas de feedback (tests / validaciones / auto-documentación), slide con contraste de commit messages

Lab Demo: El agente que se autocorrige (PRACTICAR)

Objective: O1, O2, O3, O5
Duration: 30 min
Demo app branch: S5
Description: Progressive Validation Stacking en vivo. El facilitador ejecuta tres rondas en la demo app con el grupo observando. En cada ronda el agente falla, lee el error, corrige y re-valida — sin intervención humana.

Ronda A — Linter (~8 min): El facilitador introduce un error de estilo en el JS de React (variable sin usar, import incorrecto). Añade eslint al bloque Validate del prompt. El agente ejecuta, ESLint falla, el agente lee el error, corrige el código, re-ejecuta, pasa. El grupo observa la lectura del error y la corrección en el output de Claude Code.

Ronda B — Unit tests (~8 min): El facilitador introduce un bug de lógica (función que devuelve el resultado incorrecto). Añade jest al bloque Validate. El agente ejecuta, Jest falla con el stacktrace, el agente localiza el bug en el código, corrige, pasa. El facilitador nombra el patrón: “Progressive Validation Stacking — empezamos con una capa, añadimos otra.”

Ronda C — E2E con Playwright (~14 min) — Momento definitorio: El facilitador rompe el diálogo de confirmación de borrado (comenta el handler JS). Añade el test E2E de Playwright al bloque Validate. El agente abre el browser via Playwright MCP, navega a la app, intenta borrar una tarea, toma un screenshot, detecta que el diálogo no aparece (el screenshot no muestra el modal), lee el DOM del componente React, localiza el handler comentado, lo restaura, re-ejecuta el test E2E, el diálogo aparece, el test pasa. El grupo ve el browser moviéndose solo. El facilitador: “El agente acaba de hacer lo que un QA manual haría — abrir el browser, verificar la UI, detectar el problema. Solo que lo hará en cada PR para siempre.”

Observación de auto-documentación (~2 min, integrada en el cierre de Ronda C): Tras la corrección, el facilitador señala el commit message que el agente escribió. No dice “fix stuff” — narra exactamente qué estaba mal (handler comentado), qué se hizo (restaurar el handler), y qué validaciones pasaron. “Esto es auto-documentación: el agente no solo arregla — explica lo que hizo. Un reviewer abre este PR y entiende todo sin leer el diff.”
Materials needed: Fork propio de la demo app (rama S5) por el facilitador, Playwright MCP configurado en Claude Code, proyector visible para todo el grupo, demo app corriendo en local

Práctica en proyecto: Cerrar tus bucles (APLICAR)

Objective: O3, O4, O5
Duration: 35 min
Description: Los equipos trabajan sobre su ADW de S4. Paso a paso: (1) Mapean qué comandos de validación ya tienen en su codebase (linters configurados, suites de tests existentes, comandos de compilación). (2) Identifican qué capa de validación añadir primero — se recomienda empezar por la más simple disponible (habitualmente linter o unit tests). (3) Añaden la capa al bloque Validate de un prompt del ADW usando R-V-R, con ordering explícito. Además, añaden instrucciones de documentación en la sección Request: commit messages descriptivos que expliquen qué cambió y por qué, PR description con contexto. (4) Ejecutan el flujo con una tarea de prueba y verifican que el ADW detecta y corrige un error, y que produce documentación legible. El facilitador circula, guía pero no prescribe — el objetivo es que cada equipo encuentre su primera capa de validación real, no que implementen la misma solución.

Meta de sesión: el ADW de S4 sale capaz de autocorregirse en al menos un tipo de error y de documentar lo que hizo. Los equipos que terminen antes pueden añadir una segunda capa de validación.
Materials needed: Proyecto real del equipo (GitLab + ADW funcional de S4), documentación de linters y tests existentes en sus proyectos

Reflexión / Resumen (REFLEXIONAR)

Duration: 10 min
Description: Puesta en común: ¿qué capa añadisteis? ¿Funcionó? ¿Qué descubristeis sobre vuestros proyectos al mapearlo? ¿Cómo quedaron los commit messages? Síntesis: “La fiabilidad no se supervisa — se diseña. Y no solo se valida — se documenta. Antes revisabais cada ejecución agéntica y teníais que investigar qué hizo el agente. Ahora el sistema se valida solo y narra lo que hizo.” Identidad: “No solo creamos sistemas que generan sistemas — creamos sistemas que saben si lo hicieron bien y explican lo que hicieron.” Semilla S6: “El agente se corrige y documenta… pero a veces hace trabajo que no toca. ¿Cómo lo mantenéis enfocado en lo que se le pidió?”
Materials needed: Pizarra para anotar capas añadidas y patrones del grupo

Check-out

Duration: 5 min
Description: Ritual de cierre. “¿Cómo os vais?” Ronda rápida — cómo se va cada persona. Sin relación con el contenido de la sesión.
Materials needed: —

Time Budget

Block	Duration	Activity
Check-in	5 min	Ritual: cómo se encuentra cada persona
Pregunta provocativa	3 min	”El agente terminó. Los tests pasan. ¿Hizo lo que le pedisteis?”
Recap	5 min	Puente desde S4: ADWs que trabajan solos pero están ciegos
Tests vs. Validaciones	10 min	MODELAR — la distinción que falta en los prompts agénticos
El bucle cerrado	10 min	MODELAR — diagrama + comparación ADW ciego vs. con bucle
Request-Validate-Resolve	12 min	MODELAR — el framework + prompt en vivo
Auto-documentación	7 min	MODELAR — tercera capa de feedback + contraste de commit messages
Lab Demo: El agente que se autocorrige	30 min	PRACTICAR — linter → unit tests → E2E con Playwright + observación auto-doc
Práctica en proyecto: Cerrar tus bucles	35 min	APLICAR — añadir validación + documentación al ADW de S4
Reflexión / Resumen	10 min	REFLEXIONAR — síntesis + semilla S6
Check-out	5 min	Ritual: cómo se va cada persona
Total planificado	132 min
Safety margin (12%)	18 min
Total sesión	~150 min

Nota sobre el margen: 12% (18 min), coherente con S4 (12%). El bloque de práctica en proyecto (35 min) es el más impredecible — absorbe el margen si los equipos necesitan más tiempo. Bloques prescindibles en caso de ajuste: (1) “Tests vs. Validaciones” puede comprimirse a 6 min eliminando la pregunta al grupo. (2) “Auto-documentación” puede comprimirse a 4 min eliminando el ejemplo en vivo y yendo directo al contraste de commit messages en slide. El lab demo no se comprime — el momento definitorio (Ronda C, Playwright) es el corazón de la sesión.

Materials Needed

Demo app (rama S5): configurada con ESLint (React), RuboCop (Rails), Jest/RSpec, Playwright MCP — con código intencionalmente roto en tres capas (error de estilo, bug de lógica, diálogo de confirmación de borrado comentado). El facilitador la usa en el lab demo.
Fork propio por participante: cada participante con su fork de la demo app TODO (Rails + React) para el lab demo, con Claude Code configurado.
Playwright MCP: configurado en Claude Code del facilitador. Instrucciones de setup en la rama S5 del repo.
Slides: distinción tests técnicos vs. validaciones de comportamiento; diagrama del bucle cerrado (5 pasos); anatomía del R-V-R (Request / Validate / Resolve); validation ordering (top-to-bottom, stop on fail, rerun from start); 3 capas de feedback (tests / validaciones / auto-documentación); contraste de commit messages (genérico vs. auto-documentado).
Pizarra: para el recap (activar memoria de S4) y la reflexión (capas añadidas por equipo).
Proyecto real del equipo: GitLab accesible + ADW funcional de S4 para la práctica en proyecto.

S5: Auto Correccion