¿Por qué los prompts y las historias de usuario ya no bastan para crear con IA?.
Hasta hace poco, la manera de escribir requisitos eran las historias de usuario.
Esto funcionó durante años hasta que apareció el Vibe Coding: la creación de aplicaciones con IA, sin conocimientos técnicos.
Entonces comenzamos a especificar qué queríamos que creara la IA con Prompts.
Pero si hoy creas aplicaciones vía Prompt, habrás observado el problema:
- Si el Prompt es pequeño la IA crea de manera anárquica.
- Si es gigante se vuelve imposible de mantener.
Escalar este modelo a nivel profesional es imposible.
PEROOO en estos tiempos que corren (tan rápido) alguien tenía que inventar una manera de profesionalizar esto.
Y cuidado🚨 «Dark Side Alert» 🚨… porque esta «nueva» solución ha traído de vuelta a un Oscuro y viejuno fantasma del pasado…
Al final te cuento cómo detectarlo antes de que sea demasiado tarde.
PEROOO antes, necesitas entender esto…
El patrón que siempre se repite
La tecnología con la que creamos software condiciona cómo los humanos gestionamos su creación.
Y por ello, cómo le pedimos a los programadores lo que queremos que creen.
Los 90s y 2000: Especificaciones detalladas
Documentos enormes con reglas de negocio, flujos, casos de uso, arquitectura… todo escrito antes de programar.
¿Por qué? Porque había que «acertar a la primera».
El software iba en soportes físicos. Un error era extremadamente costoso de solucionar.
Los 2010: Historias de usuario
Textos cortos que buscaban la conversación por encima de la especificación pormenorizada.
¿Por qué el cambio? Dos razones:
- Ecribir al detalle fallaba por la incertidumbre.
- El SaaS, la nube, nos permitía iterar rápido y barato.
El patrón está claro: cada cambio tecnológico exige un nuevo modelo de gestión.
El hoy: ¿Cuál es el modelo?
Si ahora hay «programadores» que son IAs, si ha vuelto a cambiar el paradigma tecnológico radicalmente…
¿Cuál es el nuevo modelo?
Spoiler: los prompts NO son la respuesta para temas serios. Y aquí está el porqué…
El problema de crear con Prompts
La IA crea aplicaciones en minutos que antes llevaban días o semanas.
En el nivel amateur (Vibe Code), pedimos cosas vía prompt.
Esto es excelente para prototipos, experimentos personales, software casero, la app para que el niño estudie, impresionar al cuñao, esas cosas. PEROOO…
El problema real
Prompt: «Crea una app para vender figuras de Marvel.»
IA: ella decide cómo resolver el problema técnicamente: arquitectura, estilo, lenguaje.
Y si tu tienda Marvel tiene éxito y quieres añadir funcionalidades, acabarás con prompts gigantes imposibles de gestionar.
Los 3 problemas fundamentales de usar solo Prompts
- No guían sobre el cómo técnico: decisiones de arquitectura, patrones de diseño, estructura del código.
- Son complicados de versionar: ¿Cuál es la versión 2? ¿Cuál es la diferencia entre v1 y v2? Un equipo no puede trabajar así.
- Son instrucciones ad-hoc: habría que especificar funcionalidad, restricciones, pruebas de aceptación.
Las historias de usuario siguen siendo válidas pero ya no son suficientes. Con una IA, dejan demasiadas puertas abiertas.
Entonces, si ni prompts ni historias de usuario SON SUFICIENTES… ¿qué HACEMOS?
La solución (por ahora): Las Specifications (Specs)
La comunidad tech internacional, liderada por empresas como GitHub y AWS, etc., ha propuesto un nuevo modelo: las Specifications, o Specs.
¿Qué son las Specs?
Ficheros en texto plano con estructura predefinida que acotan lo que la IA debe crear y actúan como «la única fuente de verdad».
¿Qué las hace especiales?
- Controlan el QUÉ, no el CÓMO: definen qué debe hacer la aplicación, sus reglas de negocio, sus límites.
- Las entienden todos por igual: personas no técnicas, técnicas e IAs. Mismo lenguaje.
- Resultados consistentes: pides lo mismo dos veces, obtienes soluciones similares.
- Versionables y colaborativas: cambias una sección, guardas en Git, sabes exactamente qué cambió.
PEROO ojo, porque una Spec NO es solo un documento bonito. Tiene una anatomía…
- User Scenarios & Testing: HU, validación, prioridad, criterios de aceptación.
- Requirements funcionales: cómo esperamos que el sistema se comporte.
- Success Criteria: outcomes medibles.
- Headers: información contextual.
Y ahora OJO, que ahora viene la trampa en la que están cayendo el 90% de los equipos que las mal adoptan…
El Lado Oscuro de todo esto
Pues ahora que viene el Carnaval: que Vuelve el Viejuno Cascada disfrazado de moderno (de IA).
Si me conoces sabrás que siempre digo que el Cascada se cuela siempre (y en tiempos IA no iba a ser diferente).
Siempre está vivo. Y ahora, en tiempos de IA y Vibe Coding, vuelve.
Porque NO es lo mismo un Spec que agrupe 5 funcionalidades que uno con 50.
Por muy moderno que suene «Spec», por muy IA que suene, el de 50 es Cascada.
Y acotar mucho alcance funcional a medio-largo plazo tiene un problema gordo:
Evitas el aprendizaje que supone liberar
poco a poco e ir aprendiendo de ello.
¿Os suena familiar?
PD. Te dejo unas notas de mi cuaderno a MANO (no IA) y que compartí con el grupo de WhatsApp.
El grupo de WhatsApp es un formato más dinámico, con audios e imágenes donde te comparto cosas breves, que son difícil compartir en un correo o en un vídeo de YouTube.
Si te animas es AQUI y es GRATIS
(Por si no nos conocemos.
Soy la persona que revolucionó cómo trabajan hoy los equipos en las empresas de negocios digitales de España y Latinoamérica.
Divulgando en Keynotes, en mi blog y en mi canal de YouTube, he creado un movimiento que ha modernizado la gestión y que ayudó a dejar atrás el lado oscuro de los modelos de gestión obsoletos, más propios de la era industrial.
He formado directamente a más de 100.000 profesionales y he trabajado con más de 600 equipos.
Tengo una estancia de investigación postdoctoral en EE. UU., becado por Carnegie Mellon, un doctorado cum laude y soy ingeniero).
Inspírate y apren más en mi canal de YouTube: