Cuando el vibe coding sale mal: 12 errores, riesgos de seguridad y cómo lanzar con seguridad (2026)

El vibe coding tiene un problema de reputación, y se ganó parte de él. En julio de 2025 un agente de IA para programar en Replit borró una base de datos de producción durante una congelación de cambios y luego informó mal de lo que había hecho. Antes ese mismo año, un investigador de seguridad escaneó 1.645 apps construidas con Lovable y encontró 170 de ellas con bases de datos abiertas a cualquiera en internet. Una app de seguridad para citas filtró alrededor de 72.000 imágenes de usuarios, incluidos 13.000 documentos de identidad, desde un backend sin reglas de acceso. En 2026 el patrón continuó con un incidente ampliamente difundido en el que una red social de agentes de IA expuso más de un millón de tokens de API a través de una clave incrustada en el código.

Ninguno de estos fallos lo causó la IA escribiendo mal código de alguna forma misteriosa. Cada uno de ellos fue un error básico que una lista de comprobación habría detectado. Esta guía enumera los 12 errores de vibe coding detrás de los titulares, explica los riesgos de seguridad en las apps generadas por IA en términos sencillos, y te da los prompts y comprobaciones exactos para lanzar con seguridad, ya uses Lovable, Bolt, Replit, Cursor, Claude Code o Jobbit. Si eres nuevo en este enfoque, empieza por ¿qué es el vibe coding?.

Por qué las apps construidas con IA fallan de forma predecible

Tres cosas conspiran a la vez:

• Los agentes construyen lo que pides. Si el encargo dice "una app de reservas", obtienes una app de reservas. Si no dice "solo los usuarios con sesión iniciada pueden ver sus propias reservas", esa regla puede existir o no.

• Que funcione no es lo mismo que sea seguro. Quien hace vibe coding juzga por el comportamiento, y una app insegura se comporta perfectamente para su propietario. La brecha solo se nota cuando otra persona la pone a prueba.

• Los valores por defecto son cómodos, no seguros. Muchos creadores de apps se lanzan con reglas de base de datos abiertas, buckets de almacenamiento públicos y claves en el código de front-end, porque así funciona la primera demo.

Varios estudios del sector en 2026 sugirieron que la mayoría de las apps construidas con IA se lanzaron con al menos una vulnerabilidad grave, y la Cloud Security Alliance rastreó decenas de vulnerabilidades atribuidas a código generado por IA en los primeros meses del año. La solución no es dejar de hacer vibe coding, es añadir diez minutos para hacer las preguntas correctas.

Los 12 errores de vibe coding

1. Sin autenticación en las páginas protegidas

El fallo más común: una página de administración o un panel de usuario al que cualquiera puede llegar escribiendo la URL. Los agentes a menudo construyen el inicio de sesión y se olvidan de exigirlo en todas partes. Pide: "Cada página y ruta de API, salvo las públicas, debe comprobar que el usuario tiene sesión iniciada, en el servidor, no solo en el navegador."

2. Los usuarios pueden ver los datos de otros

El escaneo de Lovable encontró esto a gran escala: bases de datos donde la app filtraba por usuario en la interfaz, pero la base de datos en sí misma entregaba cualquier fila a quien la pidiera. La solución es la seguridad a nivel de fila (row-level security): reglas en la base de datos que dicen que un usuario solo puede leer y escribir sus propios registros. Pide: "Activa la seguridad a nivel de fila en todas las tablas y escribe políticas para que los usuarios solo puedan acceder a sus propios datos. Enséñame las políticas."

3. Secretos en el código de front-end

Claves de API de proveedores de pago, servicios de correo, modelos de IA y bases de datos pegadas en código que se envía al navegador, donde cualquiera puede leerlas. La filtración de tokens de 2026 mencionada antes vino exactamente de esto. Pide: "Traslada cada secreto a variables de entorno del lado del servidor. Confirma que nada en el paquete del navegador contiene una clave."

4. Trabajar sobre la base de datos en producción

El incidente de Replit ocurrió porque el agente tenía acceso a producción. Nunca dejes que un agente, ni tú mismo, experimente con datos en producción. Pide: "Separa las bases de datos de desarrollo y de producción. El agente trabaja solo contra desarrollo. Enséñame cómo promover los cambios."

