La IA está inundando Linux 7.3 de código basura y sus desarrolladores ya no dan abasto: "Estamos completamente desbordados"
Elígenos como tu fuente preferida en Google.
Los desarrolladores del kernel de Linux están recibiendo cada vez más parches creados con ayuda de la IA. Aunque son cambios pequeños, toca revisarlos uno por uno.
Linux 7.2 ya queda como parte del pasado y ahora todos los esfuerzos están enfocados en Linux 7.3. Sin embargo, no ha empezado del todo bien y esta primera semana está siendo difícil de manejar por culpa de la inteligencia artificial.
La cantidad de código generado con ayuda de IA está creciendo tanto que los propios responsables del kernel afirman estar desbordados. El problema no es que la inteligencia artificial esté escribiendo una parte vital de Linux, sino que está generando una avalancha de pequeños cambios que alguien tiene que revisar.
Lo que comenzó como una herramienta con enorme potencial (con la que todos estaban de acuerdo) para ayudar a los programadores, se ha convertido en una pesadilla que está colapsando las listas donde se gestionan los fallos de seguridad más críticos de la plataforma.
El problema es que no todos esos resultados son útiles. Las herramientas de IA no siempre entienden el contexto completo del sistema, y muchas veces señalan posibles errores que en realidad no afectan a nadie o que ni siquiera son verdaderos problemas.
Aun así, esos avisos llegan a los desarrolladores como si fueran importantes. Y aquí es donde empieza el problema de verdad.
El caso está afectando especialmente al subsistema de red de Linux, uno de los más grandes y complicados del kernel. Jakub Kicinski, uno de sus responsables, explica que él y Paolo Abeni han tenido que revisar un volumen enorme de parches. En Linux 7.3 se han integrado 632 cambios en net y otros 648 en net-next, pero esto va más allá.
Según Kicinski, entre un tercio y la mitad de los parches de net-next parecen estar relacionados con tareas de baja prioridad, pequeñas correcciones, limpiezas de código o aclaraciones generadas con ayuda de modelos de lenguaje.
Y aquí está el problema: que una IA genere un parche es muy rápido, pero comprobar que ese parche no rompe nada puede llevar bastante más tiempo.
Los responsables de Linux tienen que revisar el código, entender qué intenta cambiar, comprobar que realmente soluciona algo y asegurarse de que no genera otro problema. Todo esto mientras también se enfocan en crear una actualización de kernel verdaderamente potente.
¿Por qué la IA está generando tantos parches para Linux?
El problema de base, si bien es cierto que tanto Linus Torvalds como otras grandes figuras de Linux están de acuerdo con su uso, es que la IA puede analizar código y proponer cambios en cuestión de segundos. Esto tiene sus pros y sus contras.
El problema aparece cuando esa aparente facilidad casi mágica se lleva a un proyecto como Linux. Una persona puede pedir a una IA que busque errores, limpie código antiguo o haga pequeños cambios y acabar enviando un parche al proyecto. El desarrollador que mantiene esa parte del kernel, sin embargo, sigue teniendo que comprobarlo.
La respuesta de los responsables del kernel es que, si la IA está provocando más trabajo, también puede ayudar a revisarlo.
Kicinski explica que han conseguido suficiente presupuesto para utilizar modelos de lenguaje muy potentes durante las revisiones, gracias al apoyo de Meta. La idea es pasar los parches por varios modelos antes de que lleguen a los desarrolladores y utilizar esas herramientas para detectar algunos errores o problemas.
Aclarar que no se trata de dejar que una IA decida qué código entra en Linux. Los mantenedores siguen teniendo la última palabra. Lo que buscan es utilizar los modelos como una primera capa de revisión que ayude a encontrar problemas antes de que una persona tenga que perder tiempo en ellos.
Aun así, el principal problema de la IA sigue estando ahí: no es infalible. La IA sigue sin entender todo lo que ocurre dentro del kernel.
Hay errores que solo aparecen cuando falla un componente concreto, cuando se produce un problema de hardware o cuando ocurre una situación que no es normal. Entre los ejemplos que comentan están los errores de PCIe y los tiempos de espera.
Son casos en los que un modelo puede echar un vistazo al código y pensar que todo está bien, mientras que un desarrollador con años a sus espaldas sabe que existe una forma concreta que puede acabar provocando un fallo. Desde luego, esto parece la pescadilla que se muerde la cola.
