Vibe coding con disciplina de producto

El desarrollo asistido por IA ha hecho dramáticamente más fácil convertir una idea en software funcional. Pero la velocidad crea un nuevo problema: un prototipo puede construirse en horas mientras el razonamiento detrás de él (el problema del cliente, los requisitos, las reglas de negocio, la validación y las decisiones técnicas) queda disperso entre prompts, conversaciones, documentos y la memoria de alguien. Eso crea una brecha peligrosa entre "construí algo" y "tenemos un producto". Process OS fue mi exploración de una pregunta simple: ¿cómo se vería el proceso de desarrollo de producto si la IA ayudara a mantener la estructura alrededor del producto, no solo a generar el código?

El desarrollo de producto tradicional crea artefactos de forma deliberada: investigación, requisitos, resúmenes, criterios de aceptación, decisiones de arquitectura. El desarrollo con IA a menudo invierte ese proceso. Alguien describe una idea, la IA genera una interfaz, esa persona reacciona, otro prompt cambia el flujo, otro cambia el modelo de datos. En pocas iteraciones existe un producto sorprendentemente sofisticado, pero la documentación que explica por qué funciona como funciona, muchas veces no.

• Las decisiones de producto quedan enterradas dentro del historial de prompts.
• Los requisitos evolucionan sin una fuente de verdad clara.
• La validación ocurre de manera informal en lugar de sistemática.
• Los equipos de ingeniería heredan prototipos sin suficiente contexto.
• El código generado por IA puede avanzar más rápido que el entendimiento organizacional.
• A los equipos les cuesta distinguir el comportamiento experimental de los requisitos de producto intencionales.

Product manager, diseñador de producto y constructor. Diseñé el marco, construí el producto funcional con Lovable, Claude Code, Codex y Supabase, y creé cada artefacto que el sistema establece.

1. 1.

   Problema de Vibe Coding y Producto en Vivo

   El punto de partida captura el problema que se está resolviendo junto con la aplicación funcional. Eso establece una distinción importante: el prototipo demuestra una posible solución, pero la definición del problema sigue siendo el ancla.

2. 2.

   Resumen de Validación

   Una mirada estructurada a los supuestos detrás del producto: cliente objetivo, puntos de dolor, propuesta de valor, supuestos, riesgos, evidencia y preguntas que aún necesitan validación. El objetivo es evitar que la velocidad del prototipo se confunda con validación de mercado.

3. 3.

   PRD vivo

   En lugar de un documento de requisitos estático escrito antes de empezar a desarrollar, el PRD evoluciona junto con el software. Se mantiene como la fuente de verdad duradera de los objetivos del producto, los problemas del usuario, los flujos, los requisitos funcionales, las reglas de negocio, los casos límite, los criterios de éxito y las consideraciones futuras, permitiendo experimentación rápida sin abandonar la disciplina de producto.

4. 4.

   Biblioteca de Prompts y Lógica

   Los prompts se están convirtiendo en parte del entorno de desarrollo, así que Process OS los trata de esa manera. Los prompts importantes, la lógica del sistema, las decisiones de implementación y las reglas de comportamiento quedan registradas para que futuros constructores puedan entender cómo se construyó el producto y continuarlo sin reconstruir su historia.

5. 5.

   Documentación que emerge del trabajo

   Mi principio guía: la documentación debería surgir del trabajo en lugar de convertirse en trabajo adicional. Cada artefacto informa al siguiente: definir el problema, probar los supuestos, construir el producto, registrar qué cambió, preparar la entrega. El propio prototipo se volvió parte del proceso de investigación, con Lovable, Claude Code, Codex y Supabase permitiéndome moverme rápidamente entre diseño de interfaz, lógica de producto, implementación e iteración mientras refinaba continuamente la definición del producto.

6. 6.

   Del prototipo a la entrega a ingeniería

   La etapa final respondía una pregunta cada vez más relevante: ¿qué necesitaría otro ingeniero para hacerse cargo de este producto mañana con confianza? La entrega documentó la arquitectura del producto, los flujos principales, la lógica de la aplicación, consideraciones de datos, dependencias, limitaciones conocidas, supuestos de implementación y oportunidades futuras. El objetivo no era simplemente hacer que la aplicación funcionara; era hacer el producto transferible.

• El cuello de botella se está moviendo de construir software a mantener la claridad. La IA puede cada vez más producir interfaces, flujos, código y documentación. Pero los equipos todavía necesitan responder: ¿para quién es esto, qué problema estamos resolviendo, qué supuestos están realmente validados, por qué el producto se comporta así, y qué necesitaría otro equipo para continuar el trabajo?
• El pensamiento de producto sólido importa más, no menos. La IA reduce drásticamente el costo de experimentar. Eso convierte al criterio en el diferenciador.
• La documentación viva le gana a la documentación estática. Un PRD escrito meses antes de la implementación se vuelve obsoleto. Los requisitos deberían evolucionar con el producto como una representación continuamente actualizada de la intención actual.
• Decisiones humanas, aceleración de IA. La IA puede sintetizar información, generar especificaciones y acelerar la implementación, pero el criterio de producto sigue siendo humano. El sistema fue diseñado para hacer más visibles las decisiones de producto, no para esconderlas detrás de la automatización.
• Diseña pensando en la entrega. Un prototipo exitoso no debería depender indefinidamente de la persona que originalmente lo creó con prompts. La entrega es un resultado de producto de primer nivel, no una ocurrencia tardía.