Vibe coding para quienes no son desarrolladores: qué puedes construir con seguridad en 2026

Quienes no son desarrolladores pueden hacer mucho con vibe coding de forma segura en 2026, hasta una línea que se puede nombrar. Por debajo están los prototipos, las landing pages, las herramientas internas y las apps sencillas con login y base de datos. Por encima están la lógica de pagos a medida, los datos de salud o financieros, las apps compartidas por muchas empresas y cualquier cosa con tráfico serio. Para eso sigue haciendo falta un ingeniero.

La audiencia ya está aquí. Lovable dice que el 80 % de sus usuarios se describe como no técnico y que la gente la usa para herramientas internas, CRM y tiendas online, además de sitios web (The Next Web). Los fallos llegaron con ellos. Este año UpGuard encontró 16.326 bases de datos en Supabase, el backend sobre el que corren muchas de estas apps, con tablas que cualquiera en internet podía leer (UpGuard). Veracode lleva cuatro años probando más de 100 modelos de IA y sitúa en un 56 % la tasa media de aprobado en seguridad del código escrito por IA. En sus palabras: "No se ha movido" (Veracode).

Casi todo el daño se remonta a un único error que puedes comprobar sin leer código: una base de datos que entrega filas a quien las pida. Corrige eso, mantén las claves secretas fuera del navegador y casi todo lo que un fundador, un profesional de marketing o un analista quiera construir es terreno seguro.

Cómo es el vibe coding en 2026

Describes lo que quieres en lenguaje natural, la herramienta escribe el código, navegas por una vista previa en vivo y pides el siguiente cambio. Las herramientas pensadas para quienes no programan ya van mucho más allá de la interfaz. También crean la base de datos, el sistema de registro y el hosting, así que una app con cuentas reales puede existir después de una tarde de prompts.

Lee el diagrama como un bucle con una sola salida. La salida es la parte que mucha gente se salta.

La flecha discontinua sale de las pruebas a propósito. No puedes juzgar el código generado leyéndolo, pero sí puedes juzgar lo que hace: si una segunda cuenta ve los registros de la primera o si una página se abre sin iniciar sesión. Cuando una prueba toque dinero, datos privados de otras personas o escala real, para y llama a alguien que sepa leer código.

Este año se movió mucho. Lovable ahora permite que un solo mensaje de construcción se ejecute hasta 10 horas y ha añadido un comando /goal que sigue trabajando hasta terminar una tarea, a un precio notablemente más alto (Lovable changelog). Replit lanzó Agent 4 con agentes en paralelo, y su IA ahora funciona con un Free Mode y modos de pago Power y Max. Vercel reconstruyó v0 en torno a ramas de GitHub y pull requests, y su responsable de producto asegura que el 90 % del trabajo real consiste en modificar una base de código existente. Base44, de Wix, entrenó su propio modelo, Base1, que según su fundador acabará siendo más rápido y barato para los clientes que los modelos de frontera.

Google AI Studio ahora detecta cuándo una app necesita una base de datos o un login y, una vez que lo apruebas, configura Firebase para ambos. Su constructor anterior, Firebase Studio, se va a cerrar, así que cualquier tutorial basado en él ya está desfasado.

La escalera de riesgo: qué puedes construir por tu cuenta

El riesgo sube con dos factores: de quién son los datos que guarda la app y si pasa dinero por ella. Un prototipo lleno de registros inventados no puede filtrar nada. Una app de registro con los correos de desconocidos sí puede, y este año muchas lo hicieron.

La escalera ordena los proyectos habituales según ese riesgo. Los tres peldaños de abajo son terreno seguro para cualquiera. El ámbar es donde ocurrieron la mayoría de las filtraciones de este año.

Los prototipos clicables, las landing pages con formulario de contacto y las herramientas internas solo para el equipo son el punto ideal. Un prototipo responde a "¿deberíamos construir esto?" antes de que nadie escriba un ticket. Un tracker interno para un equipo de ventas u operaciones puede reemplazar una hoja de cálculo en la que nadie confía, y si está configurado solo para el workspace y con login, quienes podrían hacer un mal uso son tus compañeros. Las automatizaciones sencillas también entran en este peldaño, aunque una herramienta de workflows como n8n o Zapier muchas veces resuelve el problema sin construir ninguna app (consulta el ranking de automatización de workflows).

Las apps para clientes con cuentas son el peldaño ámbar. Las herramientas pueden construirlas sin problema. El problema es que una sola regla de base de datos mal puesta expone a todos los usuarios a la vez, así que constrúyela y luego paga a un ingeniero para que la revise antes de que se registre gente real.

