Más de 110,000 issues de código generado por IA siguen vivos en GitHub

La discusión sobre asistentes de código suele quedarse en la productividad: cuánto más rápido sale una feature, cuántas líneas por día, cuántos tickets por sprint. Es la mitad fácil de medir. La otra mitad — qué pasa con ese código seis meses después de entrar a main — casi no se mide, y es justo la que un estudio empírico reciente decidió observar a escala.

El estudio

"Debt Behind the AI Boom", de investigadores de Singapore Management University y Huazhong University of Science and Technology, identificó commits escritos por asistentes de IA a partir de señales explícitas en los metadatos de Git — logins de bots, correos de autor y trailers Co-authored-by — entre enero de 2024 y octubre de 2025. Cubre GitHub Copilot, Claude, Cursor, Gemini y Devin, en Python, JavaScript y TypeScript, y corrió análisis estático sobre cada cambio (Pylint y Bandit para Python; ESLint y njsscan para JS/TS). Los resultados:

• 484,606 issues introducidos, repartidos en 3,841 repositorios — el 61.2% de los analizados.
• En cada una de las herramientas estudiadas, más de 15% de los commits que modifican código analizable introduce al menos un issue.
• Por tipo: 89.1% code smells, 5.8% bugs de ejecución y 5.1% issues de seguridad.
• 24.2% de los issues rastreados potencialmente sigue vivo en HEAD: unos 37 issues sobrevivientes por cada 100 commits de IA.
• La deuda acumulada pasó de unos cientos de issues a inicios de 2025 a más de 110,000 sobrevivientes en febrero de 2026.
• Supervivencia por tipo: 41.1% seguridad, 30.3% bugs de ejecución, 22.7% code smells.

Lo que el dato de seguridad está diciendo

La cifra más importante del paper no es el volumen, es el orden de la supervivencia. Si la revisión estuviera filtrando por severidad, esperaríamos lo contrario: que los problemas de seguridad fueran los primeros en corregirse y los code smells los que se quedan. El estudio muestra que los issues de seguridad son los que más sobreviven.

La explicación más razonable es que esos problemas no se ven en una revisión de diff. Un subprocess con shell=True, una consulta armada con interpolación de strings o un secreto en un archivo de configuración no rompen ningún test y no lucen raros en un PR que por lo demás está bien escrito. Y el código generado por IA suele verse bien escrito: nombres coherentes, estructura limpia, comentarios razonables. Esa apariencia es exactamente lo que baja la guardia del revisor.

La IA amplifica lo que ya tenías

El reporte DORA 2025 de Google, con casi 5,000 profesionales de tecnología encuestados, llega a una conclusión compatible desde otro ángulo: 90% ya usa IA en su trabajo, más de 80% cree que aumentó su productividad, y aun así 30% reporta poca o ninguna confianza en el código que genera. Su hallazgo central lo resume en una frase: la IA no arregla a un equipo, amplifica lo que ya está ahí.

Leídos juntos, los dos trabajos describen el mismo mecanismo. Un equipo con análisis estático en CI, reglas de seguridad obligatorias y revisión con criterio obtiene velocidad. Un equipo sin esas barreras obtiene la misma velocidad, más deuda — y el paper sugiere que la deuda se acumula en la categoría más cara.

Cómo lo abordamos en SmartDevs

Usamos asistentes de código todos los días y no pensamos dejar de hacerlo. Lo que cambiamos fue el proceso alrededor, bajo la premisa de que el cuello de botella ya no es escribir código sino verificarlo:

• El análisis estático no es opcional ni se revisa a ojo. Linters y escáneres de seguridad corren en cada PR y bloquean el merge. Las herramientas del estudio — Bandit, ESLint con reglas de seguridad — son gratuitas; no tenerlas en CI es una decisión, no una limitación.
• Las superficies sensibles tienen revisión humana explícita. Autenticación, manejo de secretos, ejecución de comandos, consultas a base de datos y webhooks de pago no se aprueban por "se ve bien". Si el diff toca esas zonas, alguien lo lee con esa lista en mano.
• PRs chicos, aunque la IA pueda generar grandes. Un asistente escribe 800 líneas con la misma facilidad que 80; un revisor no las revisa igual. Limitar el tamaño del cambio es la forma más barata de que la revisión siga siendo real.
• La deuda se mide después del merge. El hallazgo del paper es sobre supervivencia, no sobre introducción. Por eso corremos los mismos escáneres periódicamente sobre la rama principal completa, no solo sobre el diff — lo que se coló no aparece en el siguiente PR.

La conclusión práctica

Si tu equipo adoptó asistentes de código en el último año, el ejercicio con mejor retorno para esta semana no es cambiar de herramienta. Es correr un escáner de seguridad sobre la rama principal completa — no sobre el último PR — y contar cuántos hallazgos entraron desde que empezó a usarse IA. Ese número te dice si tu proceso de revisión escaló junto con tu velocidad de escritura, o si estás en la estadística de las 110,000.