An LLM Made 2013 Code Legible—and Found More Bugs
Nils Ollrogge, a diligent developer, recently reported a bug within the Linux kernel’s assoc_array implementation. Even Linus Torvalds himself admitted the code was "too obscure" to follow, a frank admission from the creator of Linux. TN/A complexity set the stage for an unexpected AI intervention.
Torvalds, ever pragmatic, turned to a modern LLM to untangle the convoluted code. He tasked the AI with breaking down opaque functions into readable, manageable components. The clarified output then underwent rigorous testing within a user-space harness, proving the LLM’s utility as a powerful analytical aid.
TN/A process not only confirmed Ollrogge’s original bug but also unearthed three additional, long-standing defects. These hidden issues traced directly back to the assoc_array library’s initial 2013 commit. The LLM, therefore, functioned not as an autonomous bug-fixer, but as an investigative partner, significantly enhancing Torvalds’ ability to understand and audit complex, legacy code.
The Kernel’s AI Patch Flood Has a Human Cost
Torvalds’ newfound appreciation for AI tools, however, doesn’t extend to the indiscriminate flood of AI-generated submissions currently overwhelming the Linux kernel. At the recent maintainers summit in Prague, contributors and maintainers grappled with a surging tide of patches, notably from nearly 800 first-time contributors in Linux 7.3 alone. TN/A influx points to a growing problem: the human cost of AI-assisted development.
Official figures show about 1,800 of 18,500 changes in Linux 7.3 carried an Assisted-by tag, a mere 10% of total submissions. Yet, maintainers estimate actual LLM usage is far higher, perhaps 90%. These are estimates, not a precise audit, but they highlight a significant disconnect between transparency and practice.
The real pressure isn't the tool itself, but its poor application. Low-quality or poorly understood patches consume scarce reviewer time, diverting it from crucial development. Torvalds’ acceptance of AI for personal use does not endorse a spam-like submission strategy. As he bluntly stated, maintainers expect competence and understanding, regardless of the tools used.
Why Torvalds Says Tool Bans Are “Utterly Stupid”
The proposed removal of the Assisted-by: tag sparked heated debate, exposing a fundamental disagreement over disclosure and accountability. Maintainers worried about losing guardrails, fearing an influx of unvetted AI-generated code. Yet, the reality was stark: only ~1,800 out of ~18,500 non-merge commits in Linux 7.3 carried the tag, while estimates suggested 90% of contributors used LLMs.
Linus Torvalds, predictably, called tool bans ""utterly stupid"." He dismantled the disclosure argument with potent analogies: "Here's a new rule for you: don't use compilers for any of your kernel submissions." He extended the logic to text editors, arguing that tools, whether compilers or LLMs, don't inherently prove or disprove a contributor's understanding.
Torvalds’ core point is clear: tool choice is irrelevant; responsibility is paramount. A contributor still must verify their code, answer reviewers, and accept full responsibility under the kernel’s submission process. The system demands competence and ownership, not a declaration of software preferences. For further discussion on kernel governance, see The 2026 Maintainers Summit.
Enjoying this? Get one like it in your inbox each morning.
one email a day · unsubscribe in two clicks · no third-party tracking
The Rule That Still Matters: Own Every Line
Dropping a hard-to-enforce disclosure tag might reduce paperwork, but it creates a governance trade-off. Maintainers still need effective review processes and clear accountability from contributors, even as the formal requirement for Assisted-by: fades.
The critical distinction isn't whether a tool was used, but how. AI-assisted development, where a human author can explain, validate, and revise a contribution, stands in stark contrast to blind copy-pasting or automated patch spam. Torvalds' own use of an LLM to clarify assoc_array code, then running it through a test harness to find three hidden bugs dating back to 2013, exemplifies responsible tool integration.
TN/A brings us to the core takeaway for open source: judge submissions by evidence, correctness, and contributor responsibility, not by the toolchain. While projects may weigh provenance and licensing risks differently, the ultimate test remains the human author’s ownership. Every line submitted still demands a competent, accountable human behind it.
Frequently Asked Questions
What did the LLM help Linus Torvalds discover?
After Torvalds used an LLM to make Linux’s assoc_array code easier to understand and test, the work confirmed a reported bug and surfaced three additional bugs dating to 2013.
Is AI-generated code banned in the Linux kernel?
The discussion described here is about dropping a required Assisted-by disclosure tag, not banning AI use. Contributors remain responsible for the code they submit.
Why did Linux consider removing the Assisted-by tag?
Supporters argued that the tag was rarely used and difficult to enforce, while critics worried that dropping it could weaken safeguards against unreviewed AI-generated patches.
What is Torvalds’ main argument about AI coding tools?
He argues that maintainers should judge whether a contributor understands and stands behind the code, rather than police which tools helped produce it.