Session Escaleta: S5 - Auto-corrección

Position in Journey

Phase: Fase 5 — Auto-corrección
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

Key Concepts

Tests vs. Validaciones: dos capas de feedback — La distinción fundamental. Tests: ¿el código funciona técnicamente? (linter, unit tests, compilación — no rompiste nada). Validaciones: ¿el agente hizo lo que se pidió? (E2E, Playwright — ¿ocurrió lo que el usuario esperaba?). Un agente puede producir código impecable que pasa todos los tests y aun así no haber implementado la feature correctamente. Ambas capas son necesarias en los prompts agénticos.
Bucles cerrados de retroalimentación — El patrón: el agente ejecuta → valida → refleja sobre el error → corrige → re-valida. Sin este bucle, el AFK de S4 está ciego — puede completar mil tareas incorrectamente.
Request-Validate-Resolve — El framework para escribir prompts con bucles integrados. Tres partes: Request (qué construir), Validate (comandos de validación), Resolve (qué hacer cuando falla). Convierte cualquier prompt en un agente que se autocorrige.
Encode validation as commands — Transformar el proceso manual de testing en comandos ejecutables: linters, unit tests, integration tests, E2E. Si lo puedes hacer a mano, el agente lo puede hacer. Ordering: top-to-bottom, stop on fail, rerun from start.
Progressive Validation Stacking — La progresión natural de capas: linter → unit tests → compilación → E2E. Empezar con una capa y añadir progresivamente. Cada capa aumenta confianza y autonomía.
End-to-end testing con Playwright — El tipo de test más valioso: el agente abre el browser, navega, verifica que la UI entrega la experiencia diseñada. El cierre de bucle más completo.
Tests y validaciones como ley del codebase — Ambas capas tienen autoridad absoluta. Nunca se ignoran. Se arreglan — el código, el test o la validación, nunca se salta la comprobación.
Auto-documentación: el agente narra lo que hizo — Tests validan que el código funciona. Documentación valida que el trabajo se entiende. El agente produce artefactos de documentación como subproducto natural de su trabajo: commit messages descriptivos, PR descriptions con contexto, comentarios en código, updates en el issue. Mecanismo: instrucciones de documentación en la sección Request del R-V-R. Es un feedback loop asincrónico: tests dan feedback al agente actual, documentación da feedback a quien viene después — el reviewer del PR, el agente del siguiente issue, el dev que llega en 3 meses.

Session Flow

