Saltar al contenido

¿El vibe coding es malo? 5 riesgos reales y cómo evitarlos

¿El vibe coding es malo? 5 riesgos reales, de fallos de seguridad a costos que se disparan y código que nadie mantiene, más una lista de seguridad.

Por Yotam DahanActualizado 15 min de lecturaCrear con IA

¿El vibe coding es malo? Una auditoría de seguridad real de Claude Code a una app de reservas hecha con vibe coding clasifica 3 hallazgos críticos, 2 altos, 1 medio y 1 bajo

¿El vibe coding es malo? No en sí mismo, pero publicar código escrito por IA que nadie ha revisado se vuelve arriesgado en cuanto hay clientes, dinero o datos personales de por medio. Para una landing page, un prototipo o una herramienta interna, los riesgos son pequeños y fáciles de manejar. Para cualquier cosa con inicios de sesión, pagos o datos de clientes guardados, necesitas las protecciones de abajo y, normalmente, una revisión humana.

¿Es seguro el vibe coding? Depende de lo que construyas

El vibe coding es lo bastante seguro para proyectos personales, prototipos y páginas simples, y arriesgado para cualquier cosa que guarde cuentas, pagos o datos personales, salvo que alguien lo revise.

Lo que construyesRiesgoQué puede salir malProtecciones mínimas
Herramienta personal o prototipoBajoSe rompe y pierdes algo de tiempoHistorial de versiones
Landing page o sitio informativoBajoUn formulario roto, precios equivocados, un hueco de privacidadPrueba el formulario, revisa cada dato, agrega una página de privacidad
Herramienta interna con datos de la empresaMedioCifras erróneas guían decisiones, o los datos llegan a quien no debePrueba con resultados conocidos, limita quién puede abrirla
App con cuentas de usuarioAltoDesconocidos leyendo datos de otros usuariosServicio de inicio de sesión probado, auditoría de reglas de acceso, revisión humana
Pagos, datos de salud o financierosMuy altoFraude, responsabilidad legal, pérdida de confianzaCheckout alojado, revisión profesional de seguridad antes de publicar

La mayoría de los primeros proyectos están en las dos filas de arriba, que es justo donde el vibe coding funciona bien. Los cinco problemas del vibe coding de abajo importan más cuanto más bajas en la tabla.

Riesgo 1: fallos de seguridad del vibe coding que no ves

El código que funciona y el código seguro son cosas distintas, y la investigación sobre los riesgos de seguridad del vibe coding lo dice sin rodeos.

Hallazgos de seguridad en código hecho con IA
56%

tasa promedio de aprobación en seguridad del código escrito por IA en las pruebas de Veracode de 2026

11.8%

de las soluciones de un agente eran seguras, aunque el 57% funcionaba

170

de 1,645 proyectos de Lovable analizados tenían reglas de acceso a la base de datos insuficientes

Fuentes: GenAI Code Security Report 2026 de Veracode, el estudio SusVibes en ICML 2026 y la declaración sobre CVE-2025-48757.

El informe de Veracode de julio de 2026 encontró que la seguridad estaba "prácticamente sin cambios" desde 2025, aunque los modelos mejoraron en escribir código que funciona, y los modelos especializados en programación no eran más seguros que los generales. En el estudio SusVibes, SWE-Agent con Claude 4 Sonnet produjo soluciones que funcionaban el 57% de las veces, pero seguras solo el 11.8%, y agregar indicaciones de seguridad a la petición no lo arregló.

El hallazgo sobre Lovable vino de investigadores que analizaron proyectos en marzo de 2025 y publicaron el problema en mayo como CVE-2025-48757, un identificador público para una vulnerabilidad conocida. Esas apps funcionaban. El problema era la row level security (RLS), las reglas dentro de una base de datos que deciden qué filas puede ver o cambiar cada visitante.

Cómo una app que funciona filtra datos
  1. El visitante abre la app

    Su navegador recibe una clave pública de la base de datos

  2. Faltan reglas de acceso

    La base de datos no comprueba quién pregunta

  3. Cualquiera puede consultar

    Un desconocido puede leer o editar todas las filas

  4. Nadie se da cuenta

    La app sigue funcionando perfectamente para los usuarios normales

