Linux 7.2: la IA dispara los bugs corregidos en el kernel

El kernel Linux 7.2 absorbió 16.418 commits no-merge y sumó 2.652 desarrolladores, un récord absoluto de participación. Pero el dato que debería hacer ruido en cualquier equipo de producto es otro: 4.830 commits de esa versión llevan etiqueta Fixes, es decir, corrigen un error introducido por un commit anterior. La curva venía plana durante varias versiones y se disparó justo cuando una masa crítica de personas empezó a usar modelos de lenguaje para cazar bugs. No es una anécdota del kernel: es un espejo de lo que ya está pasando en tu repositorio.

Linux 7.2 en números: el ciclo más cargado de la historia reciente

La 7.2 es la segunda versión más cargada de la historia del kernel. Solo la supera la 6.7, pero esa cifra estaba inflada por la fusión del historial de desarrollo de bcachefs; el volumen de la 7.2, en cambio, está repartido entre todos los subsistemas según LWN.

En participación, 2.652 desarrolladores aportaron cambios contra el récord anterior de 2.479 en la 7.1. Los dos lanzamientos previos ya habían marcado récord de debutantes y la 7.2 lo rompió otra vez, con 613 contribuyentes nuevos.

Al frente por cantidad de changesets quedó Uwe Kleine-König con 151 commits (0,9%), dedicado a limpiezas en el subsistema de drivers. Lo sigue Rosen Penev con 146, autor de una larga lista de correcciones de bugs generadas con modelos de lenguaje en arquitecturas, drivers, redes y criptografía. Ian Rogers (138) y Arnaldo Carvalho de Melo (131) trabajaron sobre la herramienta perf en espacio de usuario, mientras que Johan Hovold (133) se concentró en SPI y USB.

En líneas modificadas manda Matthew Stewart (83.587, 8,4%), por la vía clásica de añadir archivos de cabecera de amdgpu generados por máquina, seguido por Hawking Zhang (62.893).

Del lado corporativo, LWN identificó 249 empleadores. Intel lideró por changesets con 1.512 (9,2%), seguido por Red Hat (873), AMD (813), Qualcomm (767), NVIDIA (535) y Meta (441). Por líneas modificadas, AMD se llevó el 22,4% del total, empujada por el trabajo en drivers gráficos.

Según Linux Journal, la versión final se publicó el 16 de agosto de 2026 tras siete release candidates, y su novedad estrella fue Cache-Aware Scheduling, un planificador que agrupa las tareas que comparten datos en el mismo dominio de caché LLC para reducir los fallos de caché en servidores multihilo y cargas de IA.

La IA encuentra bugs más rápido de lo que el kernel puede procesarlos

Más del 48% de los commits de la 7.2 llevaron etiqueta Reviewed-by y algo más del 8% incluyeron Tested-by, con una tendencia leve a la baja en las etiquetas de revisión. En paralelo, el número de commits con etiqueta Fixes dio el salto.

Linus Torvalds lo describió a ZDNET como "the new normal with a lot of fixes, many of them due to review by various AI tools". Antes del lanzamiento de la 7.1 había sido mucho más duro: dijo que el flujo continuo de reportes de IA había vuelto la lista de seguridad "casi inmanejable", con duplicaciones enormes porque distintas personas encontraban lo mismo con las mismas herramientas. Su postura no es anti-IA: sostiene que las herramientas de IA son valiosas solo si ayudan de verdad, en lugar de generar dolor innecesario y trabajo imaginario.

XDA Developers reportó que el séptimo release candidate fue más grande de lo habitual y que Torvalds lo atribuyó justamente a que los agentes de IA están encontrando bugs más rápido de lo que los humanos pueden procesarlos.

Hay una señal concreta de ese cambio de herramientas: 252 patches de la 7.2 llevan etiqueta Reported-by que acredita al sistema de revisión Sashiko, y 568 commits lo mencionan en su changelog.

¿Cuánto código del kernel se escribe realmente con IA?

