La inteligencia artificial ya revisa cada parche enviado al subsistema de redes del kernel Linux, pero la experiencia está dejando una conclusión menos cómoda que la esperada: automatizar la revisión no elimina necesariamente trabajo humano. Jakub Kicinski, uno de los responsables de Linux Networking, asegura que los mantenedores llegaron a dedicar alrededor del 50 % de su tiempo a intentar descartar observaciones generadas por IA, mientras el proyecto recibe unos 150 parches diarios.
Las claves de la IA revisando Linux en 20 segundos
- Linux Networking utiliza IA para revisar todos los parches recibidos desde el ciclo 7.0.
- Sashiko ejecuta modelos como Gemini y, en otra instancia, Claude, mientras se han incorporado modelos adicionales.
- Los mantenedores llegaron a dedicar cerca del 50 % de su tiempo a comprobar revisiones de IA.
- En Linux 7.3 mejoró la cobertura humana, pero el equipo reconoce estar «completamente desbordado».
- Google y Meta financian parte de la infraestructura y del consumo de modelos.
La experiencia resulta especialmente interesante porque Linux ofrece algo difícil de encontrar en otros proyectos: datos públicos sobre qué ocurre cuando la IA deja de utilizarse ocasionalmente y pasa a formar parte permanente del proceso de desarrollo.
Y las cifras plantean una paradoja. La IA encuentra errores que pueden ser útiles, pero también produce falsos positivos que alguien debe investigar. Al mismo tiempo, herramientas generativas permiten que más desarrolladores produzcan código a mayor velocidad. El resultado puede ser que la capacidad para escribir software crezca bastante más deprisa que la capacidad humana disponible para revisarlo.
De revisar algunos parches a que la IA los lea todos
Linux Networking comenzó a ejecutar un revisor basado en inteligencia artificial sobre todas las contribuciones durante el ciclo de Linux 7.0.
Posteriormente adoptó Sashiko, una herramienta desarrollada inicialmente por Roman Gushchin y otros ingenieros de Google y transferida a la Linux Foundation bajo licencia Apache 2.0. Según los datos recopilados en el artículo aportado, su instancia pública había superado las 141.000 revisiones distribuidas entre 90 listas de correo.
La idea tiene bastante sentido.
El kernel Linux recibe una enorme cantidad de código y dispone de un número limitado de desarrolladores experimentados capaces de revisarlo. Un modelo puede realizar una primera lectura prácticamente inmediata, detectar posibles errores, comprobar determinados patrones y llamar la atención sobre problemas antes de que intervenga un mantenedor.
Pero la máquina no tiene la última palabra.
Ahí aparece el coste que inicialmente podía pasar inadvertido: cuando una IA señala un posible fallo, un desarrollador tiene que determinar si realmente existe.
Kicinski estimó durante uno de los ciclos que alrededor de 13 de cada 100 observaciones generadas por el sistema eran incorrectas o no merecían ser trasladadas a los desarrolladores. Posteriormente llegó una cifra todavía más reveladora: los mantenedores estaban empleando aproximadamente la mitad de su tiempo en intentar refutar revisiones producidas por IA.
Es decir, la IA puede reducir el coste de encontrar un posible error, pero no reduce de la misma manera el coste de demostrar que ese error es real.
Linux 7.3 mejora las cifras, aunque el equipo sigue desbordado
La evolución de la revisión humana muestra otro fenómeno interesante.
Según las estadísticas publicadas por Kicinski y recogidas en el material aportado, el porcentaje del código aceptado que había sido leído previamente por una persona pasó del 71,77 % en Linux 6.18 al 64,64 % en 6.19.
Con Linux 7.0, primer ciclo con revisión automática sobre cada envío, descendió hasta el 60,30 %. En Linux 7.1 cayó al 53,36 % y en Linux 7.2 alcanzó el mínimo reciente del 50,84 %.
Linux 7.3 rompe esa tendencia y recupera el 64,42 %.
La segunda métrica resulta quizá todavía más interesante: qué porcentaje fue revisado por una persona perteneciente a una empresa diferente a la del autor.
Pasó del 53,58 % en Linux 6.18 al 49,92 % en 6.19; posteriormente bajó al 47,85 % en 7.0, al 42,85 % en 7.1 y al 39,76 % en 7.2. En Linux 7.3 vuelve a subir hasta el 53,98 %.
| Ciclo | Código leído por una persona | Autor y revisor de empresas diferentes |
|---|---|---|
| Linux 6.18 | 71,77 % | 53,58 % |
| Linux 6.19 | 64,64 % | 49,92 % |
| Linux 7.0 | 60,30 % | 47,85 % |
| Linux 7.1 | 53,36 % | 42,85 % |
| Linux 7.2 | 50,84 % | 39,76 % |
| Linux 7.3 | 64,42 % | 53,98 % |
La recuperación no puede atribuirse simplemente a que los modelos hayan sustituido mejor a los revisores.
El propio proceso ha cambiado. Con más de 300 parches esperando revisión en determinados momentos, los mantenedores empezaron a priorizar aquellos que ya disponían de revisión humana. Eso aumenta la probabilidad de que el código revisado llegue finalmente al árbol del kernel.
También aumentó un 4,5 % el número de colaboradores, según las cifras recogidas. Sin embargo, muchos de los nuevos participantes envían código generado o asistido por modelos y apenas revisan contribuciones de terceros.
Aquí aparece uno de los problemas que puede extenderse mucho más allá de Linux.
La IA democratiza la producción de código, pero todavía no democratiza en la misma proporción el conocimiento necesario para responsabilizarse de revisarlo.
Dos modelos para intentar controlar las alucinaciones
Linux Networking está probando además una solución muy propia de la actual carrera de la IA: utilizar más IA para comprobar la IA.
Kicinski explicó en agosto que habían conseguido presupuesto suficiente para ejecutar varios modelos avanzados sobre cada parche, una estrategia con la que esperan reducir determinadas alucinaciones.
El artículo aportado señala que Google financia la instancia pública de Sashiko, mientras Meta financia otra utilizada específicamente por Linux Networking. Las diferentes instancias pueden ejecutar modelos distintos sobre un mismo código y comparar sus resultados.
Esto tiene una ventaja evidente: dos modelos pueden cometer errores diferentes y ayudar a identificar observaciones dudosas.
También introduce una cuestión incómoda para un proyecto abierto como Linux.
Si revisar cada contribución empieza a requerir cantidades importantes de tokens de modelos comerciales, ¿quién paga permanentemente esa infraestructura?
Roman Gushchin llevó precisamente la sostenibilidad de Sashiko al Maintainers Summit. Entre las cuestiones planteadas está la dependencia de infraestructura y presupuestos aportados por empresas externas.
No significa que exista una interferencia de esas compañías en el desarrollo del kernel. El problema es estructural: una herramienta abierta puede terminar dependiendo económicamente de servicios de IA cuyo coste no controla.
El cuello de botella empieza a ser la atención humana
El caso Linux ayuda a cuestionar una de las ideas más repetidas alrededor de la programación asistida por IA.
Si un desarrollador puede producir diez veces más código, una organización no obtiene automáticamente diez veces más software útil.
Ese código debe entenderse, probarse, integrarse, mantenerse y, en proyectos especialmente sensibles, revisarse por alguien dispuesto a responsabilizarse de él.
Linux Networking ofrece un ejemplo extremo. Cuatro personas aparecen como mantenedores principales: David S. Miller, Eric Dumazet, Jakub Kicinski y Paolo Abeni. Según el recuento citado, solamente dos gestionaron buena parte de los 1.280 parches del ciclo analizado.
Mientras tanto, la IA puede intervenir en ambos extremos.
Puede ayudar a escribir un parche y posteriormente otro modelo puede revisarlo. Kicinski llegó a estimar que entre un tercio y la mitad de determinados cambios incorporados durante Linux 7.3 podían haber sido escritos con ayuda de modelos, aunque dejó expresamente claro que se trataba de una estimación que no podía demostrar.
También se está utilizando IA en tareas menos críticas. Andrew Morton recurrió a Gemini para preparar borradores de los resúmenes de cambios de memoria del kernel, que después revisó personalmente.
Incluso Linus Torvalds ha experimentado con modelos para redactar mensajes de commit, según los episodios recopilados en el artículo.
Esto dibuja probablemente una utilización más realista de la IA en desarrollo: no sustituir de golpe al programador, sino aparecer progresivamente en casi todas las fases que rodean al código.
El riesgo comienza cuando desaparece el humano que entiende suficientemente bien lo que sucede entre ellas.
Linux tiene una defensa particularmente importante contra ese escenario: la cultura de revisión, las listas públicas y etiquetas como Reviewed-by, mediante las que una persona deja constancia de que ha examinado un cambio.
Si en el futuro una máquina escribe el código, otra lo revisa y una tercera termina aplicándolo automáticamente, esa línea dejará de ser un formalismo.
Será la respuesta a una pregunta bastante más importante: ¿qué persona leyó realmente el código antes de que acabara ejecutándose en millones de sistemas?
Preguntas frecuentes
¿Linux utiliza inteligencia artificial para revisar código?
Sí. El subsistema Linux Networking ejecuta revisión mediante IA sobre todos los parches que recibe desde el ciclo Linux 7.0, aunque la revisión automática no sustituye formalmente la responsabilidad de los mantenedores.
¿La IA está reduciendo el trabajo de los mantenedores de Linux?
No necesariamente. Kicinski llegó a indicar que los mantenedores empleaban alrededor del 50 % de su tiempo intentando descartar observaciones de las revisiones automáticas, aunque los modelos también detectan problemas reales.
¿Cuánto código de Linux Networking sigue siendo revisado por personas?
En Linux 7.3, el 64,42 % del código integrado había sido leído por una persona, frente al 50,84 % del ciclo 7.2. El porcentaje revisado por alguien de una empresa diferente a la del autor subió del 39,76 % al 53,98 %.
¿Quién paga los modelos utilizados para revisar Linux?
Según la información recopilada, Google financia la instancia pública de Sashiko y Meta aporta presupuesto para otra instancia utilizada en Linux Networking. Esta dependencia también ha abierto un debate sobre la sostenibilidad a largo plazo de la revisión mediante modelos comerciales.
