Casos de estudio

Documentation Index

Fetch the complete documentation index at: https://ai-first.falcux.com/llms.txt

Use this file to discover all available pages before exploring further.

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

​

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

​

Por qué funcionó

Tres factores convergieron:

1. 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.
2. 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.
3. 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:

1. Documentó qué API quería integrar y qué resultado esperaba
2. Le pidió al agente que implementara la integración
3. Probó el resultado
4. 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

​

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

El patrón común: En los tres casos, la diferencia no fue la herramienta ni el modelo de AI. Fue la calidad del contexto que recibió.

---

​

Cómo usar estos casos

​

Para justificar la inversión ante stakeholders

El caso de AutenTIC Sign tiene los números más claros: 2h vs 1 sprint. Eso es ~97% de reducción de tiempo en una tarea específica y acotada. No todos los features van a tener esa mejora, pero demuestra el techo.

​

Para convencer a un equipo escéptico

El caso de los 5 restarts es el más identificable. Casi todo developer que ha usado AI coding agents tiene una versión de esta historia. “Yo también reinicié 3 veces” genera empatía inmediata y abre la conversación sobre qué hacer diferente.

​

Para expandir quién usa AI

El caso del PO demuestra que no es una herramienta solo para developers. Útil para convencer a POs y designers de que la metodología también les da superpoderes.