El perfil de fallos se ha desplazado
Una empresa de seguridad de aplicaciones revisó durante medio año los datos de decenas de miles de repos y varios miles de desarrolladores. Lo que encontró cabe en una frase: la IA arregla las erratas y, de paso, fabrica bombas de relojería.
| Tipo de fallo | Cambio en desarrolladores asistidos por IA |
|---|---|
| Error de sintaxis | −76 % |
| Error de lógica | −60 % |
| Vía de escalada de privilegios | +322 % |
| Fallo de diseño arquitectónico | +153 % |
| Secreto que acaba en el código | casi el doble de frecuente |
De la misma fuente: los desarrolladores asistidos por IA produjeron entre tres y cuatro veces más código y diez veces más hallazgos de seguridad.
(Análisis de una empresa de seguridad de aplicaciones; no explican cómo identificaron el código «asistido por IA». El desplazamiento del perfil de fallos, en cambio, lo confirman todas las demás fuentes.)
La consecuencia práctica: no busques el fallo donde lo buscas en código humano. La errata ha desaparecido. Lo que queda no se ve línea a línea.
La cifra que no se mueve
La medición con la muestra más grande siguió durante mucho tiempo a más de 150 modelos, sobre 80 tareas de programación, en cuatro lenguajes y cuatro tipos de vulnerabilidad.
El resultado: solo el 55 % de las tareas de generación da código seguro. O sea, sin una instrucción de seguridad explícita, uno de cada dos o tres casos mete en el código una vulnerabilidad conocida.
Y el gráfico clave: la tasa de compilación ha pasado de un 50 % a un 95 % desde 2023, mientras que la tasa de seguridad se ha mantenido esencialmente plana, entre el 45 % y el 55 %. El código compila cada vez mejor y es igual de vulnerable.
El 55 % es la cifra agregada; el desglose por lenguaje y el desglose por tipo de vulnerabilidad no corren sobre el mismo conjunto, así que ninguna de las dos medias lo reproduce. Lo que sí te dice el desglose es dónde mirar:
| Lenguaje | Tasa segura | Tipo de vulnerabilidad | Tasa segura | |
|---|---|---|---|---|
| Python | 62 % | SQL injection | 82 % | |
| C# | 58 % | Cripto débil | 86 % | |
| JavaScript | 57 % | XSS | 15 % | |
| Java | 29 % | Log injection | 13 % |
Este es el consejo más aprovechable de todo el artículo: los modelos han aprendido la consulta parametrizada, el output encoding no. Si el código lo escribió una IA, mira primero el output encoding y el registro, no el SQL. Y el código Java se merece atención aparte.
Una cosa que no ayuda: un modelo más grande. Según la medición, el tamaño del modelo tiene un efecto muy pequeño en el rendimiento de seguridad; los modelos de razonamiento andan por el 70–72 %: mejor, pero no una solución.
El import alucinado
Este es el patrón de fallo mejor medido y más fácil de comprobar de todos.
Un estudio publicado en una conferencia de seguridad de 2025 situó la proporción de nombres de paquete inexistentes en el 5,2 % en modelos comerciales y en el 21,7 % en modelos de pesos abiertos. Una réplica de 2026 sobre cinco modelos recientes, con 199.845 prompts pareados, lo afinó entre el 4,62 % y el 6,10 %.
La dispersión entre modelos se ha reducido, pues, en un orden de magnitud. El problema no. Uno de cada veinte imports todavía puede apuntar a un paquete que no existe.
Y esto es lo que lo convierte en superficie de ataque: la réplica encontró 127 nombres de paquete que los cinco modelos alucinaron igual, y 53 de ellos siguen hoy libres para registrar. En cuanto alguien registra uno, deja de ser un fallo y pasa a ser un ataque.
La comprobación son dos segundos: mira el nombre de cada import nuevo en el registro de paquetes antes de instalarlo.
La paradoja de la confianza
Hay un experimento de 2023 que conviene citar junto con sus propias limitaciones: 47 participantes, cinco tareas, el modelo de entonces y en su mayoría estudiantes universitarios.
El resultado tiene dos partes. Una: quienes trabajaron con ayuda de IA escribieron código significativamente menos seguro: 21 % frente a 43 % en la tarea de cifrado, 3 % frente a 21 % en la de firma, 12 % frente a 29 % en el acceso a archivos con sandbox.
Dos: esas mismas personas creyeron con más probabilidad que habían escrito código seguro.
Muestra pequeña, modelo antiguo, pero el segundo resultado reaparece desde entonces en otras mediciones. Y hay un hallazgo secundario que se traduce directamente en acción: quienes confiaron menos en la IA y dedicaron más esfuerzo a formular su propia petición dejaron menos vulnerabilidades en el código.
La contraprueba que hay que contar
Si solo escribiéramos lo anterior, el cuadro quedaría cojo.
Una observación de largo plazo de 2026 siguió 508 archivos generados por agent y 508 generados por humanos en 100 repos, durante al menos seis meses y más de tres mil commits. Su resultado contradice la narrativa habitual: los archivos generados por IA recibieron la mitad de commits en el primer mes y necesitaron bastantes menos cambios correctivos que los humanos.
Los tipos de mantenimiento apuntan a lo mismo: en los archivos de IA lo más frecuente es añadir funcionalidad (21,8 %); en los humanos, corregir errores (16,8 %).
Pero los propios autores ponen encima de la mesa la explicación alternativa: menos mantenimiento también puede significar que el archivo lo usa poca gente o cuesta entenderlo. Un archivo que nadie toca nunca hay que arreglarlo.
Una cifra del mismo sitio que dice mucho: el 83 % del mantenimiento de los archivos generados por IA lo hacen personas. En sus propios archivos, los agents aportan apenas la sexta parte de los commits.
Los tests que supuestamente siempre están en verde
Este es el miedo más extendido, y la evidencia no lo respalda.
Un estudio de 2026 revisó 2.232 commits que tocaban tests en diez proyectos TypeScript. Los tests escritos por IA contenían más assertions (2,00 frente a 1,00 de media), su ganancia de cobertura fue «comparable o mayor» que la de los desarrolladores humanos y no eran más complejos, solo más largos.
No hemos encontrado ninguna medición de muestra grande sobre tests de IA vacíos, sin assertions, solo posts de blog. El miedo está extendido, la evidencia falta.
El riesgo real está en otro sitio y es más sutil: el test generado tiende a comprobar lo que el código hace, no lo que debería hacer. Eso sigue en verde aunque el comportamiento sea incorrecto. Por eso hay que empezar por un test que falla, no por el arreglo.
El coste real: la revisión
Aquí está la cifra más grande del artículo. Un análisis sobre dos años de datos de 22.000 desarrolladores y 4.000 equipos dice lo siguiente del código con IA:
| Indicador | Cambio |
|---|---|
| Tamaño del PR | +51,3 % |
| Archivos por PR | +59,7 % |
| Fallos por PR | +54 % |
| Tiempo mediano hasta la primera revisión | +156,6 % |
| Tiempo mediano dedicado a revisar | +441,5 % |
| PR fusionados sin revisión | +31,3 % |
El tiempo mediano de revisión se ha multiplicado por más de cinco. No porque el código sea peor, sino porque es más grande, y porque quien revisa no sabe qué pretendía quien escribió.
Y un dato que habla de tu propia percepción: una telemetría de editor que siguió a 800 desarrolladores durante dos años indica que quienes usan IA hacen al mes unas cien eliminaciones y reversiones más que quienes no la usan — y en estos la cifra ronda las siete al mes. Mientras tanto, la mitad de esos usuarios dice que su flujo de trabajo no ha cambiado.
¿Hasta qué punto es real esa carga? Un proyecto de código abierto conocido y usado por todo el mundo cerró su programa de recompensas por fallos a finales de enero de 2026, desbordado por informes generados y falsos: en una sola semana llegaron siete informes en dieciséis horas y ninguno encontró una vulnerabilidad real. La razón que dio el mantenedor: «queremos quitar el incentivo de mandar basura.»
La lista de comprobación
1. ¿EXISTE CADA IMPORT NUEVO? -> míralo en el registro.
Tasa de alucinación del 4,6-6,1 %, y 53 nombres libres.
2. OUTPUT ENCODING Y REGISTRO. Son los puntos más débiles
(15 % y 13 % de tasa segura). El SQL el modelo lo sabe.
3. PERMISOS: ¿el código recibe más de lo que necesita?
Vía de escalada de privilegios: +322 %.
4. ¿SECRETOS en el código, la config, los datos de test?
Casi el doble de frecuente con desarrollador asistido.
5. EL CÓDIGO JAVA LLEVA RONDA APARTE. 29 % de tasa segura.
6. ¿EL TEST COMPRUEBA LO QUE DEBE - y no lo que el código
hace por casualidad? Empieza por un test que falla.
7. PR DE MENOS DE 500 LÍNEAS. El umbral habitual. Por encima
la calidad de la revisión se desploma.
8. ¿HAY REVISOR INDEPENDIENTE? Más de tres cuartas partes de
los PR de agent fusionados los fusiona quien los envía.
9. NO REVISA QUIEN LO GENERÓ. Hace falta contexto fresco -
el modelo tiene sesgo hacia el código que acaba de escribir.
Los puntos ocho y nueve son los más importantes, y son justo los dos que más se omiten. El archivo de instrucciones tampoco te lo resuelve: de eso habla con números el post los límites de las instrucciones de proyecto , con la medición.
Malentendidos habituales
- «El código generado ya es bueno, mira, compila.» La compilación pasó del 50 % al 95 %, la tasa de seguridad se quedó entre el 45 % y el 55 %. No son el mismo indicador.
- «Modelo más grande, código más seguro.» El tamaño del modelo tiene un efecto muy pequeño en esto.
- «La IA siempre escribe tests vacíos.» Los tests de IA medidos trabajan con más assertions y cubren al menos lo mismo. El riesgo está en otra parte.
- «El código de IA hay que arreglarlo más.» Una observación de largo plazo dice que menos, aunque quizá solo porque poca gente lo toca.
- «El desarrollo se ha acelerado.» El tiempo mediano de revisión creció un 441 %. El tiempo no desapareció, se trasladó a quien revisa.
Lo que conviene llevarse
Los fallos del código generado no están donde están los del código humano. La errata desapareció y en su lugar llegaron permisos, arquitectura y secretos. La revisión hay que ajustarla a eso: imports, output encoding, registro, permisos y secretos, en ese orden, y el código Java lleva ronda aparte, porque ahí la tasa segura es del 29 %. Las dos reglas de organización que más valen: PR de menos de quinientas líneas — no es una medición, sino el umbral habitual de la comunidad — y revisor independiente, porque los PR fusionados sin revisión han subido un 31,3 %.
Las cifras detalladas del lado de la seguridad las trae el post la factura de seguridad del código de IA , con el cálculo; repartir esa primera tarea al agent lo recorre el post la primera tarea con un coding agent , paso a paso; y cuánto de todo esto conviene dejar en manos de una máquina lo discute el post la IA en el code review , con ejemplos.