Lovable y Bolt pueden conectarse a Supabase, un servicio de base de datos popular. El propio Security Advisor de Supabase califica una tabla sin estas reglas como un ERROR llamado Table publicly accessible, porque cualquiera con la URL de tu proyecto puede leer, editar y borrar todo lo que contiene.

  • Usa servicios probados para inicios de sesión y pagos en lugar de dejar que la IA invente los suyos.
  • Mantén las claves secretas fuera del código del navegador. Una clave de API es una contraseña que permite al software usar un servicio de pago, así que guárdala en las variables de entorno de tu hosting.
  • Revisa cada paquete nuevo. Los modelos que escriben código a veces nombran paquetes complementarios que no existen: en un estudio de USENIX Security 2025 con 576,000 muestras de código, los modelos comerciales lo hicieron al menos el 5.2% de las veces. Los atacantes pueden publicar malware con esos nombres, así que pídele a la IA que confirme que cada paquete nuevo es real y de uso extendido antes de instalar nada.
  • Haz que la IA ataque su propia app con el prompt de abajo, y luego arregla lo que encuentre.
  • Consigue una revisión humana para todo lo que esté en las dos últimas filas de la tabla.
Autoauditoría de seguridad
Audita este proyecto en busca de problemas de seguridad antes de publicarlo. Revisa:
1. Cada tabla de la base de datos: ¿un visitante sin sesión puede leer, agregar o cambiar filas?
2. Cualquier clave de API o contraseña visible en el código del navegador o en archivos guardados en el repositorio.
3. Formularios: ¿qué pasa con textos muy largos, vacíos o maliciosos?
4. Páginas o endpoints que funcionan sin iniciar sesión pero no deberían.
Explica cada hallazgo en español sencillo, ordénalos por gravedad y
no cambies nada de código hasta que yo apruebe las correcciones.

Ejecutamos exactamente este prompt en Claude Code sobre una pequeña app de reservas de demostración, armada con los errores con los que suelen salir las apps hechas con vibe coding: una tabla de Supabase, un formulario público y un botón de administración oculto. Leyó los cuatro archivos, no cambió nada y clasificó siete hallazgos en 38 segundos: tres críticos, dos altos, uno medio y uno bajo. Los dos primeros son los mismos riesgos de seguridad del vibe coding que describe la investigación de arriba: una clave secreta en el código del navegador y una tabla sin reglas de acceso.

Prompt de autoauditoría de seguridad en vibe coding ejecutándose en Claude Code, que marca como crítica una clave secreta de Stripe en vivo dentro del código del navegador
El prompt de autoauditoría de seguridad en una sesión real de Claude Code. Primero trabaja en modo de solo lectura y empieza por el peor hallazgo: una clave secreta de pagos que cualquiera puede leer con F12.

Además responde directamente cada pregunta que hiciste. Para la pregunta 1 explicó con detalle qué puede hacerle un desconocido sin sesión a la tabla de reservas, que es exactamente el hueco detrás de CVE-2025-48757:

Auditoría de Claude Code que muestra una tabla de reservas de Supabase con RLS desactivada: los visitantes sin sesión pueden leer, agregar, cambiar y borrar todas las filas
La row level security estaba desactivada, así que cualquiera podía leer el nombre y el teléfono de cada cliente, o borrar todas las reservas, sin usar la app.

Termina con un pedido como "Dame un resumen de una pantalla que pueda pegar en mi lista de lanzamiento: una línea por hallazgo, la gravedad primero" para obtener la lista clasificada que aparece al inicio de esta página, luego aprueba las correcciones de una en una y vuelve a ejecutar la auditoría.

¿Lovable es seguro?

Más seguro que antes. Lovable ahora ejecuta un Quick scan cada vez que publicas, y busca exactamente estos huecos: reglas de acceso a la base de datos, paquetes con vulnerabilidades conocidas y servidores MCP que tu app expone sin inicio de sesión. No evalúa la lógica propia de tu app, y la documentación de seguridad de Lovable dice que las herramientas no pueden garantizar una seguridad completa y sugiere una revisión profesional para apps que manejan datos sensibles.

Riesgo 2: la IA hace algo destructivo

Uno de los desastres del vibe coding más conocidos: en julio de 2025, Jason Lemkin, fundador de SaaStr, contó que el agente de IA de Replit borró su base de datos de producción, los datos en vivo de los que dependía su proyecto, pese a las instrucciones de no cambiar nada sin permiso, según informó The Register. El agente tenía acceso a datos en vivo y nada técnico se lo impidió.

  • Separa los datos de prueba de los reales. Construye sobre una copia y conecta la base de datos real solo al publicar.
  • Mantén un historial de versiones que controles tú. Haz commit en Git después de cada paso que funcione. Los checkpoints de Claude Code pueden deshacer sus propias ediciones de archivos, pero no los cambios hechos por los comandos que ejecuta.
  • Elige un modo que pregunte primero. Las versiones recientes de Claude Code en la terminal y en VS Code empiezan en Auto mode, donde un clasificador en segundo plano aprueba acciones por ti. Para trabajo sensible, presiona Shift+Tab o usa el selector de modo de la app de escritorio para cambiar a Manual, que pregunta antes de editar archivos o ejecutar comandos.

Riesgo 3: costos que suben poco a poco

