La IA puede generar un MVP funcional en una tarde. Esa solía ser la parte difícil; ya no lo es, y seguir actuando como si lo fuera arruina tu roadmap sin que lo notes.
Lo difícil ahora es el criterio: de todo lo que podrías construir en una tarde, ¿qué merece de verdad el tiempo de ingeniería de un sprint? Lo aprendí caro: metí una tanda de prototipos generados con IA directo a los sprints y la mitad se estancó. Funcionaban. Simplemente no importaban.
Así que ahora, antes de darle tiempo de sprint a algo, le paso tres preguntas:
1. ¿Alguien fuera del contexto puede decir qué resuelve en una sola frase?
Enséñale el demo a un colega que no estuvo en la sala. Si no puede enunciar el problema sin tu narración, el alcance todavía no es real: es una superficie convincente sobre un núcleo indefinido.
2. ¿Hay una métrica falsable escrita antes del sprint?
"A la gente le va a encantar" es una vibra, no una métrica. "El 40% de los usuarios de prueba llega a la acción principal sin ayuda" es algo en lo que puedes equivocarte, y eso es justo lo que lo hace útil.
3. ¿Cuál es el supuesto que, si es falso, vuelve todo inútil?
Nómbralo y pruébalo primero. La mayoría de los MVP con IA no mueren por la ingeniería difícil; mueren por una premisa que nadie se molestó en escribir.
Pasa las tres y se gana el tiempo de sprint. Falla una y vuelve al prompt para otra pasada; ahora que generar una versión nueva cuesta una tarde en lugar de un mes, eso es genuinamente barato.
Terminé encadenando esto en un flujo repetible (prompt → MVP → puerta de validación) para no rediscutirlo en cada planificación. Si te interesa cómo está armado, lo documento en https://nxcode.io.
Las herramientas abarataron construir. Lo escaso ahora es decidir qué vale la pena construir; ahí prefiero gastar el criterio.
¿Qué filtros usan ustedes antes de que un prototipo con IA se gane horas reales de ingeniería?
Top comments (0)