La inteligencia artificial sigue colándose en los rincones más inesperados del desarrollo de software. El último ejemplo llega de la mano de Lorenzo Stoakes, ingeniero principal de ARM y mantenedor del subsistema de gestión de memoria del kernel de Linux, quien ha presentado una serie de 23 parches para acelerar drásticamente la compilación del kernel apoyándose en un modelo de lenguaje grande (LLM).
Según detalla la lista de correos de Linux, el resultado obtenido es llamativo. Por un lado, tenemos compilaciones un 36% más rápidas con todos los módulos habilitados (allmodconfig), hasta un 70% más rápidas en builds incrementales y un 90% en compilaciones «noop» (aquellas en las que no hay cambios que recompilar). Pero lo más interesante no son solo las cifras, sino cómo se ha llegado a ellas.
El monohilo sigue siendo el cuello de botella
El proceso de compilación del kernel de Linux arrastra desde hace muchos años varios problemas estructurales. Pero uno de ellos es un cuello de botella enorme: varias fases críticas se ejecutan en un solo hilo de procesador, lo que frena el rendimiento general incluso en máquinas con decenas de núcleos.
Stoakes identificó que el tiempo muerto en estas secciones serializadas era el principal obstáculo para reducir los tiempos de build. Esto es un problema ampliamente conocido, pero que nadie había tratado de solucionar debido a lo complejo, Stoakes es el primero.
Los parches abordan múltiples componentes de la infraestructura de compilación: Kbuild (el sistema de construcción principal), kallsyms (gestión de símbolos del kernel), modpost (post-procesamiento de módulos), objtool (validación de objetos), mksysmap (generación de mapas de sistema) y el sistema de compilación de Rust. La propuesta, por tanto, no es un cambio puntual, sino una reescritura transversal para paralelizar tareas que antes bloqueaban el flujo.
FreeBSD porta el software ROCm de AMD para HPC e IA en GPU
La IA como «detective», no como programador
Parece sencillo de hacer, pero esto es un verdadero dolor de cabeza. Sin embargo, Stoakes no uso directamente a una IA que le solucionará mágicamente el problema, en su lugar, usó el modelo en dos fases. Primero, para localizar los cuellos de botella analizando el código y los logs de compilación, y después para explorar posibles soluciones.
El propio Stoakes lo resume con una franqueza poco habitual en su mensaje a la lista de kernel (LKML):
Un LLM se usó para determinar primero dónde estaban los cuellos de botella y luego para averiguar cómo mejorarlos. Generó mucho código, gran parte horrible. Audité y reescribí extensamente gran parte, y edité a fondo los mensajes de commit, la carta de presentación y los comentarios.
Además, el modelo también orquestó compilaciones de prueba, depuración y análisis, actuando casi como un agente de CI automatizado. Pero la validación final —tanto la corrección del código como la verificación de los kernels resultantes y las mejoras de rendimiento— fue completamente manual.
La etiqueta «Assisted-by»
Para dejar constancia del uso de IA, todos los commits incluyen una etiqueta Assisted-by. Este detalle que responde a un debate abierto en la comunidad del kernel sobre la transparencia en el uso de herramientas de IA.
En enero de 2026, Linus Torvalds ya intervino en la discusión sobre documentación de políticas para contribuciones asistidas por IA, señalando que «la gente que usa IA slop no va a documentar sus parches como tales». Stoakes, por su parte, ha defendido durante meses la necesidad de una política clara y de opt-in por parte de los mantenedores, argumentando que la carga de revisión recae sobre ellos y deben poder rechazar parches generados sin supervisión humana real.
Su posición quedó plasmada en el hilo «AI slop» de agosto de 2026, donde respondía a Jason Gunthorpe (NVIDIA) defendiendo el uso responsable de IA «con correa corta» y anticipando que la comunidad tendrá que moverse hacia un modelo de confianza donde los contribuyentes nuevos ganen credibilidad con cambios pequeños antes de proponer patches mayores.
5 distros Linux ultraligeras para resucitar tu viejo PC
El historial de Lorenzo Stoakes
Y quizás esa posición sea la que más sentido tiene, sobre todo por el perfil del propio Stoakes. Lorenzo Stoakes no es un aficionado, es co-mantenedor del subsistema de gestión de memoria (mm) del kernel de Linux, responsable de áreas críticas como el mapeo de memoria inverso (reverse mapping), las Transparent Huge Pages (THP) y las APIs de memoria del kernel. Lleva más de 20 años en desarrollo de sistemas: Oracle, WorldQuant, Squarepoint Capital, Imagination Technologies, y desde julio de 2026 en ARM trabajando en KVM y memoria central.
Ha hablado en Linux Plumbers Conference y en el prestigioso LSF/MM (Linux Storage, Filesystem, Memory Management & BPF), y es autor de un libro de referencia de 1.300 páginas sobre gestión de memoria en Linux (No Starch Press).
Un historial que deja claro que su credencial técnica es incuestionable, lo que da peso a su enfoque. Después de todo, Stoakes defiende que «la IA como herramienta de exploración, nunca como sustituto del juicio de ingeniería.»
¿Qué sigue para estos parches?
La serie está en revisión en la lista de kernel. Aún no hay garantía de que todos entren en mainline, pero el precedente metodológico ya está ahí: un mantenedor experimentado usa IA para acelerar el descubrimiento de problemas, rechaza su código «horrible», reescribe lo necesario, válida todo a mano y lo documenta con transparencia.
En un ecosistema donde la confianza se gana commit a commit, el caso de Stoakes ofrece una plantilla de cómo integrar IA sin romper las reglas de verificación que han sostenido al kernel durante tres décadas.
Después de todo, con estos cambios, la compilación de Linux acaba de volverse más rápida, algo que la mayoría de distros agradecerán y que posiblemente veamos repetido en otros desarrollos (ej: gcc cuyo boostrap puede tomar horas en determinado hardware). Y eso es algo que pueden aplaudir los desarrolladores, o quizás no.
Así es Hegotá, la gran actualización de Ethereum para la era poscuántica