Dejar que una IA escriba el código ya no es la pregunta interesante. Lo hace casi todo el mundo, y a estas alturas discutir si conviene o no es como discutir si conviene usar un IDE. La pregunta que sí importa, y que casi nadie responde con números, es otra: qué cuesta asegurar ese código después.
Este artículo reúne lo que dicen los estudios publicados hasta hoy sobre la seguridad del código generado por IA, con las cifras y sus fuentes. No es una opinión sobre si el vibe coding está bien o mal: es el precio, medido, de trabajar así, y qué hacer para que salga a cuenta.
De la palabra del año al primer susto
El término lo acuñó Andrej Karpathy en febrero de 2025 para describir un modo de trabajo en el que uno «se entrega a las vibraciones y olvida que el código existe». En noviembre de 2025 el diccionario Collins lo eligió palabra del año. Por el camino, Y Combinator informó de que el 25% de las empresas de su hornada de invierno de 2025 tenían bases de código generadas por IA en un 95%.
Conviene una distinción que hace Simon Willison, creador de Datasette, y que se pierde en casi todas las conversaciones: si revisas y entiendes todo el código, eso no es vibe coding, es usar un modelo como asistente de escritura. El vibe coding implica aceptar cierto grado de caja negra. Esa aceptación es exactamente lo que tiene un precio, y es lo que vamos a cuantificar.
Lo que cuesta en seguridad
Hay tres tipos de evidencia, y conviene no mezclarlos: qué pasa cuando se compara código con IA frente a código sin ella, qué falla exactamente dentro de ese código, y qué se encuentra al escanear aplicaciones que ya están en producción.
Más problemas, y concentrados en seguridad
CodeRabbit comparó en diciembre de 2025 unas 320 pull requests escritas con ayuda de IA contra 150 escritas sin ella, todas en repositorios abiertos. El resultado no es que la IA genere más fallos en general, que también, sino dónde los concentra.
Fíjate en la distancia entre la última barra y la primera. Los problemas totales se multiplican por 1,7, que ya es mucho, pero los de seguridad se multiplican por 2,74. Es decir: el código generado no es uniformemente peor, es desproporcionadamente peor en lo que menos se nota al probar que funciona.
Eso encaja con la intuición de cualquiera que haya revisado código ajeno: un fallo funcional se manifiesta al ejecutar; una referencia directa insegura o un manejo indebido de contraseñas pasan todas las pruebas de humo y solo aparecen cuando alguien las busca.
Dónde falla exactamente
Veracode evaluó más de un centenar de modelos con tareas de programación sensibles a seguridad. Su conclusión de fondo es incómoda: los modelos han mejorado mucho en escribir código que funciona, y no han mejorado en escribir código seguro. Son dos ejes distintos y solo uno avanza.
El 45% de las muestras introduce algún fallo del OWASP Top 10. Y al bajar al detalle aparece un patrón: falla peor en las defensas que hay que recordar poner, como escapar la salida o sanear lo que se escribe en los registros, y mejor en las que el lenguaje o el framework ya traen resueltas.
Y esto es lo que hay en producción
Los dos estudios anteriores son de laboratorio. Escape.tech hizo lo otro: escanear aplicaciones reales, creadas con herramientas de vibe coding y publicadas.
Los 175 casos de datos personales incluían historiales médicos y números de cuenta bancaria. Y los más de 400 secretos expuestos son claves de API y tokens de acceso, es decir, credenciales que siguen valiendo aunque arregles la aplicación.
Un apunte sobre esta cifra, porque me costó verificarla: varios medios repiten que fueron 5.600 aplicaciones. La fuente original dice 1.400. Cuando un dato circula multiplicado por cuatro, conviene ir siempre al informe y no al titular.
El espejismo de la productividad
Aquí es donde casi todos los artículos sobre este tema, incluido el mío anterior, se quedaron con una foto vieja.
En julio de 2025, METR publicó un ensayo controlado aleatorizado con desarrolladores experimentados trabajando en sus propios repositorios. El resultado fue contraintuitivo y dio la vuelta al mundo: eran un 19% más lentos con herramientas de IA, mientras ellos estimaban ser un 20% más rápidos.
Ese estudio hoy lleva un aviso del propio METR en su cabecera: «estos resultados están desactualizados». En febrero de 2026 publicaron datos nuevos, y la cifra se dio la vuelta.
Lo interesante no es que ahora salga positivo. Es lo que el propio METR reconoce sobre el nuevo experimento: muchos desarrolladores se negaron a participar porque no querían trabajar sin IA, lo que sesga el resultado. Ese detalle dice más sobre 2026 que cualquier porcentaje.
Lo que sí resiste el paso del tiempo del estudio original es la otra mitad, la que nadie cita: la brecha entre lo que la gente cree que tarda y lo que tarda de verdad. Creerse un 20% más rápido cuando vas un 19% más lento es un error de percepción de casi cuarenta puntos. Esa brecha es la que hace que nadie mida, y que los problemas se descubran tarde.
Por qué falla: no es que el modelo sea torpe
Merece la pena entender el mecanismo, porque de ahí salen los remedios que funcionan.
- Optimiza para que funcione, no para que resista. El modelo se entrena y se evalúa mayoritariamente contra «¿hace lo que le pedí?». Una función que devuelve el dato correcto y de paso permite inyección SQL supera esa prueba.
- Aprendió de código real, con sus vicios. Buena parte del código público tiene validación floja y secretos incrustados. El modelo reproduce la media de lo que vio, y la media no es segura.
- No ve tu modelo de amenazas. Sabe escribir un formulario de acceso; no sabe que ese formulario da a una red donde ya hay confianza implícita. El contexto de seguridad no está en el prompt salvo que lo pongas tú.
- Y tú revisas menos de lo que crees. Revisar código propio ya es difícil; revisar cien líneas que aparecen de golpe, funcionan a la primera y parecen razonables, lo es mucho más. La fatiga de revisión es real y el volumen la agrava.
Incidentes que ya han pasado
- Julio de 2025. El agente de Replit borró una base de datos de producción pese a tener instrucciones explícitas de no hacer cambios.
- Septiembre de 2025. Fast Company describió la «resaca del vibe coding»: equipos atrapados manteniendo código que nadie entiende.
- Febrero de 2026. Un periodista de la BBC fue comprometido a través de una vulnerabilidad en una aplicación creada con estas herramientas.
El patrón de los tres es el mismo, y no es el que se suele contar: el fallo no fue del modelo, fue del permiso. Un agente con acceso de escritura a producción, una aplicación publicada sin revisión, un despliegue sin control de acceso. La IA solo aceleró la llegada al borde del precipicio que ya estaba ahí.
De las vibraciones a la especificación
Durante 2026 la industria ha respondido a todo esto con un cambio de enfoque que tiene nombre propio: desarrollo dirigido por especificación. La idea es simple y bastante antigua, en realidad: en lugar de lanzar un prompt suelto y ver qué sale, se escribe primero la especificación, y esa especificación pasa a ser la fuente de verdad de la que se deriva el código, las pruebas y la documentación.
Lo importante para quien lea esto: no es una herramienta nueva que haya que comprar. Es trasladar el esfuerzo del después al antes. En lugar de revisar mil líneas generadas, defines las restricciones antes de que se generen, y luego compruebas que se cumplen. Revisar es caro y se hace mal; comprobar contra un criterio escrito es barato y se puede automatizar.
El método que uso, y que va a continuación, es una versión artesanal de esto mismo. Le puse nombre después de llevar tiempo haciéndolo.
Guardrails que sí funcionan
- Define el alcance antes del primer prompt. Qué entra y qué no. Sin alcance escrito, el modelo genera funcionalidad que nadie pidió y que también hay que revisar.
- Escribe los criterios de éxito como ejemplos. Entrada concreta, salida esperada. Un criterio que no puedes comprobar no es un criterio, es un deseo.
- Cicla en tramos cortos. Diez o veinte minutos. El tamaño del cambio que revisas determina la calidad con la que lo revisas.
- Git desde el primer prompt. Cada iteración, un commit. Es lo que te permite responder a «¿cuándo entró esto?» sin adivinar.
- Pruebas mínimas, pero pruebas. Si generó una API, llámala con curl. Si generó un formulario, mándale basura. Un smoke test por flujo crítico.
- Revisión de seguridad explícita, y con lista. No «revisar por encima»: la lista concreta que viene abajo. Lo que no está en una lista no se revisa.
- Y el permiso mínimo, siempre. Es la lección de los tres incidentes: un agente sin acceso a producción no puede borrar producción, por mal que se porte.
Prompt base
Este es el punto de partida que uso. No tiene magia: lo que hace es meter en el contexto las restricciones que el modelo no va a suponer por su cuenta.
Actúa como un ingeniero senior.
Objetivo: [la funcionalidad en una o dos líneas]
Stack: [Next.js / Node / Python / Bash...]
Restricciones:
- Ningún secreto en el código; variables de entorno siempre
- Validar y sanear TODA entrada: parámetros, formularios, JSON, cabeceras
- Escapar toda salida que llegue a HTML o a un registro
- Errores con mensaje claro y sin filtrar datos internos
- Permiso mínimo: si algo no necesita root, no lo tiene
- Al menos una prueba por flujo crítico
Entregables:
1) Los cambios de código
2) Lista de ficheros creados y modificados
3) Pasos para ejecutarlo en local
4) Qué decisiones de seguridad has tomado y por quéLa cuarta entrega es la que más rinde. Pedirle que explique sus decisiones de seguridad saca a la luz los supuestos que ha hecho, y ahí es donde suelen estar los agujeros.
Lista de revisión
Después de generar, antes de integrar. Ordenada por lo que más veces aparece en los estudios de arriba:
- Secretos. Ni claves ni tokens ni contraseñas en el repositorio. Es lo primero porque los commits asistidos por IA los filtran al doble de ritmo que los humanos.
- Salida escapada. Todo lo que acabe en HTML o en un registro. Es donde más falla, con diferencia.
- Entradas validadas. Parámetros, formularios, JSON, cabeceras. Todo lo que venga de fuera.
- Permisos. Mínimo privilegio, y especialmente en lo que ejecute el agente sin supervisión.
- Dependencias. Versiones fijadas y revisadas contra CVE conocidos. Los modelos sugieren con frecuencia versiones antiguas.
- Errores. Mensaje útil para quien lo usa, traza útil para ti, y nada de rutas internas ni volcados en la respuesta.
- Pruebas. Al menos el flujo crítico. Si no hay ninguna, no has terminado.
Conclusión
Los datos no dicen que haya que dejar de usar IA para programar, y yo tampoco lo digo. Dicen algo más concreto y más útil: que el ahorro y el coste caen en sitios distintos. Se ahorra en escribir, se paga en revisar y en asegurar. Si solo mides lo primero, te parecerá gratis.
La parte que envejece bien de todo esto no son los porcentajes, que ya hemos visto que se dan la vuelta en doce meses. Es el mecanismo: el modelo optimiza para que funcione, y la seguridad no se manifiesta al ejecutar. Mientras eso siga siendo verdad, la revisión de seguridad no es una fase opcional del proceso, es el proceso.
Y si no estás dispuesto a revisar lo que genera, no es vibe coding. Es publicar código de un desconocido con tu nombre encima.
Fuentes
- METR, estudio de julio de 2025 y revisión de febrero de 2026.
- Escape.tech, estado de la seguridad de las aplicaciones creadas con vibe coding.
- CodeRabbit, comparativa de pull requests con y sin IA, diciembre de 2025.
- Veracode, evaluación de más de cien modelos en tareas sensibles a seguridad.
- Collins Dictionary, palabra del año 2025.