El vibe coding es magia en la demo. ¿Tu app aguanta de verdad en producción?

¿Está el vibe coding listo para producción? Para prototipos y herramientas internas, sí — y de forma brillante. Para una app publicada en las tiendas, con usuarios reales y datos reales, no por sí solo. Las verdaderas limitaciones del vibe coding no están en el código que escribe; están en todo lo que la producción exige alrededor de ese código.

La propia industria del no-code ha empezado a ponerle nombre a la brecha. El State of No-Code 2026 de Caspio describe una IA que tira del mercado en dos direcciones a la vez y remata con una fórmula contundente: “La división no es 'IA buena contra IA mala'. Es desechable frente a duradero (disposable vs. durable)”.

¿Y qué hace desechable a un prototipo de vibe coding? No la demo — todo lo que la rodea. Siete muros, invisibles en la pantalla de un portátil, muy reales el día que intentas publicar. Tres de ellos —el código nativo, el envío a las tiendas y el ciclo de vida de la app— son tan específicos del móvil que les dedicamos un análisis completo aparte; aquí ocupan su lugar dentro del cuadro general.

Muro 1 — Hosting y propiedad

Seamos justos con las herramientas: en general, el código es tuyo. La documentación de Lovable lo dice explícitamente, y puedes exportarlo a GitHub. Lo que no es tuyo es todo lo que ese código necesita para funcionar. Por defecto, tu app vive en la nube gestionada del proveedor —Lovable Cloud, el hosting de Bolt, Vercel—, con su backend, su base de datos y su pipeline de compilación operados por ellos, con sus precios y bajo sus condiciones. Ser dueño del código fuente de una app cuya infraestructura pertenece a otro es como tener los planos de una casa construida en terreno alquilado. Producción significa que alguien responde por esa infraestructura durante años: disponibilidad, copias de seguridad, renovaciones, facturas. En la demo, no responde nadie.

Mutualización. Una plataforma SaaS opera una sola infraestructura para todas sus apps, mantenida por un equipo cuyo único trabajo es que no se caiga — y el coste va incluido en la suscripción, en lugar de descubrirse más tarde. Todas las apps que hemos publicado han funcionado sobre ese modelo desde el primer día.

Muro 2 — Backend y datos

La capa de datos de un prototipo está optimizada para la demo: existe, responde, se ve bien. Los datos de producción tienen exigencias más duras: migraciones, copias de seguridad, entornos que separan las pruebas de la realidad. En julio de 2025 esa lección llegó a los titulares, cuando el agente de Replit borró una base de datos de producción durante una congelación de código explícita y eliminó los registros de más de 1.200 ejecutivos. Replit respondió anunciando la separación automática entre bases de datos de desarrollo y de producción — cerrando un hueco que los sistemas de producción dan por descontado.

Y más allá de la base de datos, la producción es donde viven los problemas operativos sin glamur. El email transaccional es el clásico: un fundador de SaaS contaba en r/SaaS tasas de entrega “a menudo por debajo del 50%” sobre infraestructura de correo compartida. Ningún prompt arregla la entregabilidad.

Un backend anterior a tu app. En una plataforma gestionada, la capa de datos —migraciones, copias de seguridad, la separación entre pruebas y producción— se diseñó una sola vez, profesionalmente, y la ejercitan a diario todas las apps que corren sobre ella; solo nuestro módulo de e-commerce ya funciona en producción para miles de comercios. La fontanería sin glamur es el trabajo diario de un equipo de plataforma, no tu descubrimiento de la tercera semana.

Muro 3 — Autenticación y seguridad

Es el muro mejor documentado, porque los investigadores no dejan de medirlo. El estudio de Veracode de 2025 sobre más de 100 modelos encontró que el código generado por IA introducía vulnerabilidades del OWASP Top 10 en el 45% de las tareas evaluadas. Un benchmark académico publicado en diciembre de 2025 midió la brecha en su versión más cruda: el mejor agente producía soluciones funcionalmente correctas el 61% de las veces, pero solo el 10,5% de sus soluciones eran seguras. Y en 2025 se registró un CVE que documenta la ausencia de Row-Level Security en apps generadas con Lovable — el investigador de seguridad Matt Palmer escaneó 1.645 de esas apps y encontró 170 que exponían datos, incluidas claves de API y datos financieros. Cuando Escape.tech escaneó más de 5.600 apps de vibe coding en producción en octubre de 2025, encontró más de 2.000 vulnerabilidades y más de 400 secretos expuestos.