La mayoría de las herramientas de vibe coding cobran por uso, así que el contador corre mientras iteras. El momento caro es el bucle de depuración: la IA no logra arreglar un error, vuelves a pedirlo y cada intento cuesta.

Dónde se esconden los costos del vibe coding

Créditos

Los constructores en el navegador como Lovable cobran créditos por construir, y las recargas cuestan aparte cuando se acaba la cuota mensual.

Tokens

Bolt cobra en tokens, los trozos de texto que la IA lee y escribe, así que las sesiones largas en proyectos grandes gastan más.

Límites del plan

Claude Pro y Max tienen un límite por sesión de cinco horas más un límite semanal, compartidos entre el chat y Claude Code.

Hosting

Los planes de hosting de pago suelen agregar cargos por uso cuando el tráfico o el cómputo superan lo incluido.

  • Planifica antes de construir. Un plan claro significa menos reconstrucciones caras.
  • Para después de dos arreglos fallidos. Usa el prompt de abajo en lugar de pedirlo por tercera vez.
  • Configura alertas de presupuesto que actúen. En Vercel Pro, un monto de Spend Management solo te avisa, a menos que también actives Pause Production Deployments.
  • Conoce los límites de tu plan. Mira los límites de uso de Claude Code y los precios de Claude Code.
Rompe el bucle de depuración
Deja de cambiar código. Explica en español sencillo qué crees que está causando
este problema, qué has probado hasta ahora y por qué no funcionó. Luego
dame dos formas distintas de arreglarlo, con los riesgos de cada una, y espera
a que yo elija.

Riesgo 4: deuda técnica que nadie puede mantener

El software necesita mantenimiento, y el código que nadie entiende se acumula como deuda técnica: cada cambio se vuelve más lento y más arriesgado. En diciembre de 2025, el equipo de React reveló un fallo en React Server Components (CVE-2025-55182) que permitía a atacantes ejecutar código en los servidores afectados, con una calificación de 10.0, el máximo de la escala estándar de gravedad.

Las apps construidas con frameworks como Next.js tuvieron que actualizarse de inmediato, y el equipo de React advirtió que no había que confiar en las protecciones temporales de los proveedores de hosting. Una app hecha con vibe coding sin nadie pendiente de avisos como ese simplemente queda expuesta.

  • Elige el stack más simple. Las apps sin servidor no se vieron afectadas por ese fallo, así que sigue el enfoque de HTML simple de crear una página web con IA siempre que encaje.
  • Deja todo por escrito. Pídele a la IA un README y un archivo CLAUDE.md que expliquen cómo funciona el proyecto y cómo cambiarlo.
  • Agenda una revisión mensual. Pídele a tu herramienta de IA que busque dependencias desactualizadas o vulnerables y que las actualice una por una.
  • Evita quedar atrapado. Asegúrate de poder exportar el código o sincronizarlo con GitHub.

Riesgo 5: huecos de privacidad y legales

Incluso una página simple crea obligaciones en cuanto recoge nombres, correos o teléfonos. Las leyes de privacidad de donde viven tus clientes pueden exigir un aviso de privacidad, consentimiento para marketing y límites sobre cómo usas los datos.

  • Recoge solo lo que necesitas. Un nombre y un teléfono pueden bastar para una reserva.
  • Di qué recoges. Publica una página de privacidad corta que explique qué reúne el formulario y adónde va.
  • Revisa tu seguimiento. La analítica y los píxeles publicitarios pueden necesitar un banner de consentimiento, según dónde estén tus visitantes.
  • Trata los textos legales de la IA como un borrador. La IA puede redactar una política de privacidad o unos términos, pero no puede responsabilizarse de ellos.

¿El vibe coding es malo para una pequeña empresa? Pros y contras

Para muchas pequeñas empresas, la alternativa a una herramienta hecha con vibe coding no es una app diseñada con cuidado. Es nada, o una plantilla que no les gusta y no pueden cambiar. Estos son los pros y contras del vibe coding lado a lado:

ProsContras
Probar una idea con poco dinero antes de contratar a nadieEl código que funciona puede seguir siendo inseguro
Construir herramientas internas que nadie habría financiadoLos bucles de depuración queman créditos y uso del plan
Darle a un desarrollador un prototipo que funciona en lugar de un brief vagoAlguien tiene que mantenerlo actualizado
Cambiar tu propio sitio sin esperar a nadieEres responsable de los datos que recoge

En cuanto revisas y pruebas lo que construye la IA, ya no estás haciendo vibe coding puro, como explica la guía sobre qué es el vibe coding. Cuando construyo para clientes con IA, la herramienta nunca es lo que hace seguro el resultado. Lo hacen las comprobaciones aburridas de alrededor, y para eso está la lista de abajo.

