# La velocidad pasa. La complejidad se queda.

> Tres estudios independientes, tres métodos distintos — un estudio dirigido de vulnerabilidades, una comparación controlada humano-modelo y un año de observación de repositorios reales — convergen en el mismo hallazgo: el código generado por IA acarrea un coste de calidad medible que sobrevive a la ganancia de productividad con la que llegó.

Source: https://counterproof.io/es/notes/la-velocidad-pasa-la-complejidad-se-queda/ · Published 25 August 2026 · CounterProof es una práctica de Clavestra Capital Limited (Malta, C 113987).


«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*](https://counterproof.io/notes/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
1) 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*](https://counterproof.io/notes/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í](https://research.counterproof.io/) (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.*