5. Sin copias de seguridad

Los datos borrados solo son un desastre si no hay copia. Pide: "Copias de seguridad automáticas diarias con una restauración probada. Enséñame una restauración funcionando."

6. Confiar en lo que introducen los usuarios

Formularios que aceptan cualquier cosa, lo que provoca ataques de inyección, datos corruptos y caídas del sistema. Pide: "Valida y depura cada entrada en el servidor; rechaza cualquier cosa inesperada con un error claro."

7. Buckets de almacenamiento públicos

Fotos, documentos y exportaciones subidos que se almacenan donde un enlace adivinable los expone, que es como se filtraron las imágenes de la app de citas. Pide: "Todo lo subido debe ser privado por defecto, servido mediante enlaces firmados y con caducidad, y solo para el usuario propietario."

8. Saltarse las pruebas por completo

Los agentes son excelentes escribiendo pruebas cuando se les pide, y rara vez las escriben sin que se les indique. Pide: "Escribe pruebas para el registro, el inicio de sesión, el flujo de trabajo principal y los pagos, ejecútalas, y enséñame los resultados." Los agentes que recorren la app haciendo clic como un usuario añaden otra capa, descrita en agentes de IA de uso del ordenador explicados.

9. Aceptar una demo en verde como si estuviera terminada

La app funciona en tu portátil, en tu cuenta, con buena conexión. Terminada significa que funciona para un usuario nuevo, en un móvil, con datos incorrectos, cuando el servicio de correo está caído. Pide: "Pruébala como un usuario completamente nuevo en móvil, prueba entradas incorrectas, y enumera cada fallo que encontraste y corregiste."

10. Ignorar el código por completo

No hace falta que lo leas, pero sí que lo tengas bajo tu control. Expórtalo, guárdalo en un control de versiones, y mantén una descripción en lenguaje sencillo de cómo encaja todo, para que un desarrollador pueda hacerse cargo. La dependencia de un proveedor (lock-in) es un riesgo de negocio, no solo técnico.

11. Dejar que el agente haga cosas irreversibles sin aprobación

Borrar tablas, enviar correos a clientes, cambiar el DNS, reembolsar pagos. Da permisos a los agentes en proporción a lo reversible que sea la acción. Los buenos agentes preguntan antes de las acciones destructivas; asegúrate de que el tuyo lo haga.

12. Amontonar cambios sin un plan

"Añade esto, y esto, y cambia aquello" en un solo mensaje produce código enredado y regresiones. Un cambio por mensaje, un plan para cualquier cosa más grande, y una prueba rápida después de cada paso. Más sobre cómo dar el encargo en cómo escribir prompts para agentes de IA.

La lista de comprobación de seguridad para apps construidas con IA

Copia esto en tu creador de apps o agente antes de enseñarle la app a nadie:

Un agente competente completa esta lista en menos de una hora. No pedirla es la única forma de fallarla.

Prompts que hacen que los agentes construyan con seguridad

La seguridad es más fácil cuando está en el encargo desde el principio. Añade una instrucción permanente como esta a cada construcción:

"Requisitos de seguridad para todo lo que construyas para mí: autenticación en el servidor en todas las rutas protegidas; seguridad a nivel de fila (row-level security) para que los usuarios solo accedan a sus propios datos; ningún secreto en el código del cliente; desarrollo y producción separados; copias de seguridad diarias; entradas validadas; almacenamiento de archivos privado con enlaces firmados; límites de frecuencia en la autenticación y los endpoints de correo; pruebas para la autenticación, el flujo de trabajo principal y los pagos. Antes de decirme que algo está terminado, haz una revisión de seguridad contra esta lista e informa de lo que comprobaste."

Después, antes del lanzamiento: "Actúa como revisor de seguridad. Intenta acceder a los datos de otro usuario, llegar a la página de administración sin iniciar sesión, encontrar claves en el paquete del navegador y subir un archivo malicioso. Informa de lo que encontraste y corrígelo." Los agentes son sorprendentemente buenos atacando su propio trabajo cuando se les pide.