Los dos peldaños superiores son de los ingenieros. Primero, los pagos. Un botón de compra que abre el checkout alojado de Stripe está bien, porque los datos de la tarjeta van directos a Stripe y nunca pasan por tu app. La propia guía de seguridad de Stripe advierte de que un negocio que recibe datos de tarjetas directamente puede tener que cumplir más de 300 controles de seguridad de PCI DSS. La facturación por uso y las apps en las que varias empresas comparten una base de datos dependen de la lógica de autorización, justo donde los investigadores siguen encontrando fallos en apps creadas con IA.

Los datos regulados son el otro caso. Las FAQ empresariales de Lovable dicen que no firma business associate agreements, que no cumple con HIPAA y que pide a los usuarios que no suban información de salud protegida. Los datos de salud, financieros y de menores conllevan obligaciones legales que ningún escáner previo a la publicación puede cubrir.

Las herramientas que importan ahora y cómo cobra cada una

Cinco constructores cubren casi todo lo que necesita este lector, y se diferencian menos en lo que pueden crear que en cómo cobran y lo fácil que es irse. Bolt y v0 acompañan a Lovable, Replit y Base44. Los precios son los de los planes de pago de entrada, tomados de la página de precios de cada proveedor.

Para la mayoría de quienes no programan, Lovable es la opción por defecto más sensata. Publica ejemplos de coste por mensaje, analiza problemas de seguridad en cada publicación y su código se sincroniza con GitHub en cualquier plan, incluido el gratuito. Base44 va bien para quienes no quieren ver código nunca, con un matiz que verás en la sección de traspaso más abajo. Replit tiene sentido si quieres un único espacio de trabajo para apps, presentaciones y dashboards de datos, y su Free Mode es la forma más suave de empezar. Bolt encaja con quienes construyen a rachas, ya que los tokens de pago sin usar se acumulan durante un mes. v0 es la elección cuando tu empresa ya despliega en Vercel y los ingenieros se harán cargo del proyecto.

Dos opciones no-code más veteranas cubren un terreno parecido con editores visuales: Bubble crea apps web y móviles, y Glide convierte hojas de cálculo en apps. El ranking en vivo de abajo muestra cómo se posiciona hoy la categoría en general, y nuestro resumen de creadores de apps con IA profundiza en una docena de ellos.

El ranking incluye también constructores orientados a desarrolladores, así que úsalo para descubrir herramientas y la tabla para calcular presupuesto.

Por qué los créditos se gastan más rápido de lo que habías previsto

Todas estas herramientas cobran ya por el trabajo que hace la IA, no por el mensaje que envías. Eso es justo para ediciones pequeñas y caro para las vagas.

Lovable publica los ejemplos más claros. "Haz el botón gris" costó 0,50 créditos, "Añade autenticación" 1,20 y "Construye una landing page con imágenes" 2,00, mientras que un mensaje en plan mode cuesta 1 crédito (Lovable). Como un mensaje de construcción ahora puede ejecutarse durante horas, Lovable se detiene a consultarte cuando un solo mensaje supera los 20 créditos, un valor por defecto que puedes subir o desactivar. Las recargas en Pro cuestan 15 $ por 50 créditos, es decir, 0,30 $ por crédito frente a los 0,25 $ dentro del plan de 100 créditos.

Las demás funcionan igual con otros nombres. El centro de ayuda de Bolt dice que la mayor parte del uso de tokens viene de leer y sincronizar los archivos de tu proyecto, así que el mismo prompt cuesta más a medida que la app crece. v0 cuenta el historial del chat y los archivos fuente como tokens de entrada. Base44 dice que no hay un coste fijo por mensaje y sitúa los cambios típicos entre 0,5 y 4 créditos aproximadamente. El Free Mode de Replit no cuesta nada dentro de una cuota, pero los modos Power y Max consumen créditos mensuales, y sus paquetes extra de créditos caducan seis meses después de la compra.

La escalera de precios de Lovable muestra lo que eso significa para un presupuesto.

Casi no hay descuento por volumen. Todos los niveles hasta 800 créditos salen a 0,25 $ el crédito, y el de 2.000 créditos sigue en 0,24 $. Si duplicas lo que haces prompt, se duplica la factura, así que la palanca que importa son los mensajes desperdiciados.

