The code generated by Large Language Models does not need to be elegant to be useful. A case in point comes from an ARM engineer working on the Linux kernel: to reduce compilation times, they used LLMs as an exploration tool rather than as a replacement for the programmer. The results point to a significant speed-up of builds, achieved by increasing task parallelization in different areas of the process. The catch is that, along the way, the model generated a lot of code, much of it hideous.

The point is not the aesthetic quality of the output. Linux kernel compilation is a complex process, with many cross dependencies and parallelization margins that are not always visible. Finding bottlenecks does not mean writing better code: it means understanding where the process stalls and how to reorganize the work. LLMs, with their ability to generate variants and patterns, can act as a heuristic for exploring that optimization space. Even ugly solutions become useful data: they show what does not work or, by contrast, where a different approach can free resources.

This story flips a common narrative. On one side, some judge LLMs only by the syntactic quality of the code they produce. On the other, some use them to generate commits. Here the value is in the middle: the LLM as a system analyzer. Instead of aiming for a single correct output, the model produces a range of attempts that the engineer can discard or refine. The final result is a change to the build process, not an uncritical adoption of the generated code.

For those managing local infrastructure, the message is relevant. Kernel builds do not happen only in the cloud servers of big vendors. They also happen in self-hosted environments, development labs, and continuous integration pipelines. Every hour saved in compilation translates into lower CPU occupancy, faster iterations, and, over time, a lower TCO. There is no need to add hardware if you first learn to make better use of what already exists.

The ARM case shows that LLMs can be diagnostic tools for complex systems, not just text generators. The fact that they produce hideous code is not a flaw if their role is to propose hypotheses to verify. The open question is whether future tools for system optimization will integrate this capability natively, or whether it will remain an art for engineers willing to look beyond the quality of a single snippet.