AI helped a Linux developer find bottlenecks in the kernel, but the code it made to fix it was "hideous"

Published Sep 9, 2026, 12:29 AM EDT Simon is a Computer Science BSc graduate who has been writing about technology since 2014, and using Windows machines since 3.1. After working for an indie game studio and acting as the family's go-to technician for all computer issues, he found his passion for writing and decided to use his skill set to write about all things tech. Since beginning his writing career, he has written for many different publications such as WorldStart, Listverse, and MakeTechEasier. However, after finding his home at MakeUseOf in February 2019, he would eventually move on to its sister site, XDA, to bring the latest and greatest in Windows, Linux, and DIY electronics. Sign in to your XDA account Summary LLMs are great at finding Linux kernel bottlenecks but not reliable at producing clean fixes. Generated fixes were 'hideous' and required extensive auditing, rewrites, and message edits. Build times improved dramatically: allmodconfig +36%, incremental ~70%, noop ~90% faster. It has been a very interesting time in the world of Linux, and whether that's a good thing or not depends on your stance on LLM usage. Very recently, we saw Linus Torvalds fix a bug using AI, and Debian maintainers voted to allow LLM code submissions as long as the submitter takes all of the responsibility. Now, a developer for the kernel has reported that they used an LLM to locate a nasty bottleneck bug, but it turns out the AI was a far better spotter than it was a fixer. An LLM helped find a Linux kernel bug, but wasn't much help fixing it Its code required a lot of reworking before it was ready As spotted by Phoronix, Linux developer Lorenzo Stoakes of Arm sent an email detailing their work on the kernel. It turns out several single-threaded bottlenecks made building the kernel more arduous than it needed to be, so Stoakes set out to fix them. To help them with their quest, Stoakes used the aid of an LLM, which turns out was far better at finding the problem than actually fixing it: "An LLM was used to first determine where the bottlenecks were then to figure out how to improve them. It generated a lot of code, much of it hideous. I extensively audited and rewrote a lot of it, and heavily edited commit messages, the cover letter and comments." The good news is, despite the AI's 'hideous' code, the bottlenecks have now been fixed. Stoakes reports that "allmodconfig builds up to 36% faster, incremental builds up to ~70% faster, and noop builds up to ~90% faster," with noticeable speed improvements regardless of which device he used. And while the AI handled build runs and debugging, Stoakes did all of the final checks themselves. Stoakes' findings go hand-in-hand with what Linus Torvalds himself noticed with recent trends around kernel development. LLMs are getting a lot better at spotting bugs, and Linux kernel maintainers are being inundated with reports of small issues that a human may not ever have noticed. However, it seems it'll still be a while until an LLM becomes a worthy contributor of code by itself.