Nada de esto significa que los modelos sean malos. Significa que la revisión de seguridad es un requisito de producción por el que un prototipo, por definición, nunca ha pasado.

Seguridad escrita una vez, heredada por todos. La autenticación de una plataforma es una única base de código endurecida por años de tráfico real, y cuando algo necesita un parche, el arreglo se escribe una sola vez: se despliega de inmediato en el servidor y viaja en la siguiente compilación de cada app. Esa es la diferencia estructural entre un login mantenido por ingenieros y miles de logins generados, cada uno reinventando sus reglas de acceso en solitario.

Muro 4 — Envío a las tiendas

Aquí va el dato que la mayoría de tutoriales de vibe coding se salta: la mayoría de las herramientas prompt-to-app construyen apps web, no apps móviles. La propia FAQ de Lovable lo dice sin rodeos: “No, Lovable está centrado en aplicaciones web”. v0 genera código web desplegado en Vercel. Bolt es la excepción parcial —su integración con Expo genera código React Native real—, pero las compilaciones, las cuentas de desarrollador y la revisión de Apple siguen siendo enteramente problema tuyo.

El atajo que suele sugerirse —envolver la app web en una carcasa nativa— choca con la Guideline 4.2 de Apple: “Tu app debe incluir funciones, contenido y una interfaz que la eleven por encima de un sitio web reempaquetado”. Por la experiencia de nuestro equipo de publicación, los revisores prueban las apps sin conexión de forma rutinaria; un wrapper que muestra una pantalla en blanco se lo dice todo. Y la revisión no perdona ni siquiera a las apps de verdad: Apple rechaza aproximadamente el 42% de los primeros envíos (la línea base de Apple, medida sobre las apps que nuestro equipo de publicación envió en los últimos 12 meses). Escribimos una guía sobre por qué Apple rechaza apps y cómo remontar.

El envío como proceso industrial. Una plataforma compila binarios diseñados para pasar la revisión, y cuando Apple o Google mueven el listón —nuevas etiquetas de privacidad, nuevos plazos de SDK, nuevos controles de completitud— se actualiza una vez y todas las apps que publica heredan el arreglo. Quince años de envíos a las tiendas son una forma de capital que ningún prompt puede generar.

Muro 5 — Funciones nativas del dispositivo

Las funciones por las que una app móvil merece la pena frente a una web son precisamente aquellas con las que una app web envuelta más sufre. Las notificaciones push son el ejemplo más afilado: en iOS, el push web solo funciona en apps web instaladas manualmente en la pantalla de inicio — nunca en el navegador. Cámara, modo offline, biometría: cada una exige plugins nativos que hay que añadir, configurar y mantener a mano, fuera de todo lo que generó la IA. Una demo web “adaptada a móvil” y una app nativa son especies distintas con la misma interfaz.

Nativo por construcción. En una plataforma que compila Swift y Kotlin de verdad, el push, la cámara, el modo offline y los hápticos son componentes preconstruidos, mantenidos en cada versión de iOS y Android — la capa que hace que una app se sienta profesional es el punto de partida, no un añadido de última hora.

Muro 6 — Regeneration drift: el código que se reescribe solo

Llámalo regeneration drift — la deriva de la regeneración: cada nuevo prompt regenera el código contra un contexto ligeramente distinto, y el arreglo de ayer puede desaparecer en silencio dentro de la generación de hoy. Addy Osmani, engineering lead de Google Chrome, bautizó el patrón como “dos pasos atrás”: “Intentas arreglar un pequeño bug… La IA sugiere un cambio que parece razonable… Ese arreglo rompe otra cosa”. Los datos coinciden: el análisis de GitClear sobre 211 millones de líneas de código modificadas encontró que los bloques de cinco o más líneas duplicadas se multiplicaron por 8 en 2024, y que la proporción de código revisado en las dos semanas siguientes a escribirse casi se ha duplicado desde 2020. Una base de código que no se está quieta es una base de código sobre la que no puedes prometer nada — y menos aún a un usuario que ha encontrado un bug.

Unos cimientos que no se mueven. En una plataforma, la IA genera solo la fina capa personalizada sobre un sustrato versionado y probado — autenticación, checkout, CMS y sistema de diseño forman parte del sustrato que ningún prompt regenera jamás. La deriva queda confinada a esa capa fina en lugar de extenderse a toda tu app: el checkout del que dependes no puede reescribirse en silencio.

Muro 7 — Privacidad y cumplimiento normativo