Señales de alerta y qué hacer

Lo que vesQué significaQué hacer
Table publicly accessible en el Security Advisor de SupabaseUna tabla no tiene row level securityActiva RLS y agrega reglas de acceso antes de que alguien más use la app
El análisis de Lovable reporta problemas cuando abres PublishEl Quick scan encontró un hueco en la base de datos o en las dependenciasCorrige cada hallazgo y luego ejecuta un Deep scan desde la vista Security
npm audit muestra una vulnerabilidad criticalUn paquete del que dependes tiene un fallo conocidoPídele a la IA que actualice solo ese paquete, prueba y vuelve a publicar
Una clave de API aparece en el código del navegador o en GitHubCualquiera que la encuentre puede usar tu cuenta de pagoRevócala y crea una nueva con el proveedor, y guarda la nueva en variables de entorno. Borrarla del archivo no basta, porque el historial de Git guarda las versiones viejas
Un error que arreglaste vuelve después del siguiente cambioNadie entiende el código lo suficientePide primero una explicación, y haz commit después de cada arreglo que funcione
El uso o la factura del hosting se disparan de un día para otroAlgo se ejecuta en bucle o lo están abusandoPausa el proyecto, encuentra el disparador y agrega un límite

La lista de seguridad para vibe coding

Antes de construir

0 de 4 hechas

Mientras construyes

0 de 4 hechas

Antes de publicar

0 de 6 hechas

Después de publicar

0 de 3 hechas

Comprueba lo que sabes0 de 3 correctas

Una app hecha con IA funciona perfectamente para los usuarios normales. ¿Aun así puede filtrar datos?

La IA no ha logrado arreglar el mismo error dos veces. ¿Cuál es el siguiente paso más barato?

Claude Code ejecutó un comando que borró un archivo. ¿Cómo lo recuperas?

Qué hacer ahora

Busca tu proyecto actual o el que tienes en mente en la tabla de riesgos y recorre las secciones de la lista que le corresponden antes de publicar nada. Si está en las dos últimas filas, reserva presupuesto para la revisión de un desarrollador ahora, no después de publicar.

Para comparar herramientas por sus protecciones y precios, mira las mejores herramientas de vibe coding. El curso Builders incluye lecciones sobre seguridad básica, accesibilidad y privacidad para los sitios que construyes con IA.

Prompts de auditoría de seguridad antes de publicar

10 prompts que hacen que tu herramienta de IA audite su propio trabajo en busca de datos expuestos, claves filtradas, reglas de acceso débiles y bucles costosos, con cómo se ve una buena respuesta.

Escribe tu correo y la sección completa se abre aquí mismo. Además recibes una clase gratis del curso.

Sin spam. Te das de baja con un clic. Usamos tu correo para enviarte el curso y consejos de IA.

Preguntas frecuentes

¿El vibe coding va a reemplazar a los desarrolladores?

No en el trabajo donde la fiabilidad importa. Permite que personas que no programan construyan cosas pequeñas para las que nunca habrían contratado a nadie, y acelera a los desarrolladores, pero alguien tiene que entender, proteger y mantener el software del que dependen los clientes.

¿El vibe coding es malo para principiantes o para aprender a programar?

Puede serlo si aceptas todo sin leerlo. Si le pides a la IA que explique cada cambio y de vez en cuando haces pequeñas ediciones tú mismo, funciona como un tutor paciente que te muestra ejemplos reales que funcionan.

¿Quién es responsable si un sitio hecho con vibe coding filtra datos de clientes?

En general, tu negocio. Las normas de privacidad ponen la obligación en quien recoge y guarda los datos, sin importar cómo se escribió el código, y por eso todo lo que guarda información personal merece una revisión seria.

¿Por qué el código generado con IA tiene fallos de seguridad?

Los modelos aprenden de enormes cantidades de código público, bueno y malo, y están ajustados para producir código que funcione. La seguridad es un objetivo aparte, así que normalmente tienes que pedirla de forma explícita y luego comprobar el resultado.

¿Cómo encuentro un desarrollador que revise mi app hecha con vibe coding?

Busca un desarrollador freelance que conozca tu stack, por ejemplo Next.js con Supabase, y pídele una revisión de seguridad y de código a precio cerrado. Comparte el código por GitHub junto con una lista de lo que hace la app, para que se concentre en los inicios de sesión, el acceso a datos y los pagos.

¿El vibe coding es malo para el medio ambiente?

Cada petición a la IA se ejecuta en hardware de centros de datos que consume electricidad, y una sesión de agente envía muchas peticiones, así que los bucles largos de depuración cuestan energía además de dinero. Planificar primero, mantener las peticiones pequeñas y parar después de dos arreglos fallidos reduce las dos cosas.

Sigue leyendo