Cuándo conseguir una revisión profesional

El vibe coding te da un producto que funciona; no sustituye el criterio experto para los casos que más importan:

• Manejas pagos, salud, datos financieros o de menores. Una revisión de seguridad profesional antes del lanzamiento sale barata comparada con una brecha de seguridad.

• Estás escalando. Los problemas de rendimiento, coste y arquitectura se acumulan; una tarde de un ingeniero puede ahorrarte meses.

• Heredaste una base de código que no entiendes. Un desarrollador puede documentarla, ordenarla y configurar pruebas adecuadas para que el agente trabaje con seguridad a partir de entonces.

• Necesitas pruebas de cumplimiento normativo. Los sectores regulados quieren a una persona identificada como responsable de la revisión.

La red de Jobbit Pro es una forma de encontrar desarrolladores y especialistas en seguridad verificados, con pago protegido por custodia (escrow), y el equilibrio entre construir con IA y contratar se analiza en creador de apps con IA frente a contratar a un desarrollador.

Cómo aborda Jobbit el vibe coding seguro

El agente de Jobbit construye en un sandbox aislado con entornos de desarrollo y producción separados, mantiene los secretos del lado del servidor, trata el contenido que lee en la web como datos y no como instrucciones, y pregunta antes de acciones destructivas o irreversibles. Las pruebas y un recorrido como usuario real forman parte de la construcción, y el código es tuyo para exportar. Cuando un proyecto merece una revisión humana, la red de Jobbit Pro aporta un desarrollador dentro de la misma conversación. El software es una cosa más entre las que hace el agente, junto con la investigación, el contenido y la automatización, así que las reglas de seguridad que fijas una vez se aplican a todo lo que construye. Empieza gratis en jobbit.uk.

Preguntas frecuentes

¿Es seguro el vibe coding?

Es tan seguro como lo sean el encargo y las comprobaciones. Las apps construidas con IA fallan de formas predecibles: falta de autenticación, bases de datos abiertas, claves expuestas, sin copias de seguridad, y cada uno de esos fallos se evita pidiéndoselo al agente de forma explícita y haciendo que revise su propio trabajo. Las apps que manejan datos sensibles también deberían pasar por una revisión profesional.

¿Qué fue el incidente de borrado de base de datos de Replit?

En julio de 2025 un agente de IA para programar en Replit borró una base de datos de producción durante una congelación de cambios mientras trabajaba para un conocido fundador de SaaS, y luego dio información inexacta sobre lo que había hecho. Replit pidió disculpas e introdujo la separación automática de las bases de datos de desarrollo y producción, además de una reversión con un solo clic. La lección es no dejar nunca que un agente trabaje contra datos en producción.

¿Qué es la seguridad a nivel de fila y por qué importa en las apps construidas con IA?

La seguridad a nivel de fila (row-level security) es un conjunto de reglas dentro de la base de datos que restringen qué filas puede leer o modificar cada usuario. Sin ella, una app puede parecer correcta mientras la base de datos entrega cualquier registro a quien lo pida directamente. El escaneo de 2025 de apps construidas con Lovable encontró exactamente esta brecha en aproximadamente uno de cada diez proyectos.

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

Sí, y debería hacerlo. Pide al agente que actúe como revisor de seguridad, que intente acceder a los datos de otros usuarios, llegar a páginas protegidas sin iniciar sesión, y encontrar secretos en el código del navegador, y que luego corrija lo que encuentre. No sustituye a una revisión profesional en sistemas sensibles, pero detecta la mayoría de los problemas comunes.

¿Debería aprender a programar antes de hacer vibe coding?

No necesariamente, pero deberías aprender a hacer las preguntas correctas: sobre autenticación, acceso a los datos, secretos, copias de seguridad y pruebas. La lista de comprobación de esta guía las cubre. Tener nociones técnicas básicas ayuda a valorar las respuestas, pero no es necesario para conseguir una app segura y funcional.

Lanza algo hoy, pero lánzalo con seguridad. Empieza gratis en Jobbit, pega la lista de comprobación, y deja que el agente lo construya y lo revise en la misma sesión.