¿Qué es exactamente el "vibe coding"?
El término lo acuñó en 2025 el investigador Andrej Karpathy, cofundador de OpenAI, para describir una forma de programar donde una persona describe en lenguaje natural lo que quiere construir —"necesito un formulario que guarde los datos en una base de datos y envíe un correo de confirmación"— y una IA genera el código completo, sin que el usuario escriba ni entienda cada línea. La persona "siente" el resultado (de ahí "vibe"), lo prueba, pide ajustes, y repite el ciclo hasta que la app hace lo que necesita.
Esto ha democratizado la creación de software de una forma que hace cinco años era impensable. Emprendedores sin formación técnica, equipos de marketing, gerentes de operaciones y estudiantes están lanzando aplicaciones, automatizaciones y sitios web funcionales en horas, no en meses. Herramientas como Cursor, Replit, Lovable, Bolt o v0 han hecho que "describir una app" sea casi tan simple como escribir un correo.
El problema no es la velocidad. El problema es qué queda oculto detrás de esa velocidad: seguridad, arquitectura, escalabilidad y mantenibilidad — todo lo que un desarrollador con experiencia revisa por reflejo, y que una IA generativa no garantiza solo porque el código "funcione" en la demo.
⚠️ Que una aplicación funcione en tu prueba local no significa que sea segura. Muchas de las vulnerabilidades más comunes no se notan hasta que alguien —normalmente con malas intenciones— las encuentra primero.
Lo que dicen los datos sobre seguridad del código generado por IA
Esto no es una opinión ni un miedo exagerado de "los programadores de antes". Es un problema medido, documentado y creciente:
El código generado por IA elige la opción insegura casi la mitad de las veces
El Reporte de Seguridad de Código GenAI 2025 de Veracode —uno de los estudios más rigurosos del sector— evaluó 80 tareas de programación reales frente a más de 100 modelos de lenguaje distintos (incluyendo los más usados del mercado). El resultado: cuando el modelo tenía que elegir entre una forma segura y una insegura de resolver la misma tarea, eligió la insegura en el 45% de los casos.
Dicho de otra forma: no es que la IA "a veces se equivoque". Es que, en promedio, casi la mitad del código que produce tiene un patrón de vulnerabilidad conocido, del tipo que cualquier escáner de seguridad automatizado detecta.
2.74 veces más vulnerabilidades que el código escrito por una persona
El mismo estudio de Veracode encontró que el código generado por IA contiene 2.74 veces más vulnerabilidades que el código equivalente escrito por un desarrollador humano con criterio de seguridad. Para contextualizar: el código escrito por personas ya tiene una tasa de vulnerabilidad de referencia de entre 25% y 30% en pruebas similares — la IA no solo no mejora ese número, lo multiplica.
El lenguaje más riesgoso del estudio fue Java, con una tasa de fallas de seguridad del 72%. Ningún lenguaje de los evaluados (Java, JavaScript, Python, C#) quedó libre de este patrón.
El código generado también tiene más errores críticos, no solo de seguridad
Un análisis independiente de CodeRabbit sobre cientos de pull requests de código abierto encontró que el código generado por IA contiene 1.7 veces más errores críticos (no solo vulnerabilidades de seguridad, sino fallas lógicas y de funcionamiento) que el código escrito por una persona. Esto confirma que el problema no es exclusivamente de seguridad — también es de calidad general del software.
💡 Ninguno de estos estudios dice que la IA sea mala programando. Dicen que produce código funcional pero sin las garantías de seguridad que antes daba por sentado el criterio de un desarrollador. Es una herramienta extraordinaria de velocidad, no un sustituto de revisión técnica.
¿Por qué pasa esto? Las 5 razones técnicas
1. La IA optimiza para "que funcione", no para "que sea seguro"
Los modelos de lenguaje se entrenan y se evalúan principalmente en si el código cumple la función pedida. La seguridad es un criterio secundario, invisible en la mayoría de las pruebas que hace un usuario no técnico: si el formulario guarda el dato y envía el correo, "funciona" — aunque las credenciales de la base de datos estén expuestas en el código del frontend, algo que ocurre con más frecuencia de la que parece.
2. Los modelos "alucinan" dependencias que no existen
Un análisis de 2.23 millones de muestras de código generadas por 16 modelos distintos encontró que cerca del 20% incluían el nombre de al menos un paquete o librería que no existe. Esto no es solo un error inofensivo: atacantes han empezado a registrar paquetes con esos nombres alucinados exactos, sabiendo que tarde o temprano alguien los va a instalar sin verificar.
3. No hay revisión de arquitectura, solo de resultado inmediato
Cuando una persona sin experiencia técnica pide ajustes iterativos ("ahora agrégale login", "ahora que se pueda subir una foto"), la IA resuelve cada pedido de forma aislada. No hay nadie preguntando si esa nueva función rompe un supuesto de seguridad que ya existía, o si la base de datos está diseñada para escalar más allá de las primeras decenas de usuarios.
4. Falta lo que no se ve en la demo
Una aplicación puede verse y comportarse perfectamente en una demo de 5 minutos y no estar ni cerca de lista para producción real. Autenticación robusta, manejo de roles y permisos, respaldo de datos, monitoreo de errores, políticas de acceso, cumplimiento con regulaciones de datos — nada de esto es visible probando la app manualmente, y nada de esto lo genera una IA por defecto si nadie lo pide explícitamente y sabe cómo verificarlo.
5. El usuario no sabe qué preguntar
Esta es, en la práctica, la causa raíz de todas las anteriores. Un desarrollador experimentado sabe qué preguntas hacer: ¿cómo se manejan las sesiones?, ¿está la base de datos expuesta públicamente?, ¿qué pasa si dos personas escriben al mismo tiempo? Alguien sin ese criterio no sabe que esas preguntas existen, así que nunca las hace — ni a la IA, ni a nadie.
Por qué la mayoría de estos proyectos nunca llegan a producción
Más allá de la seguridad, hay un problema de fondo igual de común: estimaciones del sector ubican en un rango amplio —hasta 60% en algunos análisis— la proporción de proyectos creados con IA generativa que se abandonan antes de llegar a un entorno de producción real, es decir, antes de que clientes o empleados reales lo usen de forma estable.
Las razones se repiten con tanta frecuencia que ya son un patrón reconocible:
- Base de datos de prueba, no de producción: muchas apps generadas usan una base de datos temporal o de desarrollo que no está pensada para datos reales, backups ni concurrencia.
- Sin autenticación real: un login "que funciona" en la demo puede no tener protección contra ataques básicos de fuerza bruta, ni recuperación de contraseña segura, ni verificación de identidad.
- Sin plan de hosting serio: la app corre bien en el entorno de desarrollo de la herramienta de IA, pero mover eso a un hosting confiable, con dominio propio, certificados y monitoreo, es un paso técnico que casi nunca está incluido.
- Deuda técnica invisible: cada iteración rápida ("agrégale esto", "cámbiale esto otro") suma complejidad sin documentación ni estructura, hasta un punto en que ni la misma IA puede seguir modificando el proyecto sin romper algo.
Un ejemplo típico de lo que aparece en una revisión
Para que esto no se quede en estadísticas abstractas, así es como suele verse en la práctica. Una pyme construye con IA un portal donde sus clientes pueden agendar citas y ver el estado de sus pedidos. Funciona perfecto en las pruebas: se agenda, se guarda, se ve el estado. El fundador queda satisfecho y empieza a compartir el enlace con clientes reales.
Una revisión técnica básica de ese mismo portal, en casos similares, suele encontrar varias de estas fallas al mismo tiempo: la base de datos accesible directamente desde internet sin contraseña propia (porque la plataforma de IA la deja así por defecto para facilitar las pruebas), las claves de acceso a servicios externos —como el envío de correos o el procesador de pagos— escritas en texto plano dentro del código que cualquiera puede ver desde el navegador, ningún límite a cuántas veces alguien puede intentar iniciar sesión con contraseñas distintas, y cero copias de seguridad de la información de los clientes.
Ninguno de estos problemas es visible usando la aplicación normalmente. Se descubren revisando el código y la configuración con las preguntas correctas — exactamente el paso que se salta cuando nadie con criterio técnico participó en el proceso. Y son, casi siempre, corregibles en días, no en meses, una vez alguien los identifica.
Qué hacer si ya construiste algo con IA (o estás por hacerlo)
Ninguno de estos riesgos significa que debas abandonar el vibe coding. Significa que hay un punto en el proceso donde se necesita criterio técnico humano, y ese punto suele ser antes de lo que la mayoría piensa.
1. Haz una auditoría de seguridad antes de lanzar
Antes de que la aplicación reciba datos reales de clientes o empleados, alguien con criterio de seguridad debe revisar el código en busca de credenciales expuestas, dependencias inexistentes o mal verificadas, y las vulnerabilidades más comunes (inyección SQL, XSS, control de acceso roto).
2. Verifica dónde y cómo se guardan los datos
¿La base de datos está protegida con autenticación propia, o es de acceso público por defecto (una configuración común y peligrosa en varias plataformas de desarrollo rápido)? ¿Hay algún tipo de respaldo automático?
3. Define quién es responsable del mantenimiento
Una app generada con IA no se mantiene sola. Cuando aparezca un error en producción, alguien tiene que poder diagnosticarlo y corregirlo — y eso requiere entender la estructura del código, no solo haber descrito la idea original.
4. Separa "prototipo" de "producto"
Usa el vibe coding para lo que es extraordinario: validar una idea rápido, mostrarle algo tangible a un inversionista o cliente, probar un flujo antes de invertir en desarrollo completo. Pero trata ese resultado como un prototipo, no como el producto final, hasta que pase por una revisión técnica formal.
🔧 En iProject3 tomamos aplicaciones y automatizaciones creadas con IA —de cualquier herramienta— y hacemos la parte técnica que falta: auditoría de seguridad, arquitectura de datos, autenticación real y todo lo necesario para llevarlas a un entorno de producción confiable. No te decimos que empieces de cero; revisamos qué sirve y qué hay que corregir.
La IA no es el problema. La falta de criterio técnico, sí.
El vibe coding es una de las herramientas más poderosas que ha tenido cualquier persona sin formación técnica para convertir una idea en algo tangible. Eso no cambia. Lo que sí debe cambiar es la expectativa: "funciona en mi prueba" y "está listo para producción" son dos etapas distintas, y entre una y otra sigue haciendo falta el mismo criterio técnico que hacía falta antes de que existiera la IA generativa — solo que ahora aparece más tarde en el proceso, cuando ya hay algo construido y funcionando a medias.
Preguntas frecuentes sobre seguridad en aplicaciones creadas con IA
¿Debo dejar de usar IA para crear aplicaciones o prototipos?
No. Es una herramienta excelente para prototipar rápido y validar ideas. El punto no es evitarla, sino no tratar el resultado como listo para producción sin una revisión técnica de seguridad y arquitectura antes de que maneje datos reales.
¿Cómo sé si mi aplicación hecha con IA tiene vulnerabilidades?
La forma confiable es una auditoría de seguridad: revisión del código en busca de credenciales expuestas, dependencias inexistentes, configuración de la base de datos y los patrones de vulnerabilidad más comunes (OWASP Top 10). Probar la app manualmente no revela estos problemas, porque suelen estar bajo la superficie que un usuario normal ve.
¿Qué es una "dependencia alucinada" y por qué es peligrosa?
Es cuando la IA genera código que intenta instalar una librería o paquete que en realidad no existe, inventado durante la generación. Es peligroso porque atacantes han comenzado a registrar paquetes reales con esos nombres exactos, esperando que alguien los instale sin verificar — un ataque conocido como "slopsquatting".
¿Cuánto cuesta llevar una app hecha con IA a producción de forma segura?
Depende del alcance, pero en general es significativamente menos costoso que reconstruir desde cero, porque buena parte de la lógica y la interfaz ya están hechas. El trabajo suele concentrarse en seguridad, base de datos, autenticación y hosting — no en rehacer la aplicación completa.
¿Las plataformas de vibe coding (Cursor, Replit, Lovable, etc.) no revisan esto automáticamente?
Algunas ofrecen escaneos básicos o sugerencias de seguridad, pero ninguna sustituye una revisión técnica completa contra el contexto específico de tu negocio: qué datos maneja tu app, qué regulaciones te aplican y qué nivel de tráfico esperas. Son herramientas de generación, no de auditoría.
Fuentes y referencias
- 2025 GenAI Code Security Report (Veracode, 2025)
- Insights from the 2025 GenAI Code Security Report (Veracode, 2025)
- OWASP Top 10 (OWASP Foundation)