Casi todo el desperdicio viene de los bucles de arreglos: la IA rompe algo, su arreglo rompe otra cosa y cada ronda se factura. Planificar primero ayuda, ya que un mensaje en plan mode de Lovable cuesta un crédito fijo y Bolt dice que su plan mode usa menos tokens porque no cambia nada. Los botones también ayudan: Bolt señala que publicar o restaurar una versión con un botón no cuesta nada, mientras que pedírselo a la IA gasta tokens. Cuando una sesión se tuerce, vuelve a un checkpoint en lugar de intentar salir a base de prompts.

Introduce tus propios hábitos en el estimador de abajo. Usa los costes de ejemplo de Lovable, así que toma el resultado como un rango de presupuesto, no como un presupuesto cerrado.

Con los valores por defecto necesitas unos 162 créditos al mes, que cubre el nivel de 50 $. Si subes el retrabajo al 60 %, incluso la ruta más barata, el plan de 25 $ más recargas, sube a 70 $. Pon también un tope: la recarga automática de Lovable admite un límite de gasto mensual en lugar de "Sin límite", y Replit te deja limitar el gasto por encima de tus créditos incluidos. Si los precios por créditos aún te resultan escurridizos, nuestro explicador sobre los modelos de precios de herramientas de IA repasa créditos, asientos y tokens.

El registro de incidentes apunta a un solo error

Pon lado a lado los informes de incidentes de este año y el mismo fallo aparece una y otra vez. No es hacking sofisticado. Es una base de datos que responde a cualquiera que pregunte.

El estudio de UpGuard encontró unos 300.000 dominios con señales de usar Supabase y 16.326 bases de datos que exponían tablas legibles, más de la mitad con indicios de datos personales (UpGuard). Su explicación es concreta: las tablas creadas a través de la API, que es como los agentes de programación hablan con Supabase, no tienen activada por defecto la seguridad a nivel de fila. El responsable de seguridad de Supabase dijo a TechCrunch que los proyectos son seguros por defecto y que la seguridad es una responsabilidad compartida.

Moltbook, una red social para agentes de IA cuyo fundador dijo que "no escribió ni una sola línea de código", salió con su clave de Supabase en la página y sin políticas de seguridad a nivel de fila. Los investigadores de Wiz llegaron a 1,5 millones de tokens de API, 35.000 direcciones de correo y miles de mensajes privados antes de que el equipo lo parcheara unas horas después de que se lo avisaran (Wiz).

Una app alojada en Lovable expuso 18.697 registros de usuarios, miles de ellos cuentas de estudiantes, según el investigador Taimur Khan. Encontró la comprobación de acceso escrita al revés: "El guardia bloquea a quienes debería dejar pasar y deja pasar a quienes debería bloquear" (The Register). Lovable dijo que ofrece un análisis de seguridad gratuito antes de publicar, que actuar sobre sus resultados depende del usuario, que la base de datos vulnerable no estaba alojada por Lovable y que el proyecto contenía código que Lovable no había generado.

Las plataformas también fallan. Más adelante en el año, un investigador demostró que una cuenta gratuita de Lovable podía extraer código fuente, credenciales de bases de datos e historiales de chat con la IA de proyectos públicos de otras personas. Lovable primero calificó ese comportamiento de intencionado y por diseño. Después admitió que señalar una documentación poco clara no era suficiente, dijo "Lo haremos mejor" y afirmó que había parcheado su API para que no se pueda acceder a los chats de proyectos públicos (The Register). La firma de seguridad RedAccess contó unas 380.000 apps accesibles públicamente creadas con Lovable, Base44, Replit y Netlify, unas 5.000 de ellas con datos sensibles expuestos. El CEO de Replit respondió que es normal que las apps públicas sean accesibles y que la privacidad se activa con un clic.

La investigación dice lo mismo desde el otro lado. La prueba de larga duración de Veracode muestra lo poco que han ayudado los modelos más inteligentes.

Hasta el mejor modelo de la ronda de 2026 de Veracode falla casi una de cada tres tareas de seguridad, y los modelos creados para programar no lo hacen mejor que los generalistas. Un estudio aparte de la startup Tenzai construyó 15 apps con cinco agentes de programación y encontró 69 vulnerabilidades. Las peores tenían que ver con la autorización y la lógica de negocio, y los clásicos errores de inyección no aparecieron en absoluto. Cuadra con los incidentes. La IA escribe código que funciona, pero no se pregunta quién debería poder usarlo a menos que se lo digas.

Seguridad a nivel de fila, en cristiano

Las apps construidas así suelen hablar con la base de datos directamente desde el navegador, con una clave que es pública por diseño. Lo que impide que un desconocido use esa clave para leerlo todo es la seguridad a nivel de fila (row-level security): reglas dentro de la base de datos que deciden, fila por fila, quién puede leer o cambiar qué. El backend integrado de Lovable y la base de datos de Bolt usan estas reglas de Postgres, el mismo modelo que usa Supabase.

