Linus Torvalds, the creator of Linux, says he now likes AI. At Open Source Summit Europe in Prague, in a conversation with Dirk Hohndel, he said: "I actually really like using AI." He also drew a clear line between using it for fun and using it on something that matters. ZDNet's Steven J. Vaughan-Nichols reported the talk on October 9, 2026.
Because Torvalds is among the most-cited voices in open source, his remarks tend to be quoted in both pro-AI and anti-AI arguments. This post lays out what he actually said, what is happening with AI in the kernel according to the same report, and what it means for developers and maintainers. The source is ZDNet's write-up of the Open Source Summit Europe session. We did not attend, so quotes below are as ZDNet reported them.
TL;DR: what Torvalds said
| Topic | What he said, as reported |
|---|---|
| Overall view | He used to think AI programming "was just not very good," but now "actually really likes using AI." |
| Best use | A tool, used correctly; it makes programming "much more enjoyable." |
| Vibe coding | "A wonderful way to find joy in programming," especially for newcomers. |
| His example | A guitar-pedal hobby project: C firmware he knew, a user interface in Java he did not. |
| Caution | "You need to be very careful using AI when you're doing something real and important." |
| Kernel review | Agentic review output now appears on the kernel mailing list; some maintainers require it. |
| Cost | AI is improving the code base but "stressing maintainers out to the point that it's a problem." |
"I use AI to do the things that I'm bad at"
The headline quote comes from his guitar-pedal project. ZDNet reports that Torvalds had written a user interface in C running on a microcontroller with a small screen, and knew what he was doing, but thought it looked like something from the 1980s. He wanted a modern look, but, as he put it, "I don't do Java. I do kernels."
So he gave an AI a prompt, and the first result, in his words, was "horrendous." He then pointed out that he had already built the interface in C the right way and it was just ugly. His summary: "I use AI to do the things that I'm bad at."
The detail worth keeping is that he was not asking AI to replace an expert skill of his own. He was asking it to fill a gap outside his specialty, then judging the result against a working version he understood. That is a very different workflow from handing an unfamiliar system to a model and trusting the output.
A small shape riding a soft green wave, representing vibe coding as a way for newcomers to enjoy building software
Why he defends vibe coding for beginners
Torvalds started programming around 1981, when computers were simpler and the programs you compared yours with were simpler too. Today, he said, "the bar in software engineering has grown so high that it's hard to see your own small efforts as worth anything, because you're used to all these polished, professional programs."
His answer is generous toward newcomers: "A lot of people make fun of vibe coding, but I think it's a wonderful way to find joy in programming. It makes you feel like you're doing something relevant. It allows you, as a new programmer, to do things that you would otherwise have a really hard time with." He called the idea of AI as a "gateway drug" appealing.
He also qualified his own role. He said he does not do a lot of kernel programming; he is a maintainer, and the kernel is a project where "other people do the real work." So his enthusiasm comes from a hobbyist side project and from a vantage point of reviewing others' work, not from writing kernel code with a model.
For readers learning to program, the practical reading is that a famous skeptic-turned-user sees value in AI for motivation and for getting past the blank page. We have covered the same dynamic from other angles, including Karpathy on discardable software artifacts and Ethan Mollick on AI taking over annoying tasks.
What AI is doing in the Linux kernel
Hohndel asked about Sashiko, which ZDNet describes as an agentic Linux kernel code review system. Torvalds said its public reviews now appear on the Linux Kernel Mailing List. Some subsystem maintainers expect patches to have received such a review before they accept them. That does not mean every pull request must go through AI review; some maintainers require it, and the reporter says it seems likely all will eventually.
Torvalds said AI tools can identify genuine security problems and also surface issues in old drivers that have gone unnoticed for years. He sees value in the resulting fixes: "It is, I think, improving our code base… Although it is also stressing maintainers out to the point that it's a problem."
He added that three-quarters of the previous day's Linux Kernel Maintainer Summit discussion concerned making AI generation and review less stressful and more useful. The reporter's framing is that the bottleneck is not getting patches; it is getting useful work through review without exhausting the people responsible for it.
A magnifying lens inspecting a single replacement tile in a mosaic, representing AI-assisted review of individual kernel patches
The cost side: fabricated reports and band-aid patches
ZDNet points back to remarks Torvalds made in Mumbai earlier this year. Convincing but fabricated bug reports can take substantial human effort to disprove, and narrowly targeted patches may fix one symptom without addressing the underlying problem. He called some submissions "mindless band-aid kind of patches."
That matches what other projects are reporting. System76 recently banned AI-generated contributions from its COSMIC desktop, as we covered in COSMIC bans AI-generated code, and Google froze parts of its open-source bug bounty after a flood of low-quality submissions, covered in Google's OSS VRP freeze. On the other side, Anthropic launched free AI vulnerability scans for open-source maintainers. The tension in all of these is the same one Torvalds describes: AI makes finding problems cheap and reviewing them still costs scarce human attention.
For pull-request hygiene in agent-assisted projects, see our AnyPS5 case study.
The rest of the talk: why "incremental" still rules Linux
The AI comments came inside a broader look back for Linux's 35th anniversary, and they read differently in that context. Torvalds recalled that in the early days Linux had no development infrastructure to speak of: he tracked changes through tarball patches, made patches daily and released at least weekly, "just me, myself, and my computer." That worked until the project outgrew manual patch handling, and the BitKeeper version control system, despite its proprietary licence dividing the community, showed him what distributed source control could do. When a 2005 licensing dispute took it away, he wrote Git. Hohndel recalled the first working version took 11 days.
Torvalds also described the move from long-lived separate stable and development trees to frequent releases with a merge window and release candidates. He proposed a dramatically shorter cycle and "people looked at me like I had grown a third head." The process settled into the nine-to-ten-week rhythm still used. He rejected organizing Linux around dramatic launches: "I'm a big believer in the whole incremental small changes that, over time, turn into big features."
That philosophy explains his stance on AI. He is comfortable with a tool that makes small, checkable contributions, such as a review comment on a patch or a bug found in an old driver, because those fit a process built on small steps and human review. He is wary of anything that floods that process faster than people can absorb it. The same reasoning applies outside the kernel: AI tools are easiest to adopt where changes are small, reviewable and reversible, and hardest where a single large generated change has to be trusted whole.
What this means if you build or maintain software
- Use AI where you are weakest, and verify against something you understand. Torvalds had a working C version to compare with. Give yourself a reference.
- Match the care to the stakes. His distinction between a hobby project and "something real and important" is a usable rule: more review, tests and human sign-off as the blast radius grows.
- Maintainers: expect volume. Decide in advance how you will treat AI-generated reports and patches, such as requiring a reproduction, a test and a disclosure of tooling.
- Contributors: do the human work first. A report you cannot reproduce, or a patch that silences a symptom, costs maintainers more than it helps.
- Beginners: it is fine to enjoy it. The founder of Linux endorses vibe coding as a gateway, provided you stay aware of its limits.
What is not established
- ZDNet's report is a summary of a stage conversation; we have not seen the full recording.
- It does not say how many kernel patches have had AI review or what share of AI-found bugs were real.
- Torvalds' comments on Sashiko were brief; details of its design and accuracy are not in the article.
- His views are his own; the kernel project has no single AI policy stated in this report.
Details reflect ZDNet's October 9, 2026 reporting and may change.