Cada demo de vibe coding es una historia del Día Uno. Un prompt, una aplicación que funciona, una pantalla que parece lista para lanzarse. El problema es que el software no vive en el Día Uno. Vive en el Día Dos, cuando los usuarios reales inician sesión, los datos dejan de ser ejemplos y alguien tiene que cambiar algo sin romper todo lo demás. Ese es el día en que la demo y el producto resultan ser objetos distintos.
Por qué el Día Dos es una maquinaria diferente
El Día Uno le pide al modelo que escriba sobre un lienzo en blanco, algo en lo que es muy bueno. El Día Dos le pide que modifique un sistema que solo recuerda parcialmente, y ahí es donde falla. El vibe coding sigue siendo una capa de abstracción, no un escape del desarrollo de software: no estás escribiendo sintaxis, pero sigues gestionando estados, diseñando esquemas relacionales y manejando casos límite, porque la IA te ha transferido esa complejidad en lugar de eliminarla.
El artefacto se degrada a medida que crece. Una vez que la base de código supera la ventana de contexto del modelo, este empieza a olvidar sus propias decisiones estructurales y propone código que contradice patrones anteriores. El contexto limitado también implica que reescribe funciones utilitarias que no puede ver en ese momento, dejando lógica duplicada dispersa por todo el proyecto. Los modelos entrenados con diferentes fechas de corte escriben para versiones conflictivas de las mismas librerías, por lo que aparece la deriva de versiones. Lo que queda es un código Frankenstein: un mosaico de estilos donde la lógica de interfaz, las consultas a la base de datos y las reglas de negocio están enmarañadas en archivos que nadie planificó, y cada edición posterior debe navegar a través de todo ese caos.
Los fallos no avisan
Un cierre inesperado es honesto; te dice que algo va mal. Los fallos del Día Dos que realmente hacen daño son los silenciosos. La IA construye la ruta de éxito específica que describía el prompt y omite los casos que nadie muestra en una demo: ediciones simultáneas de dos usuarios, un formulario que pierde la conexión a mitad del envío, un botón pulsado dos veces, una entrada de datos con formato incorrecto. Un pequeño error de redondeo o cálculo se ejecuta sin problemas en cada transacción y emerge meses después en un informe de facturación o en un recuento de reservas que ya no cuadra.
La brecha de confianza es lo que hace que esto sea peligroso en lugar de simplemente molesto. Un operador no técnico no puede leer el código generado para confirmar qué hace, y las pruebas manuales recorren la ruta feliz, no las excepciones. Así, la aplicación que “funciona perfectamente” en la vista previa y la aplicación que corrompe silenciosamente una cuarta parte de sus registros pueden ser, y a menudo son, la misma aplicación. Te enteras por un cliente, no por una prueba.
La cláusula de mantenimiento
Aquí es donde el Día Dos se suma al resto de la factura. Cada cambio que realizas es una generación nueva, y en la generación es donde residen tanto los costes como los riesgos. Volver a solicitar una funcionalidad relacionada con la autenticación vuelve a lanzar los dados de la seguridad (como se explica en qué significa realmente que ‘el 45% del código de IA es vulnerable’), por lo que una capa que ya habías verificado debe verificarse de nuevo. Y cada ronda de corrección de síntomas en lugar de causas raíz alimenta el impuesto del bucle de corrección: ese ciclo de depuración pagado que convierte una suscripción barata en una abierta, la misma dinámica que separa a los contendientes en Lovable vs Bolt.
La infraestructura añade sus propias sorpresas del Día Dos. Los creadores que optan por el auto-alojamiento para evitar el bloqueo de plataforma terminan sincronizando a mano una base de datos de Supabase, un frontend en Cloudflare Worker y una plataforma de cron, y un desajuste en cualquiera de ellos tumba todo el sistema. Quienes se quedan en el alojamiento de una sola plataforma heredan el tiempo de actividad, los precios y la hoja de ruta de dicha plataforma. Ninguna de las dos es la opción gratuita que sugería la demo.
Qué seguir generando y qué no
La lectura honesta no es que el vibe coding sea inútil; es excelente para herramientas personales, prototipos y componentes personalizados delimitados donde el alcance es pequeño. El error es aplicarlo a las partes de una aplicación que deben sobrevivir al mantenimiento. Si estás construyendo dentro de una base de código real y te encargarás de la revisión, una herramienta centrada en el código como Cursor o una plataforma en la nube como Replit te permiten controlar qué cambia y cuándo.
Para aplicaciones de negocio - portales, herramientas internas, CRMs, cualquier cosa con inicios de sesión, roles y datos reales - la capa que se rompe el Día Dos es principalmente la autenticación, los permisos y la fontanería CRUD. En una plataforma como Softr, estos elementos no se generan por proyecto; son infraestructura de plataforma configurada, por lo que cambiar un permiso es un ajuste de configuración, no una ronda de regeneración, y no hay un bucle de corrección en el que entrar. Softr tiene créditos de IA para su Co-Builder, pero dado que todo lo que hace la IA también puede hacerse a mano, un saldo vacío nunca bloquea una corrección. El Día Dos más barato es aquel en el que la parte más importante nunca llegó a generarse.