El término “vibe coding” lo acuñó Andrej Karpathy en febrero de 2025 para describir una forma de programar en la que te dejas llevar por la intuición y te olvidas de que el código existe. En esa misma publicación dijo que para proyectos desechables de fin de semana no estaba tan mal. Tenía razón.
El problema empieza cuando ese código que “no existe” cobra pagos, guarda datos de clientes o sostiene un negocio. Esa es la versión que me llega: alguien armó una app con Lovable, Bolt, Cursor o Replit, en la demo funcionaba, llegaron usuarios reales y algo empezó a fallar. No leo esos proyectos de principio a fin. Reviso una lista corta en un orden concreto, porque hay fallas que cuestan una tarde mala y otras que cuestan los datos de tus clientes. Este artículo es esa lista.
Lo primero que se rompe suele ser el control de acceso: un usuario puede ver los datos de otro. Después, en el orden en que lo reviso: claves secretas que llegan al navegador, webhooks de pago que procesan dos veces o aceptan eventos falsos, una herramienta de IA con acceso a producción, consultas que colapsan con datos reales, fallas silenciosas y código que solo su autor puede tocar sin miedo.
Lo que muestran los datos públicos
Veracode probó código de más de 100 modelos de lenguaje y encontró que el 45% de las muestras no pasó las pruebas de seguridad (en inglés) e introducía vulnerabilidades del OWASP Top 10. Los modelos más nuevos y más grandes no salieron mejor parados en seguridad. Otras dos fuentes públicas apuntan en la misma dirección:
- En la encuesta de desarrolladores 2025 de Stack Overflow (en inglés), el 84% usa o piensa usar herramientas de IA, pero el 46% desconfía de la precisión de lo que generan y solo el 33% confía. La frustración más citada, por el 66%, fue recibir soluciones que están “casi bien, pero no del todo”.
- CodeRabbit comparó 470 pull requests de proyectos de código abierto y encontró cerca de 1,7 veces más problemas (en inglés) en los cambios escritos con ayuda de IA que en los hechos solo por personas. Las operaciones de entrada y salida excesivas aparecían unas ocho veces más.
Lo importante está en ese “casi bien”. El código que falla a la vista se corrige. El que está casi bien llega a producción.
Dónde el vibe coding no es problema
Prototipos que vas a tirar. Scripts de un solo uso. Herramientas internas sin datos sensibles. Maquetar pantallas, donde un diseño roto se ve apenas lo abres. En todos esos casos fallar es barato y ruidoso. Lo peligroso son las fallas silenciosas, y esas se concentran en unos pocos lugares previsibles.
El orden en que reviso
Esta es la lista completa en una sola vista. Cada punto tiene su sección más abajo.
| # | Revisión | Qué se rompe | Cómo comprobarlo |
|---|---|---|---|
| 1 | Aislamiento de datos | Un usuario puede leer o cambiar registros de otro | Corre la consulta de RLS de abajo y pide el ID de otro usuario con tu sesión |
| 2 | Claves secretas | Claves como sk_live o service_role llegan al navegador o al historial de git |
Busca en el resultado de la compilación y en el historial de git cualquier cosa con cara de clave |
| 3 | Dinero y efectos secundarios | Los webhooks procesan dos veces el mismo pago o aceptan uno falso | Confirma que se registran los ID de eventos procesados y que se verifica la firma |
| 4 | Acceso de la herramienta de IA | Un agente con credenciales de producción borra o reescribe datos | Bases de desarrollo y producción separadas, sin claves de producción en la herramienta, un respaldo ya restaurado |
| 5 | Volumen de datos | Tablas enteras en memoria, una consulta por fila, una conexión por petición | Llena la base con volúmenes realistas y mide las pantallas más lentas |
| 6 | Manejo de fallas | Ruedas que giran para siempre, registros a medias, detalles técnicos a la vista del usuario | Corta la conexión con una API externa y verifica que los errores se reporten |
| 7 | Mantenibilidad | Nadie más que el autor original puede cambiar el código con tranquilidad | Pruebas en autenticación, pagos y reglas centrales de datos, más un despliegue reproducible |
1. ¿Un usuario puede ver los datos de otro?
Va primero porque es el error más caro y de los más comunes. Muchas apps hechas con IA hablan con la base de datos directamente desde el navegador, casi siempre a través de Supabase o Firebase, y dependen de reglas en la base de datos para decidir quién ve qué. Si esas reglas no están, cualquiera con la clave pública que viaja en tu frontend puede consultar tus tablas.
No es un caso teórico. El CVE-2025-48757 describe una seguridad a nivel de fila insuficiente en sitios generados con Lovable, que permitía a atacantes sin autenticar leer o escribir en cualquier tabla. Lovable disputó el CVE con el argumento de que cada cliente es responsable de proteger los datos de su propia aplicación. Más allá de lo que opines de ese argumento, deja claro quién termina cargando con el problema: tú.
Si usas Supabase, esta consulta te muestra las tablas sin seguridad a nivel de fila (RLS):
select tablename
from pg_tables
where schemaname = 'public' and rowsecurity = false;Cada tabla de esa lista está expuesta, salvo que hayas revocado los permisos. La propia guía de RLS de Supabase (en inglés) indica activarla en todas las tablas de un esquema expuesto. Después, entra como un usuario y pide el registro de otro cambiando el ID en la URL o en la llamada a la API. Si te lo devuelve, tienes un problema, uses el stack que uses.
2. ¿Hay claves secretas en el frontend?
Compila la app y busca en el resultado cualquier cosa con cara de clave: sk_live, service_role, secret, tokens de OpenAI u otros servicios de pago. Revisa también el historial de git, porque una clave que se subió y luego se borró sigue ahí. Toda clave que haya llegado al navegador o al repositorio hay que rotarla; borrarla no basta.
3. ¿Qué pasa con el dinero y los efectos secundarios?
Pagos, correos, movimientos de inventario, todo lo que ocurre una sola vez en el mundo real. La documentación de Stripe lo dice claramente: un endpoint de webhooks puede recibir el mismo evento más de una vez (en inglés), y recomienda registrar los ID de eventos ya procesados para no repetirlos. Los manejadores generados con IA muchas veces se saltan ese paso, y a veces también la verificación de la firma, lo que significa que cualquiera puede mandarle a tu endpoint un “pago exitoso” falso. Las dos cosas se revisan y se corrigen rápido.
Con las tareas en segundo plano pasa lo mismo: si dos procesos pueden tomar la misma tarea, tarde o temprano algo va a ocurrir dos veces.
4. ¿La herramienta de IA tiene acceso a producción?
En julio de 2025, el agente de Replit borró la base de datos de producción (en inglés) del proyecto de Jason Lemkin, fundador de SaaStr, en medio de un congelamiento de código que él había declarado de forma explícita. Lo mismo puede pasar con cualquier agente que tenga credenciales de producción, sea del proveedor que sea. Reviso si desarrollo y producción usan bases de datos separadas, si la herramienta de programación tiene acceso a claves de producción y si existe un respaldo que alguien haya restaurado al menos una vez.
5. ¿Aguanta volúmenes de datos reales?
Al código generado le encanta cargar una tabla entera en memoria, hacer una consulta por fila dentro de un ciclo y abrir una conexión nueva a la base de datos en cada petición. Con diez registros de prueba nada de eso se nota. Se nota cuando tu cliente más grande abre el tablero. Lo primero que hago en este punto es llenar la base con volúmenes realistas y medir las pantallas más lentas.
6. ¿Qué pasa cuando algo falla?
Corta la conexión con una API externa y mira qué hace la app. Lo habitual: una ruedita que gira para siempre, un registro guardado a medias, un mensaje de error que le muestra al usuario el detalle técnico completo. Después fíjate si los errores se reportan en algún lado. Si la única forma de enterarte de una falla es la queja de un cliente, activa el monitoreo de errores antes de tocar cualquier otra cosa.
7. ¿Otra persona puede modificarla sin miedo?
La última revisión es si alguien distinto del autor original (persona o IA) puede cambiar el código con tranquilidad. Eso implica pruebas en los puntos donde un error sale caro (permisos, pagos, las reglas centrales de los datos), un despliegue reproducible y código que un ingeniero nuevo pueda seguir. Cuando valido ingenieros, ese es justamente el criterio que busco: alguien que lee un cambio y pregunta qué pasa cuando falla.
Usar IA sin dejarse llevar
Uso herramientas de IA todos los días y no le pido a nadie que deje de usarlas. Lo que cambia es quién tiene en la cabeza el modelo del sistema. Mis reglas son pocas:
- Nadie integra código que no pueda explicar línea por línea.
- Los agentes de programación no tienen credenciales de producción, no corren migraciones contra producción y no despliegan.
- Las pruebas van donde los errores cuestan (permisos, dinero, integridad de los datos), no donde suben un porcentaje de cobertura.
- Una persona senior decide la arquitectura. La IA acelera la escritura; no decide por dónde circulan los datos.
Si ya lanzaste una app hecha así
Calma, y no la reescribas todavía. La mayoría de estas apps se pueden reforzar. Esta semana:
- Corre la revisión de seguridad a nivel de fila y cierra cada tabla expuesta.
- Rota todas las claves que hayan pasado por el frontend o por el repositorio.
- Agrega verificación de firma y control de duplicados a los webhooks de pago.
- Haz un respaldo y restáuralo en otro lado para comprobar que sirve.
- Activa el monitoreo de errores.
Reescribir solo tiene sentido cuando el modelo de datos está mal de raíz, y esa es otra conversación. Si quieres otro par de ojos sobre esta lista, escríbeme.
Actualizado el 23 de septiembre de 2026: reescrito, y se retiraron cifras que no podía respaldar.