#	Block	Type	Description	Key Concepts	~Duration
1	Check-in	—	Ritual: cómo se encuentra cada persona	—	~5 min
2	Pregunta provocativa	—	“El agente terminó. Los tests pasan. ¿Hizo lo que le pedisteis?”	—	~3 min
3	Recap	—	Puente desde S4: tenéis ADWs que trabajan solos, pero están ciegos — no saben si rompieron algo. Hoy les damos ojos.	—	~5 min
4	Tests vs. Validaciones	MODELAR	La distinción que los desarrolladores no tienen en sus prompts agénticos: tests técnicos (¿funciona el código?) vs. validaciones de comportamiento (¿hizo lo que se pidió?). El linter y el unit test no detectan que el diálogo de confirmación no aparece — solo el Playwright test lo hace. Ambas capas son necesarias y van en el Validate del R-V-R. Tests y validaciones como ley del codebase.	1, 7	~10 min
5	El bucle cerrado	MODELAR	El patrón: ejecuta → valida → refleja → corrige → re-valida. Demo conceptual: ADW sin bucle (ciego, S4) vs. ADW con bucle cerrado. La diferencia: el segundo sabe si lo hizo bien.	2	~10 min
6	Request-Validate-Resolve	MODELAR	El framework en tres partes para escribir prompts con bucles integrados. “Encode validation as commands”: si lo puedes hacer a mano, el agente lo puede hacer. Validation ordering: top-to-bottom, stop on fail, rerun from start.	3, 4	~12 min
7	Auto-documentación	MODELAR	Tests dan feedback al agente actual. Documentación da feedback a quien viene después: el reviewer del PR, el agente del siguiente issue, el dev que llega en 3 meses. El mecanismo es el mismo: se codifica en el prompt. La sección Request del R-V-R incluye qué documentar (commit messages, PR description, comments en el issue). Ejemplo concreto: commit message genérico (“fix issue #123”) vs. commit message que explica qué se rompió y cómo se arregló.	8	~7 min
8	Lab Demo: El agente que se autocorrige	PRACTICAR	Demo app S5. Progressive Validation Stacking en vivo: (a) linter → agente falla, lee el error, corrige. (b) unit tests → mismo bucle. (c) E2E con Playwright → el agente abre el browser, detecta que el diálogo de confirmación no aparece, corrige el JS, vuelve a pasar. Momento definitorio: el bucle completo funcionando sin intervención humana. Al finalizar la Ronda C, el facilitador señala el commit message que el agente escribió — no dice “fix stuff”, narra exactamente qué estaba mal y cómo lo arregló. Es auto-documentación en acción.	2, 3, 4, 5, 6, 8	~30 min
9	Práctica en proyecto: Cerrar tus bucles	APLICAR	Los equipos añaden validaciones al ADW de S4. Mapean qué validaciones ya tienen, qué falta. Implementan al menos una capa (linter o unit tests) con Request-Validate-Resolve. Además, añaden instrucciones de documentación al Request: commit messages descriptivos, PR description con contexto. El ADW de S4 sale de la sesión capaz de autocorregirse y auto-documentarse.	2, 3, 4, 8	~35 min
10	Reflexión / Resumen	REFLEXIONAR	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: construimos el sistema que construye el sistema, y ese sistema sabe si lo hizo bien y explica lo que hizo. Semilla S6: “El agente se corrige y documenta… pero a veces hace trabajo que no toca. ¿Cómo lo mantienes enfocado?”	—	~10 min
11	Check-out	—	Ritual: cómo se va cada persona	—	~5 min

Lab Demo

Sí. Demo app S5. Progressive Validation Stacking en vivo: el facilitador añade capas de validación (linter → unit tests → E2E con Playwright MCP) a un comando existente de la demo app. En cada capa el agente falla, lee el error, corrige y re-valida — sin intervención humana. El clímax es el E2E: el agente abre el browser, detecta visualmente que algo no funciona (el diálogo de confirmación de borrado no aparece), corrige el JavaScript y vuelve a pasar el test. Es el momento definitorio de la sesión. Al finalizar, el facilitador señala el commit message que el agente escribió — auto-documentación en acción: no dice “fix stuff”, narra exactamente qué estaba mal y cómo lo arregló.

Práctica en Proyecto

Sí. Los equipos añaden validaciones al ADW de S4 usando Request-Validate-Resolve. Mapean qué comandos de validación ya tienen (linters, tests existentes) e implementan al menos una capa nueva. Además, añaden instrucciones de documentación al Request del R-V-R: commit messages descriptivos, PR description con contexto. El ADW de S4 sale de esta sesión capaz de autocorregirse y auto-documentarse. Es la integración más directa del curso: S4 aporta el flujo autónomo, S5 aporta la fiabilidad y la transparencia.

Notes

Conexión S4→S5 explícita: El ADW de S4 + los bucles cerrados de S5 = el primer flujo verdaderamente autónomo Y fiable del equipo. Nombrarlo explícitamente en el recap y en la reflexión.
El momento definitorio ocurre en el bloque 8 (lab demo): el agente falla un E2E test, Playwright mueve el browser solo, el agente lee el screenshot, detecta el error, corrige, pasa. Esto es visceral — priorizar esta demostración sobre cualquier otra.
La pregunta provocativa apunta al gap test/validación: los tests técnicos pasan pero el agente no implementó bien la feature. Es visceral para cualquier dev que haya vivido eso. La sesión responde progresivamente con la distinción tests vs. validaciones.
La distinción tests/validaciones es el concepto diferencial de la sesión — los desarrolladores ya saben testear, lo que no tienen es la validación de comportamiento codificada en sus prompts agénticos. El Playwright moment gana significado: ya no es “más cobertura” sino “la única forma de verificar la intención”.
Progressive Validation Stacking se vive en el lab, no se explica como concepto separado. El nombre puede mencionarse durante la demo para dar vocabulario.
“Tests y validaciones como ley del codebase” se enuncia en el bloque 4 y se refuerza en el bloque 6. No necesita bloque propio.
Auto-documentación se introduce en el bloque 7 como concepto y se refuerza en el lab demo (observar el commit message) y en la práctica (añadir instrucciones de documentación). No necesita bloque extenso — 7 min bastan porque el mecanismo (codificarlo en el prompt) ya se enseñó en R-V-R.
Bloque 9 (Práctica en proyecto) es el más impredecible en tiempo — extenderlo primero si hay margen. Comprimir bloque 4 primero si falta tiempo (el más conceptual/motivacional). Segundo candidato a comprimir: bloque 7 (auto-documentación a ~4 min eliminando el ejemplo en vivo).
Tiempo: 132 min planificados + 18 min margen (12%). Total sesión: ~150 min.
Prerequisito: todos los equipos llegan con un ADW funcional de S4.