AI in the Linux kernel: Torvalds' message and what it means for your company

The world's most important collaborative software project has just settled its stance on AI. In a heated discussion on the Linux kernel mailing list, Linus Torvalds declared he is willing to "put my foot down" in defense of using AI tools in the project, and sent a blunt message to those who disagree: "Linux is not one of those anti-AI projects, and if somebody has issues with that, they can do the open-source thing and fork it. Or just walk away."

The quote travels the world for its tone, but what matters to technology leaders is the context: the kernel discussion is no longer about WHETHER AI should take part in software development, but HOW to govern that participation. And the lessons apply to any organization.

What sparked the controversy

The trigger was Sashiko, an agentic code review system built for the Linux kernel. According to its maintainers, in tests the tool independently found 53.6% of the bugs that would later be fixed by humans in subsequent commits. The number is impressive, but it comes at a cost: the false positive rate, reports of bugs that do not exist, sits around 20%.

That cost is exactly what set the mailing list on fire. Maintainers questioned whether they should be subjected to a flood of automated bug reports, true or not. In the middle of the debate, a reference to the Software Freedom Conservancy, arguing that the community should "support, not just tolerate" those who reject generative AI systems, led Torvalds to draw his line: nobody is forced to use the tools, but he will "very loudly ignore" anyone trying to stop others from using them.

Technical merit, not fear (nor hype)

Torvalds' central argument deserves attention: his position is "based on technical merit. Not fear of new tools." For the creator of Linux, "AI is a tool, just like other tools we use. And it's clearly a useful one. It may not have been that 'clearly' even just a year ago, but it's no longer in question today."

The honest counterpoint is that measuring that merit is harder than it looks. A METR study became famous for showing that, in 2025, open source developers using AI were 19% LESS productive, while feeling 20% more productive. The research update in early 2026 suggests real gains have likely turned the tide, but the lesson stands: perceived productivity is not productivity. Anyone adopting AI in development needs to measure the actual effect, with flow, quality and rework metrics, not opinion surveys.

Torvalds also calibrated expectations in both directions. While admitting that "AI isn't perfect," he returned the criticism: those who point at AI's problems "had better be looking in the mirror and pointing at themselves at the same time," because natural intelligence gets things wrong too. Any engineering leader who has ever reviewed a Friday hotfix knows exactly what he means.

The risks this case exposes (and that your team will face)

The kernel discussion is an early portrait of what companies face when adopting AI in the development cycle:

• Alert fatigue. An agent that finds half the bugs but generates 20% false positives shifts cost to the human who reviews. It is the same dilemma as SOCs drowning in alerts: without smart triage and noise suppression, the tool becomes a source of exhaustion, not safety.
• Prompt injection in the supply chain. The article recalls the case of the Java library jqwik, whose developer hid a malicious instruction in the project so that "vibe coding" bots would delete tests and code. Agents that read third-party repositories need guardrails against embedded instructions, exactly as we treat untrusted input in any application.
• Intellectual property. The community raised a real legal question: LLM-generated code, without substantial human contribution, may not be protected by copyright, with implications for licenses like the GPL. In companies, the equivalent question is contractual: who is accountable for the code AI wrote into your product?

How to put this into practice without repeating the kernel fight

The answer that works is neither banning nor a free-for-all: it is governance. In practice, that means four moves:

1. An explicit policy for AI use in development, defining where AI can act (generation, review, testing), what requires mandatory human review and how to record the origin of code.
2. Technical guardrails for agents, with limited scope and permissions, protection against prompt injection and an audit trail of every action, principles we apply in Intelliway's AI governance (AI Trust) projects.
3. Architecture before tooling. As we showed in our article on AI pentesting, what separates a useful agent from a noise generator is the engineering around it: triage, validation and course correction. That is our AI Factory approach when building custom agents, from development to the SOC.
4. Honest measurement, with productivity and quality indicators defined before adoption, so the feeling of speed is not mistaken for results.

Torvalds' message, at its core, is about pragmatism: AI has entered the software development flow of the entire world, including the project that runs on virtually every server on the planet. The choice left for companies and communities is the same: govern that entry well, or spend energy on a dispute the creator of Linux has already declared over.

Want to adopt AI in your development cycle with governance, guardrails and measured results? Talk to our team and get to know Intelliway's AI Trust and AI Factory work.