See why Linus Torvalds welcomes AI tools like GitHub Copilot in Linux, and what his mailing-list warning means for teams managing AI-generated code output.
Linus Torvalds, the founder of the Linux kernel, has told senior kernel engineer Roman Gushchin that AI tools remain welcome in Linux development, despite the extra workload they create for maintainers. In an email archived at Kernel.org, reported by Computerworld on 17 July 2026, Torvalds wrote that "Linux is not one of those anti-AI projects."
The remark lands weeks after Torvalds complained that a "continued flood" of AI-generated vulnerability reports had made the Linux kernel security mailing list "almost entirely unmanageable." Read together, the two positions describe a maintainer wrestling with the same tool from two directions — welcoming what AI coding tools can surface, while absorbing the triage cost of sorting genuine issues from noise.
Why a flood of AI bug reports nearly broke the kernel mailing list
Automated scanning tools, many built on large language models, have been pointed at the Linux kernel's codebase for months, generating vulnerability reports at a volume no human review queue was designed to absorb. Torvalds's earlier frustration was specific: it was not that the tools found nothing real, but that maintainers had to wade through a disproportionate amount of chaff to find the wheat.
That is the friction point most open source projects are now hitting. AI coding tools are cheap to run at scale, so the volume of automated output — pull requests, static-analysis findings, security reports — grows far faster than the volunteer or paid maintainer capacity available to review it. Gushchin's exchange with Torvalds sits directly inside that tension.
What changed Torvalds's tone on AI in open source
Despite that frustration, Torvalds's message to Gushchin draws a line between the technology and how it is deployed. "It can also be a somewhat painful tool, both for maintainer workloads and just from a 'it keeps finding embarrassing bugs' standpoint," he wrote of AI in security scanning. His conclusion was not to restrict AI use but to redirect it: "The solution is to make sure those LLM tools help maintainers instead of just causing them pain."
He also drew a boundary around individual choice. "We're not forcing anybody to use it, but I will very loudly ignore people who try to argue against other people from using it," Torvalds said, positioning AI adoption in kernel development as an opt-in decision for individual contributors rather than a project-wide mandate.
The position is consistent with comments Torvalds made around the same period, in which he credited AI tools with the potential to lift programmer productivity by a factor of ten — a claim that sits uneasily alongside his complaint about unmanageable mailing lists, but one that captures the trade-off many engineering teams are now living with.
The gap between raw AI output and usable AI output
Torvalds's dual position — AI is useful, AI is painful, the difference is implementation — maps onto a wider pattern showing up across commercial software teams too. Tools such as GitHub Copilot have moved AI-assisted coding from a novelty into a default part of many developers' workflow, generating code suggestions, tests, and now increasingly automated reviews and security scans. The same dynamic Torvalds describes in the kernel community — more output, more noise, more triage — shows up wherever AI coding tools are switched on without a corresponding change to how that output gets reviewed.
| | Traditional manual review | Unmanaged AI-generated output | AI output with a triage workflow | |---|---|---|---| | Volume of reports/PRs | Low, human-paced | High, machine-paced | High, but pre-sorted | | Maintainer effort per item | Consistent | Rises sharply (signal buried in noise) | Falls (low-confidence items filtered before reaching humans) | | Risk of missed genuine bugs | Moderate (limited coverage) | Low coverage risk, high false-positive cost | Lower on both counts | | Contributor experience | Slow but predictable | Frustrating, adversarial | Faster, still human-governed |
The rightmost column is the outcome Torvalds says he wants: AI that helps maintainers rather than burying them. It is also the outcome that separates organisations getting genuine value from AI coding tools from those simply generating more volume for someone else to sort.
What the kernel community's experiment tells other software teams
Linux's position is notable because it is one of the most scrutinised, security-sensitive codebases in the world, maintained largely by volunteers with finite review bandwidth. If AI-generated security findings can overwhelm that community's process, the same imbalance is plausible inside any commercial engineering team running AI coding tools against a legacy codebase without a matching change to review capacity or process design.
Torvalds's stance — permissive on adoption, blunt about the operational cost — is a useful data point for any organisation currently deciding how far to open AI coding tools to its own developers. The open question, which Torvalds's email does not resolve, is whether Linux's maintainer community can build a triage layer fast enough to keep pace with the tools it has decided not to ban.
Diagnostics
Engineering leaders watching this debate are asking themselves a few pointed questions before deciding how far to extend AI coding tools inside their own teams:
Where in our review pipeline would an AI-generated flood of output — bug reports, pull requests, or security findings — currently get stuck, and who would be stuck sorting it?
Do we have a documented process for filtering AI output before it reaches a senior reviewer, or are we relying on individual judgement each time?
If AI tooling lifted our developers' raw output tenfold, as Torvalds suggested it can, would our current review capacity absorb that increase without becoming the new bottleneck?
