Coding with AI

Linus Torvalds on why AI works for him: ‘I use it to handle what I’m not good at’

Torvalds now enjoys AI coding for beginners, but Linux kernel AI reviews help fix bugs while stressing maintainers.

Linus Torvalds on why AI works for him: ‘I use it to handle what I’m not good at’

Key Takeaways

  • Linus Torvalds has shifted from skepticism to enthusiasm about AI coding, especially for tasks he is not good at, such as UI work, and sees “vibe coding” as helpful for beginners.
  • In the Linux kernel, AI-assisted review can find real issues, including security problems and long-overlooked bugs, but it also stresses maintainers with low-quality patches and fabricated reports.
  • Torvalds sees AI review as increasingly important for kernel patches, though its main challenge is making reviews useful without exhausting human maintainers.
  • Linux’s development process changed dramatically: early on Torvalds used tarballs and manual patching, while BitKeeper’s distributed model later helped shape the need for a better tool.
  • The BitKeeper licensing dispute led Torvalds to create Git, a tool that quickly became central to Linux development and open-source collaboration.

Meta description: Linus Torvalds says he now enjoys using AI for programming and calls it a "gateway drug," while warning that AI in the Linux kernel must be handled carefully. (159 characters)

Linus Torvalds on why AI works for him: ‘I use it to handle what I’m not good at’

Tags: Linus Torvalds, Linux kernel, AI coding, open source, Git

At Open Source Summit Europe in Prague, Linux creator Linus Torvalds told longtime friend Dirk Hohndel that he has changed his mind about AI-assisted programming. "I actually really like using AI," Torvalds said, a notable position at a time when many open-source developers remain skeptical of AI-generated code. His comments came during a wide-ranging conversation that also covered how the Linux kernel's development process has evolved and why Git exists at all.

For anyone who writes code, maintains a project, or simply uses Linux, Torvalds's remarks matter because they draw a clear line: AI can be a genuine source of joy for beginners and hobbyists, but using it inside something as important as the Linux kernel requires caution. That distinction shapes how the kernel community is now handling AI-generated patches and reviews.

From skepticism to enthusiasm

Torvalds admitted he did not always feel this way. "I used to think it was just not very good — but now I'm at the point where I actually really like using AI," he said.

He described himself primarily as a maintainer rather than a day-to-day kernel programmer. In his view, the Linux kernel is a project where other people do the real work and he acts as a collection point. Even so, he still enjoys programming, and he finds AI makes it more enjoyable when treated as a tool rather than a replacement for understanding.

Part of his enthusiasm comes from how much harder software engineering has become since he started programming in 1981. Computers were simpler then, and the programs people compared their own work to were simpler too. Today, Torvalds said, the bar is so high that newcomers can struggle to see their small efforts as worthwhile next to polished, professional software. He called "vibe coding" — letting AI help generate code — a wonderful way to find joy in programming, because it lets new programmers attempt things they would otherwise find very difficult.

Linus Torvalds on why AI works for him: ‘I use it to handle what I’m not good at’

He gave a personal example: a guitar pedal project with a user interface he had written in C for a microcontroller and a small screen. He wanted it to look modern rather than like something from the 1980s, but he does not work in Java. So he asked AI to help. The first result was, in his words, horrendous. He then showed the AI the C code he had already written correctly and explained that it simply looked ugly. He summed up his approach as using AI for the things he is bad at.

AI inside the Linux kernel

AI is not only a hobbyist's toy. Torvalds was asked about Sashiko, an agentic Linux kernel code review system. He noted that 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 they will accept them. Not every pull request must go through an AI review, but some maintainers require it, and Torvalds suggested it seems likely that all will eventually.

The benefits are real. AI tools can identify genuine security problems and can surface issues in old, no-longer-used drivers that have gone unnoticed for years. Torvalds sees value in the resulting fixes, but he is honest about the cost. "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.

This tension has been building. As Torvalds said 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 has called some submissions "mindless band-aid kind of patches."

The scale of the concern showed up at the Linux Kernel Maintainer Summit, where Torvalds said three-quarters of the previous day's discussion concerned making AI generation and review less stressful and more useful. The bottleneck, he explained, is not getting patches — it is getting useful work through review without exhausting the people responsible for it.

How Linux's development process changed

Because this year marks Linux's 35th anniversary, Torvalds also reflected on how the project's process has changed. In the beginning there was essentially no development infrastructure. He tracked changes through tarball patches and distributed updated source code. "I made patches every single day internally, and I released them at least weekly," he recalled, adding that it worked surprisingly well for a small project. Hohndel noted this continued until 2002, by which point Linux had become a much larger undertaking. In those days, Torvalds said, "It was really just me, myself, and my computer."

His reluctance to adopt existing source-control tools was not stubbornness. He wanted developers to work independently with their own local environments. But relying on him to apply incoming patches by hand became a bottleneck, and the project needed a better way to integrate contributions.

Linus Torvalds on why AI works for him: ‘I use it to handle what I’m not good at’

BitKeeper, Git, and a tool that outgrew its purpose

The BitKeeper version control system provided that improvement, though its proprietary licensing divided the kernel community and some developers refused to use it. Torvalds found that 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. It was not flawless, but it showed him what source control could do and helped him identify what he actually wanted.

Then the 2005 BitKeeper licensing dispute took the tool away. After experiencing distributed source control, going back was unappealing, so Torvalds built Git. Hohndel recalled that the first working version took 11 days — a new object model, code, and a functioning tool in under two weeks. Early Git was not universally popular; developers used to CVS found it unfamiliar and early versions had rough edges.

Its eventual success still surprises Torvalds. 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. All Torvalds wanted was a tool for Linux, not to remake software development everywhere. "I sometimes get way too much credit for Git," he said. After roughly six months he handed over maintenance, and he stresses that today's Git is much better than the 2005 version.

A stable model built on small changes

Linux's release process also changed, moving from long-lived separate stable and development trees toward frequent releases, a merge window, and release candidates. Under the old model, work piled up in the development tree while distributions backported changes into stable kernels, and releases meant to happen annually could stretch into years. Torvalds proposed a much shorter cycle, and the reaction was not enthusiastic. "People looked at me like I had grown a third head," he recalled. His initial five-week target was deliberately aggressive; the process settled into the familiar nine-to-ten-week rhythm. "We now, for the last 20 years, have a really stable, working model," he said.

He also pushed back on the idea that Linux should organize itself around dramatic feature launches. "I'm a big believer in the whole incremental small changes that, over time, turn into big features," he said, repeating a point he made in Mumbai: the goal remains incremental improvement and steady progress.

What this means for readers

For developers, Torvalds's message is practical rather than ideological. AI can lower the barrier to entry and make programming fun again, especially for beginners and hobbyists. But in projects where mistakes carry real consequences, AI output still needs human judgment, and the people reviewing that output need protection from burnout. The kernel community is actively working out how to get the benefits of AI review without drowning its maintainers — and if Torvalds's account is any guide, that balance will define the next phase of Linux development.

Comments (0)

  1. No comments yet. Be the first to share what worked for you.

Leave a comment

Comments are reviewed before they appear. Your email address is not published.