La documentación de Supabase es tajante. Una tabla en un esquema expuesto sin RLS "es legible y escribible por cualquier rol con un permiso sobre ella" (Supabase). Una vez activada, la clave pública no ve nada hasta que una política lo permita. Una política es corta. Esta, del tipo que tu constructor debería escribir para una tabla de pedidos, deja que cada usuario con sesión iniciada lea solo sus propias filas:

create policy "Users read their own orders"
on orders for select
to authenticated
using ( (select auth.uid()) = user_id );

No tienes que escribirla. Sí tienes que confirmar que existe una para cada tabla. La clave secreta o "service role" se salta estas reglas por completo, así que nunca debe estar en el código del navegador. Y cualquier cosa de tu front end, incluida una comprobación como "¿este usuario es admin?", puede ser editada por quien usa la app, por eso la documentación de Lovable dice que el código del front end nunca debe tomar decisiones de seguridad.

Un proceso de construcción seguro, paso a paso

Este orden mantiene baratos los errores: datos falsos hasta el último paso y personas reales solo al final.

1. 1Escribe una especificación de una página antes del primer prompt. Di quién usa la app, enumera las cinco o seis pantallas, detalla qué puede ver y cambiar cada tipo de usuario y nombra lo que queda fuera del alcance. Pégala en plan mode y pide a la herramienta que le busque agujeros.
2. 2Haz el prototipo con datos falsos. Construye las pantallas y los flujos con registros inventados, mantén el proyecto en privado y enséñaselo a quienes lo van a usar. Cambia de rumbo ahora, mientras un cambio cuesta un mensaje.
3. 3Describe el modelo de datos con palabras sencillas. Enumera cada tipo de registro (clientes, pedidos, notas) y quién es su dueño, y pide a la herramienta que cree las tablas y explique, tabla por tabla, quién puede leer y cambiar filas. Si alguna respuesta es "cualquiera", arréglalo antes de seguir.
4. 4Añade el registro y los permisos en el mismo paso y luego pide que te lean las reglas. Base44, por ejemplo, acepta reglas escritas como frases, del tipo "Solo la persona que envió un pedido debería poder verlo".
5. 5Prueba con dos cuentas y datos falsos. Regístrate como Alice y como Bob. Como Bob, intenta abrir los registros de Alice, edita el número de registro en la barra de direcciones y usa la app sin haber iniciado sesión. Todo lo que Bob alcance y no debería es un bug, sea cual sea el aspecto del código.
6. 6Pasa la revisión de seguridad. Usa el escáner integrado, corrige todos los hallazgos críticos y repasa después la checklist de la siguiente sección. La auditoría completa de Bolt no gasta tokens si se lanza desde el menú Publish. Si la app guarda datos personales de clientes, aquí es donde un ingeniero la revisa.
7. 7Lanza en pequeño, con límites. Invita primero a un puñado de usuarios reales, fija límites de gasto, confirma que funcionan las copias de seguridad y el rollback, y borra las cuentas falsas.

¿No sabes en qué peldaño está tu idea? El árbol de abajo te da una respuesta en tres preguntas o menos.

Si el árbol te manda a un ingeniero, el prototipo no se pierde. Una maqueta funcional más una especificación es el briefing más claro que puede recibir un desarrollador.

La checklist de seguridad previa al lanzamiento

Pásala antes de que nadie fuera de tus cuentas de prueba reciba un enlace. Nada de esto requiere leer código. Cada punto es un ajuste que revisar, un análisis que lanzar o una prueba que hacer.

Dos puntos hacen la mayor parte del trabajo. La seguridad a nivel de fila en cada tabla se comprueba en la vista de base de datos o de seguridad de tu constructor, y Bolt señala las reglas "siempre verdaderas", es decir, las que dejan pasar a todo el mundo. La prueba con una segunda cuenta detecta lo que los escáneres pasan por alto, como la comprobación de acceso al revés de la app de Lovable que vimos antes.

El resto es rápido. Bolt activa por defecto la protección contra contraseñas filtradas, y el análisis previo a la publicación de Lovable avisa cuando está desactivada. En Lovable, todo lo que lleve el prefijo VITE_ acaba en el navegador, así que una clave secreta nunca debe llevarlo.

