An ARM engineer let an AI generate hideous code and found a 70% speedup in the Linux kernel build

Lorenzo Stoakes at ARM put an LLM to work on the Linux kernel build system (kbuild) and got two things out of it: a lot of code he himself described as “hideous,” and a second revision of patches that cut allmodconfig build times by 36% and incremental builds by 70%. The v2 series hit the mailing list this week. The target is the Linux 7.4 merge window.

Those are not rounding-error improvements. Kernel developers run incremental builds constantly. Seventy percent of the waiting, gone.

What was actually serial

The kernel build has had parallel compilation since the beginning, or close enough to it. You pass -j$(nproc) and the compiler fans out. That part works. The problem was in the phases before compilation: dependency resolution, header scanning, the Makefile machinery that figures out what needs building before anything gets built. Those phases had single-threaded bottlenecks that nobody had gotten around to fixing because the compiler phase dominates the perceived cost.

Stoakes used the LLM to generate candidate implementations of parallel versions of these phases. Most of what came out was unusable. His description was “hideous.” But the generated code served a different purpose: it mapped the critical path by showing which operations the AI thought could be parallelized and, by inference, which ones could not. Once the bottlenecks had names, Stoakes wrote the actual fixes.

That is a defensible use of an LLM. Not as a code generator whose output lands on the mailing list, but as a search over the space of “what if we did this differently” that produces signal even when it produces garbage. The garbage goes in the bin. The signal goes into a clean patch series.

Why this is different from the August flood

In August the Linux 7.2 merge window saw a wave of AI-assisted patches: comment rewrites, spelling fixes, style cleanups, whole-file reformats, all generated or assisted by LLMs and queued by maintainers. Linus had public opinions about it. The legitimate concern was that maintainer review bandwidth was being spent on noise dressed up as maintenance.

None of the hideous kbuild code from Stoakes’s experiment appeared on the mailing list. The AI output was scaffolding, not a submission. The patches Stoakes actually sent are clean enough that they are being taken seriously for a near-term merge window. That is the distinction: using AI to find the problem, versus using AI to generate the fix and submitting both.

The Linux 7.3 merge window is still in its RC cycle. The 7.4 merge window is weeks out. kbuild changes touch infrastructure that almost everything in the build system depends on, so the review bar is appropriately high.

What 70% actually means

On a machine with 32 cores running a full kernel development workflow, incremental build times are already short in absolute terms. A two-minute incremental build becoming 36 seconds is not the headline. The headline is what happens at scale: CI pipelines running hundreds of builds a day, developer machines rebuilding after a header change that touches half the tree, kernel distributions rebuilding on each stable point release.

The 70% incremental improvement is also the number that compounds. A single developer working on a subsystem does not care much about allmodconfig, but they rebuild constantly while iterating on a patch. Cut that by 70% and you change how people work, not just how long they wait.

Rod does not build the Linux kernel. He builds FreeBSD ports on iron that has had the same make.conf since before systemd was a noun. But waiting for a build is waiting for a build regardless of what you are compiling, and finding that seventy percent of the wait was unnecessary parallelism nobody had gotten around to fixing is the kind of thing that should have happened sooner. It did not happen sooner because profiling kbuild is unglamorous work and nobody wanted to do it.

An ARM engineer and a language model found time for the unglamorous work. The results are real. I reserve the right to remain skeptical of every other LLM-assisted kernel patch series that lands in my inbox for the next year, but this one earned the benchmark numbers it is carrying.