Lovable y los app builders con IA: por qué la demo nunca es producción

El pitch es perfecto. La realidad, no tanto.

Abres Lovable, escribes lo que quieres construir, y en unos minutos tienes algo que parece una aplicación. Tiene colores, botones, un flujo de usuario reconocible. Se lo enseñas a alguien y dice "hostia, qué rápido". Subes una captura a LinkedIn y consigues cincuenta likes de gente que tampoco ha tocado el producto.

Eso es la demo. Y la demo miente.

No miente porque sea falsa. Miente porque parece completa cuando en realidad es un esqueleto con pintura. La diferencia entre ese prototipo y una aplicación que aguanta usuarios reales, datos reales y errores reales es exactamente la diferencia entre un decorado de película y un edificio de verdad. Desde la cámara, son idénticos. Desde dentro, uno se cae.

En marzo de 2026, Business Insider publicó una prueba en la que tres periodistas, con distintos niveles de experiencia técnica, usaron Cursor, Lovable y Base44 para construir apps reales: un compañero de escritura, un dashboard de redacción y un coach fotográfico. El resultado fue instructivo precisamente porque ninguna de las apps se describió como lista para producción. Ni una.

Qué pasó cuando tres periodistas pusieron el vibe coding a prueba

La prueba de Business Insider no fue un tutorial de marketing. Fue gente intentando construir algo útil con las herramientas que todo el mundo lleva meses vendiendo como la revolución del desarrollo de software.

Cheryl Teh, autodidacta que ya había experimentado con cinco plataformas de vibe coding, describió Cursor como "hackear el mainframe": líneas de código, comandos manuales, aprobaciones paso a paso. Cursor le preguntó si quería un plan de construcción de MVP, un prototipo clickable o una especificación completa de producto. Son distinciones que un ingeniero de software entiende de inmediato. Para alguien sin ese contexto, es ruido.

Aditi Bharade, principiante sin experiencia técnica, tuvo que ChatGPT para refinar su prompt inicial antes de meterlo en la plataforma. Eso ya te dice algo: incluso las herramientas que se venden como "no-code" asumen que sabes formular lo que quieres con una precisión que no es obvia si nunca has especificado software en tu vida.

Base44 y Lovable fueron más amables. Interfaces de chatbot, lenguaje sencillo, colores que invitan (Base44 en naranja, Lovable en rosa intenso, lo que la periodista llamó "girlypop"). Ninguna interrumpe el proceso para pedirte que apruebes comandos. Van de principio a fin solas. Eso suena bien hasta que miras lo que producen.

Los fallos que no salen en la demo

La app construida con Base44 carecía de funcionalidades que estaban en el brief original: no se podían eliminar tareas ni arrastrar elementos al calendario. Cosas básicas. Se solucionaron con prompts adicionales, pero el punto es que no estaban ahí desde el primer intento, aunque estaban en la descripción inicial.

Lovable consumió más créditos gratuitos que Base44 durante la construcción. La app era estéticamente cercana a lo que se buscaba, pero algunas funcionalidades directamente no funcionaban. No fallaban de vez en cuando: no funcionaban.

En ninguno de los dos casos, ni en Lovable ni en Base44, se podía recortar imágenes o ajustar el encuadre en el primer intento. Fue necesario un segundo prompt para acercarse a la visión inicial. Esto no es un fallo menor: es el patrón exacto que define la diferencia entre un prototipo y un producto.

Un prototipo hace lo que le dices que haga en condiciones ideales. Un producto hace lo que el usuario espera en condiciones que nadie anticipó.

Cursor fue el caso más extremo. Para desplegar la app, el periodista tuvo que configurar Supabase (una base de datos en la nube) y un servidor local. El proceso tomó más de treinta minutos y fue descrito como frustrante. Treinta minutos configurando infraestructura antes de tener algo que enseñar no es vibe coding: es desarrollo de software con pasos extra.

Por qué los fallos en cascada son el problema real

Cuando un desarrollador escribe código manualmente y hay un bug, lo localiza, lo entiende y lo corrige. El error tiene un origen claro.

Cuando una IA genera código y hay un bug, la situación es distinta. El código existe, pero nadie en el equipo lo escribió ni lo entiende completamente. Si falla algo, no está claro si el problema está en el prompt que generó ese módulo, en cómo interactúa con otro módulo generado por un prompt diferente, o en una dependencia externa que la IA incluyó sin avisar.

En sistemas simples esto es manejable. En cadenas largas de lógica, donde el output de un paso es el input del siguiente, un error pequeño al principio se amplifica. Lo que en el paso uno era una asunción incorrecta sobre el formato de una fecha se convierte, en el paso cinco, en datos corrompidos que llegan al usuario.

Esto no es especulación: es la mecánica básica de los sistemas de agentes encadenados. Y los app builders de IA, cuando generan aplicaciones con múltiples funcionalidades interconectadas, son exactamente eso: cadenas de lógica donde cada pieza fue generada por separado y ensamblada sin garantía de coherencia interna.

La prueba de Business Insider lo ilustra de forma concreta: funcionalidades que deberían estar presentes según el brief no lo estaban, funcionalidades que sí estaban no funcionaban, y la solución era más prompts. Cada prompt adicional es una capa más de lógica generada que interactúa con las anteriores de formas que nadie ha auditado.

El problema de la dependencia de plataforma

Hay una pregunta que nadie hace cuando está entusiasmado con la demo: ¿qué pasa si quiero sacar esto de aquí?

