Del vibe coding al producto real: la parte difícil empieza cuando la app funciona

Crear una aplicación con IA puede llevar un fin de semana. Crear un producto en el que alguien confíe para pagar, guardar sus datos y volver mañana es un problema completamente distinto.

El *vibe coding* ha reducido de forma espectacular la distancia entre una idea y algo que funciona. Podemos describir una aplicación, generar una interfaz, conectar una base de datos y desplegar una primera versión sin dominar cada detalle técnico de la implementación.

Es un cambio enorme y, en mi opinión, muy positivo. Personas que antes no podían convertir sus ideas en software ahora pueden experimentar con ellas. Los desarrolladores podemos explorar alternativas con mucha más velocidad. Los equipos pueden enseñar algo concreto antes de invertir meses en construirlo.

Pero esa velocidad también puede ocultar una diferencia importante: una aplicación funcional no es necesariamente un producto.

La demo demuestra que una idea puede ejecutarse. El producto tiene que demostrar que puede sostenerse cuando lo utilizan personas reales, con datos reales, expectativas reales y problemas que no estaban en el guion.

Una demo funciona cuando todo sale bien

La primera versión de una aplicación suele estar construida alrededor del camino feliz.

El usuario completa todos los campos correctamente, la conexión no se interrumpe, el proveedor externo responde a tiempo, el pago se confirma, el proceso termina y la pantalla siguiente aparece como estaba previsto.

En esas condiciones, muchas aplicaciones parecen terminadas.

La realidad empieza cuando alguien pulsa dos veces el mismo botón. Cierra el navegador a mitad de un proceso. Introduce un dato inesperado. Pierde la conexión. Intenta acceder desde un móvil antiguo. Vuelve una semana después. Paga, pero uno de los servicios posteriores falla.

Ninguno de estos casos resulta especialmente atractivo en una demostración, pero todos forman parte del producto.

Una demo responde a la pregunta «¿puede funcionar?». Un producto debe responder también a otras:

• ¿Qué ocurre cuando algo falla?
• ¿Puede recuperarse sin perder información?
• ¿Entiende el usuario qué está pasando?
• ¿Podemos descubrir la causa del problema?
• ¿Es seguro volver a ejecutar la operación?
• ¿Puede el negocio asumir su coste de forma repetida?

El salto entre prototipo y producto se encuentra, en gran parte, dentro de esas preguntas.

El ejemplo de una generación en Buklea

En Buklea, una familia puede crear un cuento personalizado con inteligencia artificial. Desde fuera, el flujo parece sencillo: el usuario aporta algunos datos, el sistema genera una historia y el resultado aparece listo para leer.

Ese es el camino feliz. Detrás hay un proceso bastante más largo.

Hay que preparar la historia, generar distintas escenas, mantener la consistencia de los personajes, procesar imágenes, guardar resultados y construir los formatos de lectura. Algunas operaciones dependen de proveedores externos, cuestan dinero y pueden tardar varios minutos.

¿Qué pasa si se generan diecinueve páginas y falla la última? ¿Debemos empezar de nuevo y pagar dos veces todo el proceso? ¿Qué ocurre si el usuario cierra la aplicación mientras espera? ¿Y si actualiza la página o pulsa otra vez el botón porque parece que no está sucediendo nada?

Resolver el camino feliz permite enseñar la aplicación. Resolver estas situaciones es lo que permite cobrar por ella con responsabilidad.

El sistema necesita conocer el estado de cada trabajo, conservar los resultados que ya son válidos, reintentar únicamente lo necesario y evitar que una misma petición se ejecute dos veces. El usuario debe poder marcharse y encontrar su cuento más tarde, sin depender de mantener una pestaña abierta.

Nada de esto cambia la idea principal del producto. Sin embargo, determina si la experiencia transmite confianza o frustración.

Los errores dejan de ser excepciones

En un prototipo, un error puede resolverse recargando la página o modificando manualmente un dato. En producción, los errores son una parte normal del sistema.

Una API puede devolver una respuesta incompleta. Un modelo puede rechazar una generación. Una tarea puede superar su tiempo límite. Un servicio puede estar disponible y degradarse unos minutos después. Incluso nuestro propio código puede encontrarse con una combinación que nunca habíamos previsto.

La cuestión no es conseguir que nada falle. Eso no es realista. La cuestión es diseñar cómo falla el producto.

Un sistema preparado para producción suele necesitar:

