«La IA escribe código más rápido» no está en discusión. Si escribe código peor es una cuestión aparte, empírica — y preferimos responderla con mediciones antes que con los argumentarios de cualquiera de los bandos. Tres estudios independientes, con tres métodos distintos, convergen en la misma respuesta.
El punto de partida: una tasa de defectos documentada
Tratamos el estudio fundacional en detalle en A Clean Benchmark Is Not a Clean Codebase (en inglés): Pearce et al. (IEEE S&P 2022) encontraron alrededor del 40 % de 1 689 programas generados por Copilot vulnerables a las clases de debilidades del Top 25 de MITRE. El estudio ya es lo bastante antiguo como para que su cifra no deba leerse como actual — los modelos han cambiado desde 2022. Lo que estableció, y sobre lo que se apoya el trabajo posterior: la cuestión es real y puede responderse con métodos estándar — escenarios dirigidos, una muestra grande, análisis estático contra una lista de debilidades con nombre.
El mecanismo: no son fallos aleatorios, es una ausencia sistemática
Una cifra sola no dice qué hacer. Una comparación controlada de código escrito por humanos y código generado por LLM — estructuras de datos, algoritmos, rutinas criptográficas y problemas tipo LeetCode, con tests unitarios, fuzzing y análisis estático (arXiv:2409.19182) — fue más lejos y encontró esto: el código generado por LLM es menos seguro ante todo porque le faltan las construcciones de programación defensiva — las comprobaciones de límites y la validación de entradas que un ingeniero cuidadoso añade por hábito, no la funcionalidad que realmente se pidió. Esa ausencia es la que invita a los desbordamientos de búfer y de entero. Bajo fuzzing, el código generado por LLM era más propenso a cuelgues y caídas que la base de comparación escrita por humanos. Los fallos de corrección podían ser sutiles en lugar de evidentes: en un caso, el modelo produjo una implementación incorrecta de SHA-1 que aun así compilaba limpiamente — errónea, y silenciosa al respecto.
El hallazgo que debería inquietar a cualquiera que tome «pídele al modelo que lo arregle» por una red de seguridad: el mismo estudio construyó un bucle de retroalimentación pidiendo al modelo regenerar el código y eliminar los problemas que se le acababan de mostrar. No funcionó de forma fiable. En algunos casos la corrección tuvo éxito. En otros, el código «corregido» contenía problemas nuevos — y en algunos casos el propio acto de promptear introdujo problemas en ficheros que estaban limpios antes. Dejar que el autor califique sus propios deberes no es una revisión.
La evidencia en producción: el coste no pasa con la novedad
La evidencia más reciente viene de fuera del laboratorio por completo. Un estudio siguió 807 repositorios open source en GitHub que adoptaron el asistente de codificación Cursor entre enero de 2024 y marzo de 2025, contra un grupo de control de 1 380 repositorios comparables sin él — con SonarQube como instrumento de medición de avisos de análisis estático, duplicación y complejidad, hasta agosto de 2025. La historia de productividad se desarrolló como se esperaba: un pico efímero de commits y líneas añadidas en el primer o segundo mes, de vuelta a la línea base en el tercero. El coste de calidad no pasó con él. Los avisos de análisis estático subieron en torno a un 30 % tras la adopción y se mantuvieron elevados. La complejidad del código subió más de un 40 % — más de lo que explicaría por sí solo el crecimiento de la base de código. La ganancia de velocidad fue temporal. La deuda, no.
Un límite honesto
Esto no es la afirmación de que el código generado por IA sea siempre peor, como ley general. La tarea, el modelo y la forma de trabajar cuentan — y un equipo que trata la salida de la IA como un primer borrador que merece la misma disciplina de revisión que la pull request de un ingeniero junior ve resultados distintos de los de un equipo que la entrega sin revisar. Los estudios de arriba no prueban todos los modelos ni todas las formas de trabajar, y ninguno aísla la disciplina de revisión como variable. Lo que establecen de forma consistente, a través de tres métodos independientes (tests CWE dirigidos, comparación controlada, datos longitudinales de producción): el efecto es real y sistemático en lugar de ocasional — y pedirle al modelo que compruebe su propio trabajo no sustituye a que lo haga otra persona.
Por qué esto es una cuestión de cumplimiento, no solo de ingeniería
En virtud del Cyber Resilience Act, un fabricante debe velar por que los productos con elementos digitales «se diseñarán, desarrollarán y producirán de manera que garanticen un nivel adecuado de ciberseguridad sobre la base de los riesgos existentes» y «se comercializarán sin vulnerabilidades aprovechables conocidas» (Reglamento (UE) 2024/2847, anexo I, parte I, puntos
- y 2) a)). Ninguna de las dos cláusulas menciona cómo se escribió el código. Ambas se vuelven más difíciles, no más fáciles, de satisfacer cuanta más superficie de una base de código haya sido producida por un proceso con un déficit medido y sistemático precisamente en las construcciones — comprobaciones de límites, validación de entradas — que impiden que una clase conocida de debilidades se vuelva aprovechable. Generar más rápido sin revisar más no es un atajo alrededor de esa obligación. Es una distancia que crece respecto a ella.
Por qué nos importa
En CounterProof practicamos la revisión adversarial de código escrito por máquinas, y estos tres estudios describen exactamente la brecha que nuestra práctica existe para cerrar: tratar la salida de la IA — la que genera y la que revisa — como una afirmación que hay que comprobar, no como un resultado en el que confiar. Véase la pieza compañera A Clean Benchmark Is Not a Clean Codebase (en inglés) sobre lo que ocurre cuando la herramienta de comprobación también se basa en IA y su propia fiabilidad queda sin examinar. El argumento largo, incluida la forma condicional de cada afirmación de arriba, está en nuestro documento de trabajo sobre colación y procedencia del texto generado por máquinas, legible íntegramente aquí (en inglés). Es un preprint en estado de borrador, sin revisión por pares, y así lo dice.
Las fuentes citadas arriba se verificaron contra sus resúmenes publicados. La cifra de Pearce et al. procede de IEEE S&P 2022 y describe Copilot tal como existía en el momento de aquel estudio, no los modelos actuales. Las cifras de Cursor proceden de un estudio longitudinal de 807 repositorios contra un grupo de control de 1 380, seguidos de enero de 2024 a agosto de 2025. Las disposiciones del CRA citadas remiten al Reglamento (UE) 2024/2847 y se han verificado contra la versión lingüística española oficial. Esta página es una traducción del original inglés; en caso de divergencia, prevalece el original. Si algo aquí es erróneo, lo corregiremos por escrito en esta página.