Oficialmente, 1.111 cambios (menos del 7% del total) llevaron etiqueta Assisted-by, frente a los 301 de la 7.1. LWN advierte que el número real debe ser mucho mayor: muchos desarrolladores no etiquetan por desconocer las reglas, los maintainers casi nunca preguntan y al menos uno elimina esas etiquetas al aplicar los parches. Medir con precisión cuánto código nace de un modelo puede ser, directamente, imposible.

El caso más comentado es el de Bryam Vargas, el debutante más activo con 43 commits repartidos entre input, NVMe, F2FS, AppArmor, Landlock, SELinux, NTFS, WiFi, ATA, SCSI, redes, Ceph y Thunderbolt. LWN señala que a un desarrollador veterano le costaría llegar con esa profundidad a tantos subsistemas en un solo ciclo, y que los parches de Vargas no llevan Assisted-by, así que hay que creer que se hicieron sin asistencia de LLM.

El riesgo que viene después: código que nadie entiende

El propio análisis de LWN plantea la pregunta incómoda. Si la IA permitió crear parches a personas que antes no habrían podido, es razonable concluir que muchos remitentes no entienden del todo lo que hacen sus propios parches. El escenario posible es una pila de código que nadie comprendió nunca del todo y que igual habrá que mantener durante años.

El kernel lleva 35 años absorbiendo procesos y herramientas nuevas, y casi siempre encontró la manera, aunque no siempre sin turbulencias. El flujo tampoco se detiene: en el repositorio linux-next hay casi 14.000 changesets esperando para la 7.3, y más de 1.100 ya llevan Assisted-by.

¿Qué significa esto para tu startup?

El kernel es el experimento más grande del mundo sobre qué pasa cuando la IA escribe y revisa código a escala. Tu equipo puede leer los resultados sin pagar el costo de ser el conejillo de indias.

• Etiqueta lo que genera la IA. La comunidad del kernel resolvió la trazabilidad con Assisted-by y Reported-by. En tu repositorio, un trailer en el commit o un campo obligatorio en el pull request (qué agente lo generó, quién lo revisó) te da algo que hoy casi nadie tiene: la capacidad de medir cuánto de tu código viene de agentes y con qué calidad sale.
• Mete una capa de verificación antes del merge. Google lanzó revisión automatizada en Conductor, su extensión de Gemini CLI: genera un informe post-implementación que audita calidad del código, cumplimiento del plan original, guías de estilo, ejecución de tests y seguridad básica antes de que el código llegue a producción. Es open source bajo licencia Apache 2.0 y convive con CodeRabbit, Qodo, Copilot Review o Bugbot. El dato que lo justifica: según CodeRabbit, el código generado por IA introduce 1,7 veces más bugs que el escrito por humanos, con errores de lógica un 75% más frecuentes.
• Mide tu ratio de Fixes. Si en el kernel los commits de corrección se dispararon, esa misma métrica es la más barata que puedes activar en tu producto: qué porcentaje de los commits del mes corrigen algo que se rompió antes. Compáralo en la ventana previa y posterior a la adopción de agentes. Si sube, no tienes más velocidad: tienes más retrabajo.
• No confundas volumen con productividad. 16.418 commits suenan a un equipo imparable, pero dentro de esa cifra hay 4.830 correcciones. Un tablero que solo muestra commits entregados está midiendo actividad, no salud del código.
• Rota revisores humanos en los módulos críticos. La conclusión que deja este ciclo no es prohibir agentes, sino evitar que un módulo entero dependa de código que ningún humano del equipo sabría defender en una sesión de debugging.

Conclusión

Linux 7.2 no será recordado por una feature espectacular, sino por haber expuesto con datos lo que pasa cuando la IA entra de lleno en un proyecto de software: más detección de bugs, más correcciones y una pregunta abierta sobre cuánto de ese código alguien entiende de verdad. La ventaja competitiva ya no está en generar código más rápido, sino en tener la infraestructura de verificación y trazabilidad para sostener esa velocidad sin acumular deuda técnica que explote en dos años.

Fuentes

• LWN: Development statistics for the 7.2 kernel (fuente original)
• ZDNET: AI-enriched Linux 7.2 delivers cache-aware scheduling
• Linux Journal: Linux Kernel 7.2 Officially Released
• XDA Developers: Linux 7.2 is on track to release next week
• WWWhat's New: Google Conductor añade revisión automática de código