• estados explícitos para los procesos largos;
• reintentos limitados y seguros;
• operaciones idempotentes que no dupliquen pagos o trabajos;
• conservación de resultados parciales;
• mensajes comprensibles para el usuario;
• una vía de recuperación cuando la automatización no puede continuar.

Estas decisiones apenas se ven cuando todo funciona. Precisamente por eso es fácil posponerlas mientras construimos a gran velocidad.

Guardar datos no es lo mismo que cuidarlos

Conectar una base de datos es hoy relativamente sencillo. Decidir qué guardar, durante cuánto tiempo, quién puede consultarlo y cómo recuperarlo exige bastante más criterio.

Cuando una aplicación empieza a manejar información de usuarios, aparecen responsabilidades que no existían en la demo. Hay que controlar permisos, validar entradas, proteger secretos, crear copias de seguridad y pensar qué sucede cuando alguien solicita eliminar sus datos.

En productos que trabajan con fotografías de menores, como Buklea, estas preguntas son especialmente importantes. Una imagen no es solamente un archivo necesario para completar una generación. Es información sensible que debe tratarse con una finalidad clara y durante el tiempo estrictamente necesario.

La IA puede generar rápidamente el código que sube una fotografía a un servicio de almacenamiento. No puede decidir por sí sola cuál debe ser la política del producto ni asumir las consecuencias de una mala decisión.

Pasar a producción significa dejar de pensar únicamente en lo que el sistema puede hacer con los datos y empezar a limitar deliberadamente lo que debería hacer.

El coste debe funcionar también a escala

Una demo necesita completar el proceso una vez. Un producto debe hacerlo de manera repetida y con una economía sostenible.

Esta diferencia importa especialmente en aplicaciones de IA generativa. Cada texto, imagen, audio o vídeo puede implicar un coste variable. Una arquitectura que parece económica durante las pruebas puede dejar de serlo cuando llegan más usuarios, aparecen reintentos o cada resultado requiere varias generaciones descartadas.

Por eso no basta con saber cuánto cuesta una llamada al modelo. Hay que entender el coste de una experiencia completa:

• cuántas operaciones necesita un resultado;
• cuántas fallan o se repiten;
• qué recursos pueden reutilizarse;
• cuánto cuesta almacenar y servir el contenido;
• qué parte del proceso puede ejecutarse con modelos más pequeños;
• qué margen queda después de pagos, impuestos y soporte.

Optimizar no siempre significa elegir el modelo más barato. También puede consistir en evitar trabajo duplicado, reutilizar resultados válidos, reducir el tamaño de los recursos o reservar los modelos más capaces para los pasos donde realmente aportan valor.

Si cada nuevo usuario genera una pérdida, tener más usuarios no arreglará el producto.

Sin observabilidad, cada incidencia es un misterio

Durante el desarrollo podemos mirar la terminal, repetir una acción y seguir el rastro del error. Cuando el producto está en manos de otras personas, esa visibilidad desaparece.

Un mensaje como «mi cuento no se ha generado» no explica qué parte falló, qué proveedor intervino, cuánto avanzó el proceso ni si es seguro intentarlo de nuevo.

Para operar un producto necesitamos poder reconstruir lo ocurrido. Eso implica registrar eventos relevantes, relacionarlos con una operación concreta, medir tiempos y recibir alertas cuando un comportamiento se aleja de lo normal.

La observabilidad no es una sofisticación reservada a sistemas enormes. Es lo que permite responder preguntas básicas:

• ¿Está fallando un usuario o están fallando todos?
• ¿El problema está en nuestro código o en un proveedor?
• ¿Cuánto tiempo lleva bloqueado el proceso?
• ¿Se ha cobrado la operación?
• ¿Podemos recuperarla sin empezar desde cero?

Sin estas respuestas, el equipo no opera el producto: reacciona a ciegas.

La interfaz también debe explicar la incertidumbre

Muchos prototipos están diseñados como si todas las acciones fueran inmediatas. El usuario pulsa un botón y aparece un resultado.

Los productos basados en IA no siempre funcionan así. Algunos procesos tardan, pueden degradarse o producen resultados que necesitan una segunda revisión. La experiencia debe representar esa incertidumbre.

No basta con mostrar un indicador de carga. Conviene explicar qué está ocurriendo, permitir que el usuario continúe con otra tarea, conservar el progreso y comunicar con claridad cuándo debe intervenir.

