--- title: "Vibe coding: qué pasa con el primer cliente" description: "Qué se rompe primero en una aplicación generada con IA cuando deja de usarla su autor, en qué orden pasa y qué se hace con cada cosa." canonical: https://caricalia.com/notas/vibe-coding-primer-cliente last-updated: 2026-09-08 --- # Vibe coding: qué pasa con el primer cliente > Las aplicaciones generadas con IA no se caen a la vez. Se rompen en un orden predecible, y casi siempre por sitios que nadie decidió. Publicado: 2026-09-08 Autor: carlos Temas: vibe coding, producción --- ## Qué pasa el primer día Nada. El primer cliente entra, usa la aplicación y funciona, porque hace exactamente lo que hacía cuando la probaste tú. Lo que cambia ese día es que ya hay alguien que no puede esperar a mañana. Las cosas empiezan a romperse a las pocas semanas. Se rompen porque hay decisiones que nadie tomó, ni tú ni el modelo, y que solo aparecen cuando hay dos personas dentro a la vez. Esto no va de si generar código con IA está bien o mal. Nosotros lo usamos todos los días. Va de qué falta cuando lo único que has pedido es que funcione. Si buscas la definición del término, está en [vibe coding](/glosario/vibe-coding). ## El orden en que se rompe Se rompe antes lo que solo falla con más de un usuario, y después lo que solo falla con dinero de por medio. Lo que falla con el tiempo tarda más, y lo último en aparecer es lo que solo se nota cuando alguien mira desde fuera. ### 1. La autenticación va para uno y no para muchos Con un usuario, cualquier cosa parece una sesión. Con varios aparecen las preguntas que no se hicieron: cuánto dura la sesión, cómo se expulsa a alguien que se ha ido de la empresa, qué ve un usuario si escribe en la barra de direcciones el identificador de otro. Ese último caso es habitual: la pantalla comprueba qué te enseña, pero la consulta a la base de datos no comprueba de quién son los datos. Con una sola cuenta es invisible. ### 2. Los datos se guardan dos veces El cliente pulsa dos veces porque la primera tardó. Se crean dos pedidos. Nadie decidió qué debía pasar ahí. La versión cara es cuando la duplicación no se ve: dos registros idénticos con identificadores distintos, que luego se suman en un informe y cuadran mal por una cifra que nadie sabe de dónde sale. ### 3. Los pagos cobran pero no registran El cobro se hace fuera, en la pasarela, y funciona. Lo que falta es lo que pasa después: la pasarela avisa de que ha cobrado y ese aviso llega una vez, o llega tres veces, o llega cuando la aplicación estaba reiniciándose. Sin nada que reconcilie las dos partes, la cuenta de la pasarela y la de tu base de datos se separan despacio. Se descubre cuadrando el mes, cuando ya hay que devolverle dinero a alguien. ### 4. El correo sale de una cuenta personal Funciona hasta que el volumen sube y todos los envíos salen de la misma dirección personal. A partir de ahí, parte de los avisos acaba en spam sin que nadie lo vea, porque no se comprueba si el correo se entregó. ### 5. Las claves están en el código Las contraseñas de la base de datos y las llaves de la pasarela de pago, escritas dentro de los ficheros. Aguanta mientras el repositorio sea privado y lo abras solo tú. Deja de aguantar el día que entra una persona nueva, o que el repositorio deja de ser privado. Entonces hay que cambiarlas todas, y como nadie sabe cuántos sitios las usan, cambiarlas rompe cosas. ### Y una sexta que llega más tarde Nadie sabe qué había ayer. No hay copias de seguridad, o las hay y nunca se ha restaurado ninguna. Se descubre el día que hace falta. ## Síntoma, causa y qué se hace | Síntoma | Causa | Qué se hace | |---|---|---| | Un cliente ve datos de otro | La consulta filtra en la pantalla, no en la base de datos | Se mueve la comprobación de permisos al acceso a datos y se prueba con dos cuentas | | Pedidos repetidos | Sin clave única ni control de reintentos | Clave única de negocio y operaciones que se pueden repetir sin duplicar | | La pasarela y tu base de datos no cuadran | El aviso de cobro se procesa una vez, o ninguna, o tres | Registro de cada aviso recibido, reintentos y un cuadre que se ejecuta solo | | El cliente dice que no le avisaste | Envío desde cuenta personal, sin registro de entregas | Dominio propio con su configuración de envío y registro de qué se entregó | | Hay que cambiar una clave y da miedo | Credenciales escritas en el código | Claves fuera del código, rotables, y un inventario de dónde se usa cada una | | Nadie sabe qué había ayer | Sin copias de seguridad probadas | Copias automáticas y una restauración hecha delante del cliente | ## Por qué no es culpa de quien lo montó Porque nadie le pidió eso. Lo que pediste fue una aplicación que hiciera algo, y la tienes. Ninguna de las seis cosas de arriba aparece en la conversación con un modelo salvo que las nombres tú, y para nombrarlas hay que haberlas sufrido antes. La primera versión de un producto es hoy la parte barata. Lo caro sigue siendo el segundo año, cuando hay clientes que ya no se pueden perder. ## Qué hacemos con eso Leerlo primero. Antes de decir si sirve o no sirve, abrimos lo que hay: la aplicación, la base de datos, lo que alguien está arreglando a mano cada semana y lo que ya se rompió una vez. Casi nunca hay que tirarlo. Lo que montaste tiene dentro las decisiones reales de tu negocio, y eso no está escrito en ningún otro sitio. Qué se conserva y qué se cambia está contado, con el orden en que se hace, en [de prototipo a producción](/de-prototipo-a-produccion). Y si todavía no tienes clientes, quédate donde estás. ## Por dónde empezar mañana Coge tu aplicación y prueba las tres primeras a mano. Entra con dos cuentas distintas y cambia el identificador en la dirección. Pulsa dos veces el botón de pagar. Busca las claves con un buscador de texto en el repositorio. Si alguna te da un resultado que no te gusta, ya sabes por dónde va la conversación. Si prefieres que lo miremos con el sistema delante, eso es [un diagnóstico](/diagnostico).