Vibe coding: los riesgos de seguridad y escalabilidad de las webs hechas con IA
En resumen: el vibe coding —pedirle a una IA que escriba una aplicación completa y publicarla sin entender ni revisar el código— sirve para prototipos, no para productos que manejan dinero, datos de clientes o tráfico real. Los fallos más comunes son claves expuestas, endpoints sin autorización, bases de datos abiertas, dependencias inventadas y arquitecturas que colapsan al crecer. La IA acelera, pero la ingeniería (revisión, pruebas, seguridad y arquitectura) sigue siendo lo que hace que un producto funcione y no te exponga.
¿Qué es el vibe coding?
El término lo popularizó Andrej Karpathy a comienzos de 2025 para describir una forma de programar en la que "te dejas llevar por las vibras": describes lo que quieres en lenguaje natural, aceptas lo que genera la IA y, si algo falla, pegas el error y pides que lo arregle. No lees el código; solo miras si "parece funcionar".
Para una demo de fin de semana es fantástico. El problema empieza cuando ese mismo resultado se entrega como la web o la app de un negocio: con usuarios reales, pagos, datos personales y la expectativa de que funcione igual con 10 que con 10.000 personas.
¿Por qué una web hecha "a punta de prompts" puede salir cara?
Porque la IA optimiza para que el código se vea correcto y compile, no para que sea seguro, mantenible ni escalable. Y quien no sabe leer ese código tampoco puede detectar lo que falta. Varios análisis independientes publicados en 2025 —entre ellos el informe de seguridad de código generado por IA de Veracode— encontraron vulnerabilidades en una proporción muy alta del código que los modelos producen cuando nadie lo revisa.
Lo que vemos una y otra vez al auditar proyectos que llegan a Key Lab:
1. Claves y secretos expuestos en el navegador
Claves de API de pagos, de correo o de la base de datos escritas directamente en el código del frontend. Cualquiera que abra las herramientas de desarrollador del navegador puede copiarlas y usarlas a tu nombre (y a tu costo).
2. Endpoints sin autorización real
La pantalla oculta el botón de "borrar usuario" a quien no es administrador, pero el endpoint del servidor no verifica quién hace la petición. Basta con llamar la URL directamente para leer o modificar datos de otros clientes.
3. Bases de datos abiertas
Tablas sin reglas de acceso por fila (row-level security), colecciones públicas en servicios backend as a service o conexiones permitidas desde cualquier IP. Es el tipo de error que termina en una filtración de datos.
4. Inyecciones y validación inexistente
Entradas del usuario que llegan sin validar a consultas, comandos o plantillas: inyección SQL/NoSQL, XSS, subida de archivos sin control de tipo ni tamaño.
5. Dependencias inventadas o abandonadas
Los modelos a veces sugieren paquetes que no existen. Atacantes registran esos nombres con código malicioso (una técnica conocida como slopsquatting). Otras veces se instalan librerías sin mantenimiento con vulnerabilidades conocidas.
6. Cero pruebas, cero monitoreo
Sin pruebas automatizadas, cada cambio "rompe algo en otra parte". Sin registros ni alertas, te enteras de un fallo cuando un cliente se queja —o cuando ya perdiste ventas.
¿Y la escalabilidad?
Una app puede funcionar perfecto con cinco usuarios de prueba y caerse el día del lanzamiento. Los síntomas típicos:
- Consultas N+1 y sin índices: cada página dispara cientos de consultas a la base de datos.
- Todo en el cliente: lógica pesada y datos completos descargados en el navegador, lo que hace lento el sitio en celulares.
- Sin caché ni colas: cada petición recalcula todo; los procesos largos bloquean al usuario.
- Estado y archivos en el servidor equivocado: imposible escalar horizontalmente o desplegar sin perder datos.
- Costos que se disparan: llamadas a APIs de IA o de terceros sin límites, reintentos ni control de uso.
Vibe coding vs. ingeniería asistida por IA
| Vibe coding | Ingeniería asistida por IA | |
|---|---|---|
| Quién decide la arquitectura | El modelo, prompt a prompt | Un equipo, antes de escribir código |
| Revisión del código | Ninguna ("si corre, sirve") | Revisión humana + análisis automático |
| Seguridad | Se asume | Se diseña: autenticación, autorización, secretos, validación |
| Pruebas | Manuales, a veces | Automatizadas en cada cambio (CI) |
| Escalabilidad | Se descubre en producción | Se planifica: índices, caché, colas, límites |
| Mantenimiento | Cada cambio es una apuesta | Código legible, documentado y versionado |
| Velocidad inicial | Muy alta | Alta (la IA también acelera aquí) |
| Costo total | Bajo al inicio, alto después | Predecible |
La diferencia no es "usar IA o no usarla". En Key Lab usamos IA todos los días. La diferencia es quién es responsable del resultado y qué controles existen antes de que el código llegue a tus clientes.
Checklist: ¿tu web o app necesita una auditoría?
Si respondes "no sé" a dos o más de estas preguntas, probablemente sí:
- ¿Las claves de API y de base de datos están solo en el servidor, en variables de entorno?
- ¿Cada endpoint verifica quién hace la petición y qué puede hacer?
- ¿La base de datos tiene reglas de acceso y copias de seguridad probadas?
- ¿Las entradas de formularios y archivos se validan en el servidor?
- ¿Hay pruebas automatizadas que corren antes de cada despliegue?
- ¿Sabes qué pasa si mañana tienes 10 veces más usuarios?
- ¿Tienes registros, alertas y un plan si el sitio se cae?
- ¿Las dependencias están actualizadas y sin vulnerabilidades conocidas?
- ¿Otra persona (o equipo) podría mantener el código sin reescribirlo?
- ¿Cumples con la normativa de datos personales que te aplica?
Cómo trabajamos en Key Lab
Somos un estudio de ingeniería de software: construimos productos web, móviles, de IA y de tokenización para empresas que no pueden permitirse que su plataforma falle.
- Arquitectura primero: definimos datos, seguridad y escalabilidad antes de escribir la primera línea.
- IA como copiloto, no como piloto: la usamos para acelerar, y cada cambio pasa por revisión humana y pruebas.
- Seguridad por diseño: autenticación, autorización, manejo de secretos, validación y dependencias auditadas.
- Rendimiento medible: Core Web Vitals, pruebas de carga y monitoreo en producción.
- Rescate de proyectos: si ya tienes una app hecha con vibe coding, la auditamos, corregimos lo crítico y te decimos con honestidad si conviene refactorizar o reconstruir.
Preguntas frecuentes
¿El vibe coding es malo?
No para prototipos, pruebas de concepto o herramientas internas sin datos sensibles. Es un riesgo cuando se usa para productos en producción con usuarios, pagos o datos personales sin revisión profesional.
¿Se puede usar IA para programar de forma segura?
Sí. La IA es una gran aceleradora cuando la usa un equipo que entiende el código que genera, lo revisa, lo prueba y aplica prácticas de seguridad. Lo inseguro es publicar código que nadie entiende.
¿Cómo sé si mi web tiene fallas de seguridad?
Con una auditoría: revisión del código y de la configuración, análisis de dependencias, pruebas de autorización en los endpoints y revisión de la base de datos. Muchas fallas críticas no se ven desde la interfaz.
¿Vale más la pena arreglar o reconstruir una app hecha con vibe coding?
Depende de la arquitectura base. Si los datos y la autenticación están bien planteados, suele convenir corregir y refactorizar por partes. Si no, reconstruir lo crítico sale más barato a mediano plazo.
¿Tienes una web o app que "funciona, pero no sabes cómo"? Agenda una revisión con Key Lab y te decimos qué riesgos tiene y cómo llevarla a nivel producción. También puedes ver cómo aplicamos esta misma ingeniería en tokenización de activos y en proyectos de nuestro laboratorio.