‘I use AI to do the things that I’m bad at’: Linus Torvalds on why it works for him

At Open Source Summit Europe in Prague, Linux creator Linus Torvalds told Dirk Hohndel, head of Ericsson Software Technology, that his view of AI-assisted programming has shifted. Where he once thought the technology simply was not very good, he said he has reached the point of genuinely liking it. The remarks put him at odds with parts of the open-source world, where resistance to AI-generated contributions remains strong.

The clearest dividing line in his position is between personal projects and serious production work. Torvalds described himself primarily as a maintainer rather than a day-to-day kernel programmer, with other people doing the real work in the Linux kernel and his role as the collection point. Even so, he said he still enjoys programming immensely, and that AI, treated as a tool and used correctly, makes the activity more enjoyable.

His most concrete example was a guitar pedal project. Torvalds said he had written a user interface himself in C, running on a microcontroller with a small screen, and disliked how dated it looked. He does not work in Java, so he turned to an AI tool with a prompt. The first result, in his telling, was horrendous; he then pointed the model at the C implementation he had already written and described as correct but ugly. He summarized his approach as using AI for the things he is bad at.

Torvalds also offered a broader argument about why AI lowers the barrier for newcomers. He recalled starting to program in 1981 or so, when computers were simpler and the programs people compared their own work against were simpler too. Today, he said, the bar in software engineering has risen so high that a beginner's small effort can feel worthless next to polished professional software. Vibe coding, which many people mock, strikes him as a wonderful way to find joy in programming: it makes a new programmer feel relevant and enables work that would otherwise be very hard. He described AI as a kind of gateway drug in that sense.

On the kernel itself, the picture is more complicated. Hohndel asked about Sashiko, an agentic code review system for Linux kernel patches, and Torvalds noted that its public reviews now appear on the Linux Kernel Mailing List. Some subsystem maintainers have begun expecting patches to have received such a review before they are accepted. It is not a universal requirement, but Torvalds indicated it seems likely that all maintainers will eventually require it. In practice, that turns an AI reviewing agent into part of the project's contribution pipeline, layered on top of human review rather than replacing it.

Torvalds credited these tools with finding real problems, including security issues and defects in old drivers that had gone unnoticed for years. He said the work is improving the code base, while acknowledging the cost: it is also stressing maintainers to the point of being a problem. He has previously described, in Mumbai earlier this year, how convincing but fabricated bug reports can consume substantial human effort to disprove, and how narrowly targeted patches may fix one symptom without addressing the root cause. He has called some submissions mindless band-aid patches.

The maintainer summit discussion the day before, he said, spent roughly three-quarters of its time on making AI generation and review less stressful and more useful. His framing of the bottleneck is that obtaining patches is not the hard part; getting useful work through review without exhausting the people responsible for it is. This suggests the constraint on AI-assisted kernel development is human attention rather than model capability, and that tooling, policy and reviewer capacity will decide how much of it sticks.

Because the occasion was Linux's 35th anniversary, Torvalds also traced how the project's process changed. In the early days there was effectively no development infrastructure. He made patches every day internally and released them at least weekly, tracked through tarball patches and regularly distributed updated source code, which he said worked surprisingly well for a small project. Hohndel noted that this pattern of tarball releases continued until 2002, by which time Linux had grown much larger. Torvalds described those years as just him, himself and his computer.

The move to a distributed version control system came through BitKeeper, which was controversial because of its proprietary licensing and which some developers refused to use. Torvalds called its adoption a huge success for his purposes, saying it made merging work from subsystems such as networking and ARM substantially easier, and that it clarified what he actually wanted from such a tool. He did not require every maintainer to adopt it.

When a licensing dispute ended BitKeeper access in 2005, returning to the old approach no longer appealed. Hohndel recalled that the first working version of Git took 11 days, including a new object model and functioning tool in under two weeks. Early Git was unfamiliar to developers used to CVS and rough around the edges. Torvalds said its eventual ubiquity still surprises him, and that he sometimes gets far too much credit for it. Referencing a 2022 Stack Overflow survey in which nearly 94% of respondents and almost 97% of professional developers reported using Git, he noted that he only wanted a tool for Linux. He handed off maintenance after about six months, and observed that Git today is considerably better than Git in 2005.

Linux's release process also changed, from long-lived separate stable and development trees to frequent releases with a merge window and release candidates. Under the old model, work piled up while distributions backported changes into stable kernels, and releases meant to be annual could stretch for years, complicating planning. Torvalds proposed a much shorter cycle; the reaction, he recalled, was as if he had grown a third head. His initial five-week target was deliberately aggressive, and the process settled into a nine-to-ten-week rhythm that he still considers remarkably effective, stable and working for the last 20 years. He remains skeptical of organizing development around dramatic feature launches, favoring incremental small changes that accumulate into big features over time.

Why it matters: Kernel maintainers and subsystem contributors are the people most directly affected, since AI review is becoming an expected step before patches are accepted and fake or shallow submissions can consume scarce reviewer time. For developers more broadly, Torvalds's split between hobby and production use is a useful frame: AI lowers the entry barrier and can be genuinely enjoyable on personal projects, while in high-stakes codebases its value depends on review capacity and the quality of what it produces. Inference: expect projects to formalize AI review policies and tooling rather than debate whether AI belongs in the workflow at all.