Los escáneres tienen límites, y los propios proveedores lo dicen. La documentación de Lovable afirma que sus herramientas "no pueden garantizar una seguridad completa" y recomienda una revisión profesional para las apps que manejan datos sensibles. La de Base44 es más breve: eres responsable de los ajustes de seguridad de tu app.

Pasarle el proyecto a un desarrollador

Una app creada con vibe coding que funciona acabará necesitando a un ingeniero, tarde o temprano, para revisarla o para hacerse cargo de ella. Planifica el traspaso desde el primer día.

Conecta pronto un repositorio de GitHub. La sincronización bidireccional de Lovable funciona en todos los planes, y un desarrollador puede clonar el repositorio y seguir trabajando en su propio editor. La de Base44 empieza en el plan Builder. En v0, un repositorio conectado pasa a ser la fuente de verdad, y v0 sube sus cambios a una rama de trabajo en lugar de directamente a la rama de la que partió. Bolt también sincroniza los commits con GitHub.

Ten claro qué se queda fuera con el código. La documentación de Lovable dice que ni la sincronización con Git ni la descarga del código incluyen los datos que hay dentro de tu base de datos, y su guía para alojar en otro sitio te hace mover a mano los archivos de almacenamiento. Base44 dice que nada queda atado a su plataforma y que la sincronización con GitHub exporta el código fuente completo. Su documentación para desarrolladores también describe un SDK que los proyectos exportados usan para acceder a los servicios propios de Base44, tanto para datos como para funciones de backend. Es nuestra lectura, no una afirmación de Base44: salir por completo de Base44 puede implicar reemplazar esa capa.

Dale al desarrollador un paquete de traspaso corto:

• La especificación, con cada pantalla y quién puede usarla.
• Acceso al repositorio y al proyecto del constructor.
• Una lista en lenguaje llano de cada tabla y de quién debería poder leerla y modificarla.
• Las integraciones que añadiste y los nombres de los secretos que usan, nunca los valores en sí por chat o correo.
• Bugs conocidos, cualquier apaño raro que hayas metido a base de prompts y lo que ha costado el proyecto en créditos hasta ahora.

Pide una revisión de seguridad antes de añadir nuevas funciones: reglas de acceso, funciones del lado del servidor y dónde viven los secretos. La mayoría de los desarrolladores abrirán el repositorio en una herramienta de programación como Cursor o Claude Code. Nuestro resumen de asistentes de programación y el artículo asistentes de programación con IA frente a creadores de agentes explican en qué se diferencian esas herramientas de los creadores de apps, y el ranking de asistentes de programación con IA clasifica el sector.

Preguntas frecuentes

¿Soy dueño del código que escribe una herramienta de vibe coding?

Lovable, Base44, Bolt y v0 sincronizan el código con un repositorio de GitHub que controlas tú, Base44 desde su plan Builder. Ser dueño del código no es lo mismo que ser dueño de la app en funcionamiento, eso sí. Tus datos, archivos almacenados y servicios de backend pueden quedarse en la plataforma hasta que alguien los migre.

¿Qué herramienta de vibe coding es la más barata para empezar?

Las cinco tienen plan gratuito. Lovable da a los usuarios gratuitos 5 créditos de construcción al día, con un tope de 30 al mes, y el Free Mode de Replit funciona en sus planes individuales gratuito y de pago, con límites que fija el plan. Entre los planes de pago, el Starter de Base44 cuesta 16 $ al mes facturados anualmente y Replit Core 20 $ al mes.

¿Puedo cobrar pagos en una app hecha con vibe coding?

Sí, mediante un checkout alojado. La integración de Lovable con Stripe abre Stripe Checkout y guarda tu clave secreta como secreto de backend, no en el código de la app. Prueba primero con claves de sandbox y con la tarjeta de prueba de Stripe. La facturación por uso, los pagos a otros usuarios y la facturación para cuentas de varias empresas son terreno de ingenieros.

¿Puede la IA revisar la seguridad de su propio código?

En parte. Los escáneres integrados detectan problemas comunes como reglas de acceso ausentes, claves expuestas y paquetes vulnerables. Pero los propios proveedores dicen que los escáneres no pueden garantizar la seguridad, y la app que filtró 18.697 registros estaba en una plataforma que ofrece un análisis gratuito previo a la publicación. Considera el escáner un mínimo, no una aprobación final.

¿Qué pasó con Firebase Studio?

Google lo está cerrando. Ya no crea espacios de trabajo nuevos, cierra en 2027 y Google dice a los usuarios que pueden migrar los espacios de trabajo existentes a Google AI Studio o Antigravity. Los servicios de Firebase, como Firestore y Authentication, siguen funcionando igual que antes.