Lovable genera web apps, no aplicaciones nativas. La app de iOS que lanzaron el 28 de abril de 2026 (según 9to5Mac) permite crear y gestionar proyectos desde el móvil, iniciarlos ahí y continuar en escritorio, pero las aplicaciones resultantes son web apps accesibles como webs, no paquetes nativos distribuibles en tiendas de apps. Eso tiene implicaciones directas para rendimiento, acceso offline y experiencia de usuario en móvil.

Lo que no se especifica en ninguna de las fuentes disponibles es si el código generado por estas plataformas puede exportarse a un entorno de desarrollo estándar sin dependencia continuada de la plataforma. Si tu app vive en Lovable, ¿puedes llevártela a otro sitio si Lovable cambia sus precios, sus condiciones o simplemente cierra? No está claro.

Tampoco se mencionan métricas de rendimiento: latencia, uptime, comportamiento bajo carga. No se habla de seguridad del código generado ni de deuda técnica acumulada. No hay datos sobre la legibilidad del código para un desarrollador que luego tenga que mantenerlo. Estas no son preguntas académicas: son exactamente lo que te preguntan cuando intentas escalar algo más allá del prototipo.

Para qué sí sirve esto (y no es poco)

Nada de lo anterior significa que estas herramientas sean inútiles. Significa que hay que usarlas para lo que son.

Lovable, Base44 y herramientas similares son extraordinariamente eficaces para tres cosas concretas:

Validar hipótesis rápido. Si tienes una idea de producto y quieres saber si la gente entiende el concepto antes de invertir en desarrollo real, un prototipo de Lovable te da esa respuesta en horas, no en semanas. El prototipo no tiene que ser robusto: tiene que ser suficientemente convincente para obtener feedback real.

Demos a inversores. El CEO de Atech, Gustav Hugod, describió exactamente este caso de uso: compras un kit de hardware, hablas con un chatbot, obtienes código para un prototipo funcional. Lovable respaldó a Atech en una ronda pre-semilla de 800.000 dólares liderada por a16z Scout Fund, Sequoia Scout Fund y Nordic Makers (TechCrunch, mayo 2026). La inversión no va a un producto terminado: va a una demostración de que el concepto es viable. Para eso, el vibe coding es suficiente.

MVPs internos. Si necesitas una herramienta interna para tu equipo, un dashboard, un tracker, algo que use diez personas que conoces, los riesgos de producción son manejables. No hay datos sensibles de usuarios externos, no hay escala que estresar, y si algo falla, hay alguien disponible para arreglarlo con un prompt más.

Lo que no son estas herramientas es un atajo hacia producción real. La velocidad con la que generan un prototipo no se transfiere a la robustez que necesita un sistema que maneje datos de usuarios, procese transacciones o esté disponible las 24 horas.

El precio real que nadie menciona

Lovable tiene planes de suscripción de 9,99 a 79,99 dólares al mes (9to5Mac, abril 2026). Eso es el precio de entrada. Lo que no está en el precio son los créditos adicionales que consume construir algo medianamente complejo, Lovable consumió más créditos gratuitos que Base44 en la prueba de Business Insider, ni los servicios externos que necesitas para que funcione de verdad.

Cursor, que está orientado a desarrolladores, te llevó a configurar Supabase para la base de datos. Supabase tiene su propio modelo de precios. Si además necesitas un servidor para desplegar, suma eso. El coste total de propiedad de una app generada con estas herramientas no es solo la suscripción mensual: es la suscripción más los servicios en la nube más el tiempo que dedicas a prompts adicionales cuando algo no funciona.

Para un prototipo de validación, ese coste es irrisorio comparado con contratar un desarrollador. Para un sistema en producción, la ecuación cambia: necesitas desarrolladores para mantener el código de todas formas, más los costes de plataforma, más la deuda técnica acumulada en código que nadie entiende completamente.

Lo que viene después del prototipo

El movimiento del vibe coding está expandiéndose. Lovable invirtiendo en Atech, una startup que lleva el vibe coding al hardware, desde coches construidos por niños hasta plantas de hidrógeno, según TechCrunch de mayo de 2026, indica que la industria ve potencial más allá del software puro.

Pero la expansión al hardware hace la brecha entre demo y producción todavía más relevante. Un bug en una web app molesta al usuario. Un bug en el firmware de una planta de hidrógeno es otra categoría de problema. La velocidad de prototipado que hace atractivo el vibe coding en software es exactamente lo que lo hace peligroso en sistemas físicos sin la supervisión adecuada.

Apple, por su parte, mantiene las directrices habituales de la App Store pero no prohíbe las apps de vibe coding, precisamente porque Lovable genera web apps, no apps nativas que puedan cambiar su comportamiento después de pasar la revisión (9to5Mac, abril 2026). Es una distinción técnica que mantiene a Lovable dentro de las reglas, pero también define el límite de lo que puede construir.

La pregunta que deberías hacerte antes de esto

Antes de abrir Lovable o cualquier herramienta similar para construir algo, hay una pregunta que vale la pena responder con honestidad: ¿qué pasa cuando esto falla?

Si la respuesta es "nada grave, lo arreglo con otro prompt", estás en el territorio correcto para estas herramientas. Si la respuesta implica datos de usuarios, transacciones, decisiones automatizadas o sistemas que no puedes parar fácilmente, estás en territorio donde necesitas algo más que un chatbot que genera código.

La demo es real. El código existe. La app funciona en condiciones ideales. Pero producción no son condiciones ideales: es el usuario que hace exactamente lo que no esperabas, el pico de tráfico que no anticipaste, el error que se propaga por tres módulos antes de que alguien lo note.

Para eso, el vibe coding todavía no tiene respuesta. Y por ahora, nadie que haya probado estas herramientas en serio afirma que la tiene.

---