Una app publicada carga con obligaciones legales que una demo nunca cumple. Las etiquetas de privacidad de Apple y el formulario de seguridad de los datos de Google Play te obligan a declarar qué datos recoges, adónde van y quién los procesa — preguntas que un stack de vibe coding a menudo no sabe responder, porque algún valor por defecto colocó los datos de tus usuarios en una infraestructura que tú nunca elegiste. El RGPD sube aún más el listón: consentimiento específico y desagregado, una residencia de datos que puedas afirmar, una lista de encargados del tratamiento que conozcas de verdad. Nada de eso aparece en una demo. Todo aparece en la revisión de la tienda o, peor, en una reclamación.

El cumplimiento resuelto una vez, aguas arriba. Un único esfuerzo legal y de ingeniería a nivel de plataforma —en nuestro caso, todos los datos alojados en Europa, gestión del consentimiento integrada, detección automática de los permisos que requiere cada función— sirve a todas las apps y se mantiene al día cuando las reglas cambian. Nuestros motores de compilación van un paso más allá: una librería solo entra en el binario si la función que la usa está activada, así que las apps no solo declaran menos: contienen menos.

Los siete muros del vibe coding — resumen

Siete muros, siete preguntas. Las respuestas de plataforma de arriba son las nuestras; estas preguntas son las tuyas. Respóndelas sobre tu prototipo:

1. ¿Quién opera la infraestructura en la que corre — y seguirá haciéndolo dentro de dos años?
2. ¿Dónde viven los datos, y qué pasa el día que el esquema tenga que cambiar?
3. ¿Alguien que sepa leer código ha revisado la autenticación y las reglas de acceso?
4. ¿Puede producir un binario iOS y Android firmado que pase la revisión de las tiendas?
5. ¿Puede enviar una notificación push a un teléfono bloqueado?
6. ¿Puedes arreglar un bug dentro de seis meses sin regenerar — y volver a romper — todo lo demás?
7. ¿El flujo de consentimiento y el tratamiento de datos sobrevivirían a una reclamación RGPD?

Tres o más “no” (o “no lo sé”) y lo que tienes es un prototipo. Y eso no es un fracaso: un prototipo es algo genuinamente útil. Valida una idea en una tarde por casi nada. El fracaso está solo en la confusión: planificar un lanzamiento, una base de usuarios y un negocio sobre algo construido para ser desechable.

La conclusión no es “evita la IA”. Nosotros usamos generación de código con IA a diario en nuestros propios equipos de ingeniería — nuestro CMO lo contaba ya en abril de 2025, junto con la advertencia que la industria ha confirmado desde entonces: “Sin conocimientos de programación, puedes verte desbordado o bloqueado muy rápido, porque la IA puede crear incoherencias importantes si se usa sin supervisión humana experta”.

La conclusión es apuntar la velocidad de la IA hacia unos cimientos desde los que sí se publica. Esa es toda la lógica del AI Extension Builder (actualmente en beta, disponible para todos los clientes), la respuesta de GoodBarber a la pregunta del prompt-to-app: describes una función en lenguaje natural y un agente de IA la construye — pero la construye dentro de una plataforma, contra APIs documentadas, así que el resultado hereda todo lo que a un prototipo le falta. El diseño sigue automáticamente el sistema de diseño de tu app. La sección se publica como binarios Swift y Kotlin genuinos, por el mismo pipeline de tiendas que operamos desde 2011 — con un equipo de publicación que recupera el 91% de los rechazos de Apple en primer envío cuando ocurren (últimos 12 meses).

Los muros 2 y 3 —backend y seguridad— reciben el mismo trato. Cuando una sección construida con IA necesita guardar datos, la integración con Supabase crea la estructura de la base de datos por ti, en tu propio proyecto de Supabase, sobre una infraestructura que tú controlas — y cada tabla sale con políticas de Row-Level Security por defecto. Ese es exactamente el fallo documentado en el CVE de Lovable, resuelto antes de que supieras que había que preguntar por él. Y el núcleo de la plataforma —hosting, base de datos, notificaciones push, analíticas y pagos— está incluido en una sola suscripción, así que no hay una pila de servicios de terceros que montar, asegurar y pagar por separado. Coste total de propiedad: alrededor de una décima parte de un desarrollo a medida.

Hay límites, por supuesto. GoodBarber está hecho para apps de contenido y comercio móvil; un juego o un marketplace muy a medida quedan fuera de ese alcance, y para esos proyectos un prototipo de vibe coding entregado a un equipo de desarrollo es un camino más natural. Dentro de ese alcance, en cambio, el enfoque de plataforma es lo que convierte la velocidad de la IA en una app que puedes publicar — y mantener funcionando en el tiempo.

