Ha sido una tarde intensa. En cuestión de horas hemos levantado y cerrado el MVP del Proyecto Joshua. Sobre el papel, un éxito rotundo a velocidad de vértigo: 16 de 16 historias de usuario completadas en nuestro `sprint-status.yaml`, integrando virguerías técnicas como sombreado geoespacial, consolas de terminal simuladas y voz sintetizada. Todo construido a ritmo frenético usando el framework agentico BMAD.

Pero como ocurre a menudo en la ingeniería de software (y más aún cuando delegas en agentes autónomos), el resultado final esconde un rastro de sangre. Hicimos una retrospectiva honesta, blameless, y lo que encontramos no fue un problema de capacidad de la IA, sino un fallo sistémico en cómo la estábamos guiando.

Caímos de lleno en el **"Hope-Driven Development"** (Desarrollo Guiado por la Esperanza).

El problema de la Amnesia Iterativa

Hicieron falta más de 15 iteraciones esta misma tarde para dar con el resultado esperado en el frontend. ¿Dónde quedó la traza de esos 15 intentos fallidos? En ningún sitio.

Los agentes sufren de Amnesia Iterativa. Al carecer de un registro estricto en los Dev Notes, cada vez que el agente chocaba contra un muro, olvidaba el contexto de los intentos anteriores. Esto nos enseñó una lección de oro: la memoria no emerge por sí sola, hay que forzarla. Si un agente no documenta estructuradamente el Problema, la Causa Raíz y la Solución en cada intento, estás condenado a pagar el coste de inferencia en bucle.

El agente ciego y la "Regla del Screenshot"

El punto de inflexión de Joshua llegó por pura frustración. El agente no era capaz de arreglar problemas visuales en la interfaz porque, sencillamente, no podía verlos.

No fue hasta que le conectamos el MCP de Playwright y le pedimos que sacara secuencias de capturas de pantalla, que la IA hizo click. Por fin entendía por qué el CSS estaba roto. De ahí nació nuestra nueva norma grabada a fuego: La Regla del Screenshot. Si un bug de frontend no se resuelve en 2 iteraciones, se detiene el desarrollo a ciegas y se activa la verificación visual automatizada obligatoria.

Los nuevos Guardarraíles de BMAD

A partir de hoy, nuestro despliegue de BMAD cambia drásticamente para entornos empresariales. Hemos acabado con las autoevaluaciones del agente programador. Se acabaron los "Trust me, bro" sintéticos:

1. Quality Gates estrictos: Prohibido pasar una tarea a `in-progress` sin un scaffold de test de aceptación predefinido (ATDD es ahora innegociable).
2. Separación de Poderes: El agente desarrollador ya no puede marcar una tarea como `done`. Solo puede dejarla en `review-ready` para que un auditor independiente verifique los tests.
3. Trazabilidad obligatoria: Si el Dev Note no explica el por qué de una decisión, el pull request se rechaza.

El dilema de la sincronización

Nos queda un último elefante en la habitación: cómo aplicar estas reglas estrictas, personalizadas para nuestras necesidades de calidad, sin romper la sincronización con el repositorio principal (upstream) de BMAD. Ese es nuestro siguiente gran reto arquitectónico.

Pero de momento, la locura de esta tarde con Joshua nos ha dejado una lección vital: un framework agéntico sin infraestructura de testing rigurosa y sin "ojos" no es un equipo de desarrollo; es una máquina de escribir muy rápida trabajando a oscuras.