Casos de estudio
Tres casos reales que fundamentan Blueprint AI-First. Cada uno ilustra un punto diferente de la metodología.
Caso 1: Los 5 restarts — el origen de la cadena de artefactos
Contexto
Un product designer con experiencia en UX decide explorar AI coding agents para construir MVPs. Su objetivo: validar si una sola persona puede construir un producto funcional usando AI como builder principal. Stack: Next.js + NestJS + Prisma + Supabase + Shadcn UI. Herramienta: Claude Code (terminal). Experiencia previa con AI coding agents: Ninguna.Qué hizo
El designer inicializó un proyecto con su stack, escribió una descripción breve de la idea, y le pidió al agente que implementara. El flujo era directo: describir → generar → probar → ajustar. No había PRD. No había documento de arquitectura. No había archivo de contexto para la AI. No había guía de diseño. Solo una idea y un prompt.Qué pasó
Primer intento: La AI generó una interfaz que se veía completa. Menús, botones, formularios, navegación. Al probar, la mayoría era decorativo — botones sin funcionalidad, formularios que no enviaban, menús que no navegaban. Al pedir que implementara las features reales, la AI cambiaba el diseño con cada iteración. Segundo intento: Restart completo. Esta vez, el designer dio más contexto en el prompt inicial. Funcionó mejor al principio, pero al tercera sesión la AI había perdido contexto de lo implementado anteriormente. Features nuevas aparecían en la UI sin funcionalidad, mientras features anteriores dejaban de funcionar. Tercer y cuarto intento: Más restarts. Cada vez el designer intentaba dar más contexto, pero siempre llegaba un punto donde la AI no podía mantener la coherencia entre lo existente y lo nuevo. Quinto intento: El designer cambió de enfoque. En vez de darle contexto en el prompt, creó documentos previos: un PRD describiendo qué se construía, un archivo de contexto con las reglas del proyecto, y una estructura de carpetas clara. La AI recibió estos documentos al inicio de cada sesión. El quinto intento funcionó. No porque la AI fuera diferente, sino porque tenía contexto persistente que no dependía de la conversación.Datos
| Métrica | Valor |
|---|---|
| Intentos (restarts) | 5 |
| Tiempo total invertido | ~2 sprints |
| Tiempo productivo real | Último intento (~20% del total) |
| Causa raíz | Falta de artefactos de contexto persistente |
| Solución | Cadena de artefactos: PRD → Arquitectura → AGENTS.md |
Lección para la metodología
Capítulo que ilustra: Capítulo 3 — La cadena de artefactos. La AI no “olvida” — simplemente no tiene acceso a lo que no se le dio. Cada sesión empieza sin memoria de la anterior. Sin documentos persistentes, cada sesión es un restart parcial. La cadena de artefactos no es burocracia — es memoria externa para un agente que no tiene memoria propia. Anti-patrón documentado: Implementar directamente desde una descripción verbal sin documentación previa. Principio extraído: “El costo de documentar siempre es menor que el costo de reiniciar.”Caso 2: AutenTIC Sign — 2 horas vs. 1 sprint
Contexto
Un equipo de tres personas necesita implementar una mejora en su producto de firma electrónica. El cliente solicita replicar una experiencia de usuario que ya existe en otro módulo de la aplicación. Equipo: Product designer (líder), product owner, tech lead. Stack: Angular + PrimeNG (producto existente). Herramienta: Claude Code. Estado del proyecto: Producto en producción con documentación completa — PRD, specs por módulo, guía de diseño, archivo de contexto para la AI.Qué hicieron
El equipo configuró la sesión de Claude Code con el contexto del proyecto: AGENTS.md con las reglas del producto, referencia a las specs del módulo que se iba a modificar, y la guía de diseño con los patrones visuales existentes. El requerimiento era claro: replicar una experiencia que ya existía en otro módulo. La spec estaba escrita. Los patrones de diseño estaban documentados. La arquitectura era conocida. Los tres trabajaron juntos en la sesión: el PO validaba que el comportamiento fuera correcto, el tech lead revisaba la calidad técnica, y el designer verificaba la consistencia visual.Qué pasó
En 2 horas, la mejora estaba implementada, probada, y lista para producción. La AI generó código que seguía los patrones existentes porque los tenía documentados en el AGENTS.md y la guía de diseño. No hubo inconsistencias de UI porque los patrones estaban explícitos. No hubo sorpresas de arquitectura porque la estructura estaba documentada. El equipo estimó que sin AI, la misma mejora hubiera ocupado un sprint completo: estimación, diseño detallado, desarrollo, testing, iteración con el cliente.Datos
| Métrica | Con AI + docs | Sin AI (estimado) |
|---|---|---|
| Tiempo total | 2 horas | 1 sprint (~2 semanas) |
| Personas involucradas | 3 (simultáneo) | 2-3 (secuencial) |
| Restarts | 0 | N/A |
| Inconsistencias de UX | 0 | N/A |
| Documentación previa | Completa | N/A |
Por qué funcionó
Tres factores convergieron:- Documentación completa previa. El proyecto tenía PRD, specs, guía de diseño, y AGENTS.md. La AI no tuvo que adivinar nada.
- Requerimiento claro y acotado. “Replicar esta experiencia en este otro módulo” no deja espacio para ambigüedad. La AI sabía exactamente qué producir.
- Tres roles validando en tiempo real. Producto, técnica, y diseño revisaban simultáneamente. Los errores se atrapaban en segundos, no en días de review.
Lección para la metodología
Capítulos que ilustra: Capítulo 1 (ROI medible), Capítulo 4 (AGENTS.md como cerebro), Capítulo 10 (protocolo de features). El caso demuestra que la inversión en documentación previa tiene un retorno medible: la misma tarea que toma un sprint sin contexto documentado toma 2 horas con contexto completo. Principio extraído: “La AI implementa a la velocidad del contexto que recibe.”Caso 3: El PO y los POCs de integración — AI como acelerador de validación
Contexto
El product owner de un equipo de desarrollos a la medida necesita validar la viabilidad técnica de integrar APIs externas para un cliente. Son pruebas de concepto (POCs) — no producción, sino validación rápida de que la integración funciona antes de comprometer un sprint de desarrollo. Rol: Product owner (no developer). Herramienta: AI coding agent. Objetivo: Demostrar que la integración es viable en horas, no en días.Qué hizo
El PO, sin ser developer, usó un AI coding agent para implementar POCs de integración de APIs. Su flujo:- Documentó qué API quería integrar y qué resultado esperaba
- Le pidió al agente que implementara la integración
- Probó el resultado
- Iteró hasta tener un POC funcional
Qué pasó
El PO logró implementar POCs funcionales que demostraban la viabilidad de las integraciones. Esto permitió al equipo tomar decisiones de producto informadas sin esperar a que un developer construyera la prueba. El tiempo de validación se comprimió de días (esperar a que un developer tenga disponibilidad) a horas (el PO lo hace directamente).Datos
| Métrica | Con AI | Sin AI |
|---|---|---|
| Quién implementa | PO directamente | Developer (cuando tiene disponibilidad) |
| Tiempo de validación | Horas | Días (depende del backlog del dev) |
| Costo de oportunidad | Bajo (PO tiene autonomía) | Alto (developer detenido de otras tareas) |
| Calidad del POC | Suficiente para validar | Más robusta pero innecesaria para un POC |
Lección para la metodología
Capítulo que ilustra: Capítulo 2 (AI-First no es solo para developers), Capítulo 11 (adopción por roles). Este caso demuestra que AI-First no es exclusivo de developers. Un PO con specs claras puede producir POCs funcionales que aceleran decisiones de producto. El rol del PO no cambia (sigue definiendo qué se construye), pero gana una herramienta para validar viabilidad sin depender del backlog de desarrollo. Principio extraído: “AI-First reduce la barrera de quién puede construir software, pero no la barrera de quién debe decidir qué construir.” Precaución: Los POCs del PO son para validación, no para producción. Cuando la decisión es “sí, esto es viable”, la implementación de producción la hace el equipo de desarrollo con la cadena de artefactos completa.Resumen comparativo
| Caso | Sin metodología | Con metodología | Factor clave |
|---|---|---|---|
| 5 restarts | 2 sprints perdidos | Último intento exitoso | Cadena de artefactos |
| AutenTIC Sign | 1 sprint (estimado) | 2 horas | Documentación completa previa |
| POCs del PO | Días (esperar al dev) | Horas (PO autónomo) | AI accesible a roles no-dev |