El 3 de agosto de 2026, el mantenedor de las ramas estables de Linux y la subsistema de staging, Greg Kroah-Hartman, anunció nuevas reglas para la aceptación de cambios en el catálogo drivers/staging. La razón de esto fue la reciente «invasión de parches creados por LLM». Ahora, las correcciones preparadas por modelos de lenguaje para esta parte del núcleo serán rechazadas automáticamente, salvo excepciones confirmadas de vulnerabilidades reales.
El catálogo drivers/staging se utiliza para albergar controladores y otros componentes que aún no cumplen con los requisitos de la rama principal de Linux. Según la documentación oficial del núcleo, dicho código permanece en staging mientras requiera trabajo adicional; tras refinamientos, puede ser trasladado a la parte principal del núcleo, y los componentes que no se desarrollan se eliminan con el tiempo.
Sin embargo, Kroah-Hartman también señaló otra tarea de esta subsistema: drivers/staging existe principalmente como un lugar donde los desarrolladores principiantes pueden aprender a participar en el desarrollo del núcleo. Aquí se dejan deliberadamente muchas tareas relativamente simples: correcciones de formato de código, migraciones a nuevas API y pequeñas reestructuraciones. Al realizarlas por su cuenta, los principiantes dominan la preparación de parches, la comunicación en listas de correos y el procedimiento de revisión.
Según el mantenedor, la limpieza automática de dicho código va en contra del propósito mismo de staging. Señaló que los desarrolladores podrían corregir todas las fallas formales utilizando herramientas automáticas si ese fuera el objetivo principal. En su lugar, se conservan algunas tareas sencillas para que los humanos puedan aprender de ellas. Por ello, Kroah-Hartman tiene la intención de «rechazar automáticamente cualquier parche creado por LLM para la subsistema drivers/staging».
Los intentos de no indicar el uso de un modelo de lenguaje tampoco ayudarán. Kroah-Hartman declaró que tales cambios suelen ser fáciles de reconocer y advirtió a los autores que esconder deliberadamente el origen del parche podría interpretarse como un intento de engañar a los mantenedores. El objetivo es que las personas puedan aprender, no que intenten engañar al mantenedor, explicó el desarrollador.
La única excepción se hace para correcciones de errores de seguridad reales. Se permite enviar dicho parche, pero el autor debe probarlo en el hardware real para el cual se destina el controlador y describir detalladamente las pruebas realizadas. Además, el remitente debe estar preparado para demostrar que el error es realmente reproducible y puede afectar al usuario. Según Kroah-Hartman, «al menos un tercio» de los problemas modernos detectados por LLM resultan ser erróneos o provocan cambios perjudiciales.
El propio Kroah-Hartman compara drivers/staging con «un gimnasio donde se puede aprender y desarrollar habilidades». Según él, los modelos de lenguaje están gradualmente convirtiéndose en herramientas adecuadas para «el trabajo duro», pero deben ser utilizados por especialistas que ya tienen conocimientos suficientes para evaluar el resultado. Así, la decisión no impone una prohibición general sobre el uso de IA en el desarrollo de Linux: la nueva regla se refiere únicamente al árbol drivers/staging que acompaña Kroah-Hartman y, sobre todo, a las correcciones cosméticas generadas automáticamente.
Fuente: linux.org.ru
