Lorenzo Stoakes reducirá su trabajo de revisión en el kernel Linux porque el volumen de series de parches generadas con inteligencia artificial ha superado el tiempo que puede dedicarles. El ingeniero principal de software de Arm no deja el proyecto: conservará sus tareas de mantenimiento y limitará las revisiones generales a las áreas bajo su responsabilidad directa.
La decisión quedó formalizada en una serie de cuatro parches enviada a la lista de correo del kernel el 10 de noviembre. En ella, Stoakes propone retirarse de funciones de revisión en varias áreas de gestión de memoria, mientras redistribuye esas tareas entre otros responsables. Según explicó, el volumen actual de series generadas con IA le deja sin capacidad para ofrecer revisiones generales fuera de las áreas que mantiene.
“Given the current throughput in the kernel resulting from AI-generated series, I unfortunately lack the bandwidth to generally be able to offer review except in those areas I maintain.”
— Lorenzo Stoakes, ingeniero principal de software de Arm
Una retirada parcial, no una salida del proyecto
El cambio afecta a funciones de revisión, no a las responsabilidades de mantenimiento que Stoakes conserva. En declaraciones a The Register, aclaró que no piensa renunciar a esas responsabilidades: quiere reducir la carga de su bandeja de entrada y dejar de revisar de forma general fuera de los subsistemas que mantiene.
La distinción importa porque revisar y mantener no son tareas intercambiables. Stoakes describe en su currículum cuatro áreas de mantenimiento relacionadas con la gestión de memoria: mapeo de memoria, su bloqueo, la interfaz madvise y el mapeo inverso entre memoria física y virtual. Según su propio mensaje, el ajuste le permite concentrar el trabajo en esas áreas, en vez de asumir una disponibilidad amplia para revisar otras contribuciones.
La serie enviada a la lista organiza las revisiones que deja por áreas y las deriva a David Hildenbrand, Andrew Morton y Alice Ryhl junto con Danilo Krummrich. También incorpora una entrada en CREDITS por su trabajo de mantenimiento de THP, las páginas enormes transparentes. Stoakes explica que, tras el nombramiento de Zi como co-mantenedor, ya no espera tener que intervenir allí.
Más propuestas, la misma capacidad de revisión
El problema que señala Stoakes es una diferencia de escala: producir parches se ha vuelto más fácil, pero no ha aumentado de la misma manera el número de personas disponibles para comprobarlos. Una propuesta debe llegar a alguien que entienda el área, evalúe los cambios y decida si encaja. La IA puede acelerar la generación de código; no elimina ese trabajo de evaluación.
Stoakes describió a The Register una progresión clara: las contribuciones asistidas por IA pasaron de aparecer una vez por semana a llegar a diario, y ahora representan, según su estimación, la mitad de lo que ve durante las revisiones. Añadió que el impacto alcanza a la gestión de memoria en conjunto. También contó que suele terminar trabajando durante las noches y los fines de semana, una rutina que vincula con el riesgo de agotamiento.
Para los responsables de un proyecto, la consecuencia inmediata no es solo una cola más larga. Si un revisor reduce su disponibilidad, el trabajo tiene que repartirse entre otras personas o esperar; en este caso, el propio Stoakes separó los parches por áreas para que otros mantenedores puedan hacerse cargo. La decisión evita presentar la revisión como una obligación ilimitada de una sola persona, pero también deja al descubierto que el cuello de botella está en la atención experta, no en la cantidad de código que se puede generar.
Greg Kroah-Hartman, citado por The Register tras una sesión de preguntas en el Open Source Summit del mes anterior, expresó una preocupación parecida: dijo que no hay suficientes personas para revisar todos los parches generados por LLM y que los mantenedores llevan años agotados. Su comentario sitúa el caso de Stoakes en una tensión más amplia dentro del mantenimiento del kernel: el aumento de propuestas llega a una comunidad que, según Kroah-Hartman, ya carece de revisores suficientes.
El contraste con las correcciones asistidas por IA
La carga de revisión coincide con otra señal, de signo más favorable. Linuxiac informa de que Linus Torvalds destacó el uso creciente de correcciones asistidas por IA en Linux 7.4-rc2. En su anuncio del 8 de noviembre escribió que buena parte del trabajo reciente de mantenimiento había recurrido a ellas y que quizá dejaría de mencionarlo porque podría convertirse en algo habitual.
Torvalds también citó al mantenedor de BPF, Alexei Starovoitov, quien observó que en ese subsistema el ritmo de correcciones ya supera al de nuevos informes de errores. Torvalds advirtió que no ocurre lo mismo en la mayoría de las demás áreas: lo presentó como una posible señal de avance en BPF, no como una mejora general del kernel. Linuxiac señala además que no identificó qué herramientas produjeron las correcciones ni qué parches concretos fueron generados por IA.
Así conviven dos efectos: las herramientas pueden ayudar a encontrar y corregir errores, pero también aumentan el caudal de material que alguien debe revisar. Más correcciones no equivalen a menos trabajo de revisión si cada propuesta sigue necesitando evaluación humana y el número de revisores no crece al mismo ritmo. La diferencia entre ambos casos también importa: el comentario de Torvalds se refiere a correcciones que llegan al desarrollo; Stoakes habla de la carga que supone el conjunto de series que recibe para revisar.
Qué cambia para quienes mantienen software
El episodio hace visible una limitación organizativa para las empresas que dependen de Linux: un proyecto puede recibir más contribuciones sin ganar capacidad para integrarlas. En el caso de Stoakes, la respuesta consiste en acotar su disponibilidad y repartir responsabilidades, no en abandonar los subsistemas que mantiene.
Para quienes envían cambios, el contexto eleva el coste de una propuesta que llega sin suficiente preparación: consume tiempo de revisión aunque después no se integre. Hardware Upgrade recoge el mismo problema en otros proyectos de código abierto y menciona la preocupación de los desarrolladores de Godot por los aportes generados por IA. El ejemplo no convierte el caso de Linux en una prohibición general; muestra que cada comunidad tiene que decidir cómo gestionar un volumen que sus revisores quizá no puedan absorber.
La decisión de Stoakes también delimita qué puede esperarse de una persona con varias responsabilidades: mantener un área no implica revisar todo el kernel. Al formalizar la salida de ciertas funciones y reasignar las series, hace explícito qué trabajo puede seguir ofreciendo. La pregunta práctica para los proyectos y las compañías que los utilizan es cómo sostener la revisión cuando generar propuestas cuesta cada vez menos, pero el juicio de quienes conocen el código sigue siendo un recurso limitado.
Stoakes no ha renunciado a sus mantenimientos y quiere que su bandeja de entrada sea más manejable. Las cuatro modificaciones enviadas a la lista de correo traducen esa decisión en cambios concretos de responsabilidades.
Fuentes: theregister, Hardware Upgrade, Linuxiac, Linux kernel mailing list (Lorenzo Stoakes’s original post), Tom's Hardware
