Linus Torvalds: "I actually really like using AI" — with limits

Linus Torvalds told the Open Source Summit Europe in Prague: "I actually really like using AI." The comment, made in conversation with Dirk Hohndel, head of Ericsson Software Technology, cuts against the prevailing mood in open-source circles — the same week System76 banned AI-generated content from its COSMIC desktop.

The Linux creator's enthusiasm comes with a sharp distinction. AI as a hobby-project accelerant is fine. AI in production kernel work, where generated patches and fabricated bug reports can bury maintainers, demands caution. "I think that you need to be very careful using AI when you're doing something real and important," Torvalds said.

The stakes are considerable. The Linux kernel underpins most of the internet's infrastructure and every major cloud platform, and its maintainer community — the humans who review and merge code — is a finite resource. If AI-generated submissions exhaust that resource faster than they improve the code, the economics of the world's largest collaborative software project change for the worse.

Why does Torvalds like AI for beginners?

Torvalds draws on his own history to explain his position. "I started programming in 1981 or so, and back then computers were much simpler, and you could understand what they were doing, and also the programs you compared your own programs to were much simpler," he recalled.

The contrast with today is stark. "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," he said.

That gap, in his view, is where AI helps most. "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," Torvalds said.

He frames this as a pipeline issue for the ecosystem: new developers who experience early success are more likely to stick with programming and eventually contribute at a professional level.

How does Torvalds himself use AI?

Torvalds offered a concrete example: a toy guitar pedal project. He had written the user interface himself in C, running on a microcontroller with a small screen, and judged the result ugly.

"I love the concept of AI as a gateway drug because I was working on my own toy project, the guitar pedal, and I knew what I was doing. I had a user interface that I had written myself in C that was running on a microcontroller that was running on this small screen, and I was like, 'This is just stupid. It looks like something from the '80s; I wanted it to look like something from this century. But I don't do Java. I do kernels,'" he said.

His approach was pragmatic. "So, I use AI to do the things that I'm bad at," Torvalds said. "I'd seen all the same YouTube videos you have. Give AI a prompt, and it will do it. So I gave it a prompt, and it did it, and it was horrendous. Then I said, 'Hey, look! I already did this in C. I did it the right way. It's just ugly.'"

He clarified his own role in the kernel today: "To be fair, I don't do a lot of kernel programming. I'm a maintainer. The Linux kernel is a project where other people do the real work, and I act as the collection point. But I still enjoy programming immensely. I think AI is a wonderful tool if you use it correctly and treat it as a tool, and I find it makes programming much more enjoyable."

What role does AI play in the Linux kernel itself?

AI has already become a working component of kernel development, not just a topic of debate. Hohndel asked about Sashiko, an agentic Linux kernel code review system. Torvalds confirmed its public reviews now appear on the Linux Kernel Mailing List (LKML), and some subsystem maintainers now expect patches to have received such a review before accepting them.

Not every pull request must pass an AI review today. Some maintainers require it, and Torvalds considers it likely that all eventually will.

The tools deliver real value. They can identify genuine security problems and surface issues in old, no-longer-used drivers that have gone unnoticed for years. Torvalds sees worth in the resulting fixes — while acknowledging their price. "It is, I think, improving our code base… Although it is also stressing maintainers out to the point that it's a problem," he said.

What are the costs of AI-generated patches?

The burden falls into two categories, both of which Torvalds flagged in Mumbai earlier this year and reiterated in Prague:

• Convincing but fabricated bug reports can require substantial human effort to disprove.
• Narrowly targeted patches may fix one symptom without addressing the underlying problem — submissions Torvalds has called "mindless band-aid kind of patches."

The scale of the issue dominated the industry's most senior kernel gathering. Torvalds said three-quarters of the preceding day's Linux Kernel Maintainer Summit discussion concerned making AI generation and review less stressful and more useful. The bottleneck is no longer producing patches. It is getting useful work through review without exhausting the people responsible for it.

AI code checking is nonetheless permanent, in his assessment. The open question is process design, not adoption.

How has kernel development changed over 35 years?

Because this year marks Linux's 35th anniversary, Torvalds also traced how the project's development machinery evolved.

In the beginning, there was none. Torvalds tracked changes through tarball patches and regularly distributed updated source code. "I made patches every single day internally, and I released them at least weekly," he recalled. "And it actually worked surprisingly well for a small project."

That model persisted until 2002. "It was really just me, myself, and my computer," Torvalds said of the early period.

His resistance to existing source-control tools was deliberate. He wanted developers working independently, in their own local environments. "I really felt very strongly that everybody should have their own local setup," he said.

As the project grew, manual patch application by Torvalds became the bottleneck. The project needed a better way to integrate contributions.

What did BitKeeper and Git change?

BitKeeper, a proprietary version control system, supplied the improvement — and divided the community. Some developers refused to use it on licensing grounds. Torvalds found distributed source control made merging work from subsystems such as networking and ARM substantially easier.

"BitKeeper, as far as I'm concerned, was a huge success," he said. He did not consider it flawless, but it showed him what source control could do and helped him identify what he actually wanted.

The 2005 BitKeeper licensing dispute ended access to the tool. Having experienced distributed source control, Torvalds would not go back. Git was his answer.

Hohndel recalled the timeline: Torvalds produced the first working version — a new object model, code, and a functioning tool — in 11 days. Early Git had rough edges and felt unfamiliar to developers accustomed to CVS.

Its eventual reach still surprises him. According to a 2022 Stack Overflow Developer Survey, nearly 94% of respondents and almost 97% of professional developers use Git, making it the de facto standard for version control. Torvalds never intended that outcome. "I sometimes get way too much credit for Git," he said.

He handed over Git's maintenance after roughly six months. The point, he stressed, is that subsequent decades of development belong to other people. "It's worth noting that Git today is a lot better than Git in 2005."

Why does the kernel favor incremental change?

The release process underwent one more major shift: away from long-lived, separate stable and development trees, toward frequent releases, a merge window, and release candidates. Under the old model, annual releases could stretch into years, making planning difficult.

Torvalds proposed a dramatically shorter cycle. The reaction was blunt. "People looked at me like I had grown a third head," he said. His initial five-week target was intentionally aggressive; the process settled into the familiar nine-to-ten-week rhythm.

The result has held. "We now, for the last 20 years, have a really stable, working model," he said.

He also rejects organizing Linux around dramatic feature launches. "I'm a big believer in the whole incremental small changes that, over time, turn into big features," he said. As he put it this summer in Mumbai, the goal remains "incremental improvement and steady progress all the time."

That philosophy frames his position on AI. The tools are changing how Linux finds and fixes problems, and maintainer stress is a real cost the community is still learning to manage. But the development model itself — rapid, small improvements to an essential, stable operating system — is not up for revision.