También hay que diseñar estados vacíos, errores, permisos denegados, resultados parciales y contenido que supera las dimensiones previstas. Son pantallas menos vistosas que la principal, pero probablemente sean las que más influyan en la confianza.

Una buena experiencia no finge que el sistema es infalible. Hace que sus límites sean comprensibles y recuperables.

Cada funcionalidad crea una obligación

Con herramientas de IA resulta tentador añadir una funcionalidad porque implementarla parece cuestión de unas horas. El coste inicial ha bajado, pero la responsabilidad permanece.

Una vez publicada, esa funcionalidad tendrá que:

• seguir funcionando cuando cambien sus dependencias;
• convivir con nuevas versiones del producto;
• explicarse en la interfaz y en el soporte;
• medirse para saber si aporta valor;
• protegerse frente a usos no previstos;
• migrarse o retirarse si deja de tener sentido.

El código generado también pasa a formar parte del sistema. Alguien deberá entenderlo, revisarlo y modificarlo en el futuro. Si cada nueva pieza utiliza un patrón distinto o resuelve el mismo problema de otra manera, la velocidad inicial se transforma poco a poco en fricción.

La mantenibilidad no exige que un prototipo nazca con la arquitectura definitiva. Sí exige reconocer qué partes son experimentales y cuáles empiezan a convertirse en infraestructura del producto.

Qué puede hacer la IA y qué sigue siendo nuestra responsabilidad

Los agentes de código pueden ayudar en casi todas estas áreas. Pueden escribir pruebas, revisar permisos, añadir registros, detectar casos límite, preparar migraciones y proponer una arquitectura más resistente.

El error sería concluir que, como pueden ejecutar ese trabajo, ya no necesitamos dirigirlo.

Un agente no conoce automáticamente el nivel de riesgo aceptable, la promesa que hemos hecho al usuario, el coste que soporta el negocio o los datos que consideramos especialmente sensibles. Tampoco puede saber qué compromisos queremos aceptar para lanzar antes.

La capacidad más importante no es escribir cada línea manualmente. Es establecer buenos criterios:

• qué debe ocurrir para considerar una operación completada;
• qué datos no podemos permitirnos perder;
• qué acciones deben ser reversibles;
• dónde necesitamos intervención humana;
• qué fallos podemos tolerar y cuáles deben generar una alerta;
• qué evidencia necesitamos antes de ampliar el uso.

La IA acelera la implementación de esas decisiones. No elimina la necesidad de tomarlas.

Un checklist para cruzar la distancia

Antes de considerar que una aplicación está preparada para convertirse en producto, conviene revisar al menos estas preguntas:

1. Camino feliz: ¿la propuesta principal resuelve de verdad un problema y se entiende? 2. Errores: ¿qué puede fallar en cada paso y cómo se recupera? 3. Persistencia: ¿el usuario puede cerrar la aplicación y continuar después? 4. Duplicados: ¿repetir una acción puede cobrar, enviar o generar dos veces? 5. Seguridad: ¿cada persona accede únicamente a los datos que le corresponden? 6. Privacidad: ¿guardamos solo lo necesario y podemos eliminarlo correctamente? 7. Costes: ¿conocemos el coste real por experiencia completada, incluidos los fallos? 8. Observabilidad: ¿podemos reconstruir una incidencia sin pedir al usuario que la repita? 9. Soporte: ¿existe una salida cuando el sistema no puede resolver el problema automáticamente? 10. Mantenimiento: ¿podremos entender y modificar esta parte dentro de seis meses?

No todas las respuestas tienen que ser perfectas antes de lanzar. Un producto pequeño no necesita la infraestructura de una gran plataforma. Pero los riesgos deben ser decisiones conscientes, no huecos que todavía no hemos descubierto.

La parte difícil empieza cuando la app funciona

El *vibe coding* es una forma extraordinaria de empezar. Reduce el coste de explorar una idea, permite aprender construyendo y abre el desarrollo de software a muchas más personas.

Su límite no está en la calidad de la primera demo. Está en confundir esa demo con el final del trabajo.

Un producto real no se define solamente por lo que hace cuando todo va bien. Se define por cómo protege los datos, cómo responde cuando algo falla, cómo sostiene sus costes y cómo permite que el equipo siga mejorándolo después del lanzamiento.

La IA ha reducido enormemente el coste de escribir software. Ahora podemos llegar mucho antes al punto donde empiezan las decisiones de ingeniería, producto y operación que construyen la confianza.

La app funciona. Ese no es el final. Es el momento en el que empieza el producto.