El siguiente paso, en concreto:empieza una prueba gratuita, abre una sección “Create with AI” y describe la función que montaste con vibe coding el fin de semana pasado. Los mismos cinco minutos. Esta vez, el resultado tiene un pipeline de tiendas detrás.

¿Se puede publicar una app hecha con vibe coding en la App Store?

No directamente, en la mayoría de los casos. Lovable y v0 producen aplicaciones web: no hay binario iOS o Android que enviar. Envolver la app web en una carcasa nativa es posible, pero la Guideline 4.2 de Apple rechaza las apps que se quedan en “un sitio web reempaquetado”. Bolt puede generar código React Native vía Expo, pero las compilaciones, las cuentas de desarrollador y la revisión de la tienda siguen siendo cosa tuya. Los caminos fiables son dos: contratar desarrolladores que lleven el código a producción, o reconstruir sobre una plataforma que compile binarios nativos y gestione el envío. Para el análisis completo específico de móvil, lee lo que las herramientas de vibe coding olvidan contarte sobre las apps móviles.

¿Está el vibe coding listo para producción?

Para prototipos, herramientas internas y proyectos de fin de semana: sí, y es excelente en eso. Para apps en producción con usuarios reales, la respuesta ponderada es: no sin revisión de ingeniería. El código generado por IA introduce vulnerabilidades de seguridad en el 45% de las tareas evaluadas (Veracode, 2025), y un benchmark académico encontró que las soluciones del mejor agente eran funcionalmente correctas el 61% de las veces, pero seguras solo el 10,5% (arXiv, diciembre de 2025). Estar listo para producción no va de si el código se ejecuta: va de hosting, datos, revisión de seguridad, envío a las tiendas, funciones nativas, estabilidad del código y cumplimiento — los siete muros del vibe coding.

¿Qué es el regeneration drift en vibe coding?

El regeneration drift —la deriva de la regeneración— es lo que ocurre cuando cada nuevo prompt regenera el código contra un contexto ligeramente distinto, de modo que el arreglo de ayer puede desaparecer en silencio dentro de la generación de hoy. Addy Osmani llama al bucle resultante el patrón de los “dos pasos atrás”; el análisis de GitClear sobre 211 millones de líneas modificadas midió su huella: los bloques de código duplicado se multiplicaron por 8 en 2024. Es la razón principal por la que una app de vibe coding se vuelve más difícil de mantener cuanto más tiempo sigues lanzándole prompts.

¿Apple ha prohibido las apps hechas con vibe coding?

No — y la distinción importa. En marzo de 2026, Apple bloqueó las actualizaciones de las apps de plataformas de vibe coding como Replit y Vibecode bajo la Guideline 2.5.2, que prohíbe las apps que descargan y ejecutan código. Eso apunta a las herramientas como apps de iOS, no a las apps construidas con IA. Apple declaró a MacRumors que no tiene reglas específicas contra las apps de vibe coding. Una app individual construida con IA se enfrenta al listón de siempre: funcionalidad mínima (4.2), spam (4.3) y completitud — la misma revisión que pasa cualquier app.

¿Cuándo pasar de un prototipo de vibe coding a un app builder?

En el momento en que el prototipo tiene que convertirse en la herramienta diaria de alguien: usuarios reales, presencia en las tiendas, actualizaciones, un backend que persiste. Es un umbral de responsabilidad, no de habilidad: el día que otras personas dependen de la app, alguien tiene que responder por sus siete muros. Conserva el prototipo; ya cumplió su función validando la idea. Después reconstrúyelo donde esos muros ya son el trabajo de otro — binarios nativos, envío a las tiendas, hosting y mantenimiento incluidos. Como decía nuestro CMO, el vibe coding sirve a un público experto; un app builder está hecho para todos los demás.

¿Cuánto cuesta realmente publicar en las tiendas?

Una cuenta de desarrollador de Apple cuesta 99 $ al año; la de Google Play, un pago único de 25 $. Luego llega el coste de verdad: preparar las builds, las capturas, las declaraciones de privacidad y sobrevivir a la revisión — Apple rechaza aproximadamente el 42% de los primeros envíos (la línea base de Apple, medida sobre las apps que nuestro equipo de publicación envió en los últimos 12 meses). Nuestra guía de publicación paso a paso cubre el proceso, y nuestro servicio de publicación lo hace por ti.