The most watched thing Linus Torvalds does isn't write code any more. It's say things. When he posts to the Linux kernel mailing list or sits down for an interview at a major conference, the technical community listens. Not because he's a thought leader in the TED Talk sense. Because he still runs the most important software project on the planet, and what he permits or prohibits shapes how tens of thousands of contributors work.
So when Torvalds stepped on stage at Open Source Summit North America this year and declared that Linux is "not one of those anti-AI projects," it wasn't a vibe statement. It was a policy decision with actual consequences. And it's worth reading carefully, because the nuances in what he said contain some hard-edged points that most of the breathless coverage glossed over.
What Actually Happened
At Open Source Summit NA in May, Torvalds was interviewed onstage by Dirk Hohndel, a longtime collaborator. The AI question came up, as it always does now. But his answer was sharper than the usual hedging you get from open source figures trying not to alienate anyone.
He was direct: "Linux is not one of those anti-AI projects." The project isn't going to ban AI tools, isn't going to require contributors to disclose when they used a coding assistant, and isn't going to treat AI-generated code as categorically suspect. The question of whether AI tools are useful, he said, is no longer up for debate. It's been settled by the data.
What is the data? The kernel has seen roughly 20% more commits across recent releases compared to previous norms. Lowered barriers to contribution are the most plausible driver, with AI coding tools helping developers who might have been put off by the complexity of kernel submission standards actually get patches over the line.
That sounds good. Here's the other side.
The same AI wave that boosted commit volume also overwhelmed the kernel's security vulnerability disclosure list. Researchers using AI tools to hunt for bugs found lots of them. Sometimes the same bugs, independently, multiple times. The security list became, in Torvalds' words, "almost entirely unmanageable." The kernel team had to update their security documentation to change how AI-discovered vulnerabilities are handled. The new policy: because multiple people probably find the same AI-surfaced flaw simultaneously, those bugs should be treated as public rather than under embargo from the start. You disclose the bug, but you don't disclose how to exploit it.
That's a meaningful policy shift, and it's entirely downstream of what AI tooling changed about how vulnerability research gets done.
Torvalds also set out his personal position without much ambiguity: "I have a love-hate relationship with AI. I actually really like it from a technical angle, I love the tools, I find it very useful and interesting, but it is definitely causing pain points."
On the political side, he was equally clear. No one is forced to use AI tools, but he will "very loudly ignore people who try to argue against other people from using it." The project is, he insisted, "about the technology." Ideological opposition to AI tooling is not going to carry weight in patch reviews. "The kernel project has been and will continue to be about the technology," he said, specifically pushing back against any characterisation of Linux as a "social warrior" project.
Why This Matters
The Linux kernel debate has played out in miniature in every engineering team trying to work out its AI policy over the last couple of years. Does code generation mean lower quality? Does it matter how a patch was written if it's technically correct? Who's accountable when AI-generated code ships a bug?
Torvalds' answer to the last question is the most important thing he said. He drew a direct line between AI-assisted development and the fundamental requirement of the kernel project: every patch needs a human who can explain it, maintain it, and own it. That rule doesn't disappear because you used Copilot to generate the code. The person who submits the patch is still responsible for understanding it.
He put it this way: developers maintaining long-term projects "need to understand not just your prompts, but your end result." That's a compact statement of a principle a lot of engineering teams haven't fully absorbed yet. AI coding tools are productivity multipliers, not substitute engineers. You still need someone who can answer "why does this function do this?" three months after the commit lands.
The comparison he drew to compilers is instructive. "Compilers increase your productivity by a factor of a thousand. So AI is great, but AI is not changing programming." What he means is that the cognitive work of understanding what you want to build, what constraints it has to respect, and what breaking it would look like, that work hasn't changed. The tooling to express that understanding has just got faster.
The commit volume increase is real, then, but its value depends entirely on the quality of human oversight applied to those commits. The security list chaos is what you get when AI-generated output flows in without that oversight. More noise, not more signal. The tool lowers the barrier to finding things; it doesn't automatically lower the barrier to reasoning about them clearly.
What Isn't Proven Yet
The policy is clear. The practice is harder.
Torvalds can say that "AI slop" (low-effort, machine-generated patches submitted without proper review or understanding) is banned. But policing that at scale across tens of thousands of contributors is a different problem. The current enforcement mechanism is largely social: experienced maintainers reject patches they judge to be AI-generated without genuine human understanding behind them. That works when maintainers have capacity and can spot the signals. It doesn't obviously scale if commit rates keep climbing at 20% above historical norms.
The security list situation already showed the shape of the real friction. AI tools lowered the barrier to finding bugs; they didn't lower the barrier to communicating about them intelligently. Duplicate reports, poorly framed disclosures, volume problems, all of that required policy overhead that didn't exist before. It'll require more as the tools improve.
There's also a question the interviews didn't resolve: what happens when AI tools get capable enough that the "human who understands the code" test gets genuinely hard to apply? Right now a skilled maintainer can usually tell whether a contributor actually understands a patch. In two or three years, that test may be significantly more difficult to run reliably. Torvalds is setting policy for the current generation of tools. The next generation may require different rules entirely.
Where Dakik Fits In
Here's what this means for a product team trying to make practical decisions right now.
The Torvalds position establishes something important: AI-assisted development is legitimate, but the accountability structure doesn't change. Someone still owns the code. That person needs to understand it. The question for your team is how to get the productivity benefit without eroding the accountability that makes software maintainable over time.
The teams that get this right aren't the ones who hand developers a generic Copilot subscription and call it a strategy. They're the ones who build AI tooling that's specific to their codebase, their standards, and their review process. A generic LLM knows every codebase in the abstract. It doesn't know yours.
That's a concrete project you could commission. What we'd build: a codebase-aware AI assistant using a RAG pipeline over your actual code, documentation, and pull request history, indexed with Qdrant so the vector search respects the structure of your repo rather than treating it as a flat blob of text. On top of that, an agent layer that can answer "does this proposed change violate any of our existing patterns?", "what's the blast radius if this function changes?", "which tests cover this path?" The answers come from your codebase, not a generic model trained on everyone's code.
The result is a tool that makes your developers faster in precisely the way Torvalds describes, useful and interesting, while reinforcing rather than undermining the human accountability standard he's also insisting on. The AI gives you a first pass. The developer still owns the output. The system makes that review faster, not optional.
We've built this stack for clients in Angular and Next.js frontends with Node and .NET backends. The indexing pipeline, the retrieval layer, the agent routing logic. It's typically a six-to-ten-week engagement depending on codebase complexity, and you end up with something that knows your codebase rather than the internet's. That's a meaningfully different product.
If the world's most experienced kernel maintainer is telling his contributors to embrace AI tools while holding the line on human accountability, the answer for your team isn't to wait and see. It's to build the infrastructure that makes both things possible at once.
The Linux kernel is moving faster because of AI. Your product should be too, and for the same reason: not because the technology is doing the thinking, but because it's giving your engineers more leverage over the thinking they were already doing.