Conversations with Linus Torvalds: AI Bots Reviewing Bots Inside the Linux Kernel AI Experiment

November 07 2026 13:53
Linus Torvalds does not enjoy public speaking, and after 35 years of running Linux he says he still gets nervous about it. So the Linux Foundation keeps staging his keynotes as a conversation. His old friend Dirk Hohndel, who recently became head of Ericsson Software Technology, invents the questions. The most recent installment took place at the Open Source Summit in Prague, and it wandered through the whole arc of his career, from patches by email to bots reviewing code on mailing lists.

The opening story is the one I like best. In 1991 and 1992, people who knew more about Unix than Linus did were sending him working patches. He did not apply them. He read each one, worked out what the author was trying to do, and then rewrote it himself from scratch.

He says this lasted three or four months. The first version of the kernel was about 10,000 lines, so he knew every corner of it, and it felt like his project. Eventually he asked himself why he was doing extra work when someone had handed him something ready to use. That was the moment he started becoming an open source maintainer, as opposed to a person who published source code.

His point is that this is normal and not really a problem, unless it drags on. A project goes wrong when the founder never accepts outside help and never lets contributors feel like part of the thing. Learning to work with a community takes time, even for the person at the center of it.


Hohndel asked the obvious follow up. With no source control at all, how did the early kernel survive? Linus said he made patches every day for his own use and released tarballs roughly weekly. It worked well for a small project, with a handful of people in 1991 that grew to maybe 50. He was not even opposed to CVS at first. He had simply never used any source control system, and patches and tarballs felt natural.

That changed as he learned more. He came to hate the central repository model, where someone has to host the server, manage who can commit, and fight with branches. He wanted everyone to have their own full local copy. Tarballs and patches, oddly, did that better than the traditional tools. Hohndel joked that tagging a release in CVS on his own system once took about two and a half hours.

Then came BitKeeper, the proprietary tool the kernel used from 2002. It was controversial, and plenty of developers refused to touch it on principle. Linus says it was the first system that made him think source control could help distribute data instead of making weak copies of a central store. He still calls it a huge success, flaws included. Torvalds has said similar things before. In a recent look back at 20 years of Git, he recalled thanking BitKeeper for showing what good source control looks like.


In 2005 someone reverse engineered BitKeeper, and the free license for kernel developers went away. Linus describes the shock in a way anyone who has lost a favorite tool will recognize. People get used to a process, even a bad one, and when it is taken away the pain is real. Going back to tarballs was impossible because he had now seen something better. So he announced he was stepping back from the kernel until he had an alternative, and then he built one.

The timeline is famously short. Heise notes that he created Git in just a few days in early April 2005. Hohndel, who was there, put it at 11 days to a working version and told a story about the day it began. Linus pulled him aside at his daughter's birthday party to talk about the idea, and the two of them vanished to an ice cream shop while their wives did the party prep. Hohndel says he heard about that more than once afterward.

Git was not an instant hit. Linus says it was disliked even more than BitKeeper, partly because he deliberately renamed commands to avoid anything that looked like CVS, and partly because its object store model was conceptually different. People coming from CVS found it baffling. Within roughly five years, it had taken over.

What he wants everyone to understand is that Git was never the goal. It was a tool to get the kernel working again. After about half a year he handed it to Junio Hamano, and he says he has not been involved for over 20 years. He thinks he gets far too much credit. That is consistent with what he told reporters on Git's anniversary, when he said Hamano deserves the credit and even joked that he uses only five Git commands himself.


The other big process change came around 2006. Before that, Linux shipped when Linus felt like it, which meant roughly every two or three years in practice. There was a stable tree people used and a development tree where all the new work happened. By the time the big release was due, the new work did not function. Distributions backported what they needed and everyone ended up with a mishmash.

Linus told the maintainers he wanted to go to releases every five weeks. He says people looked at him as if he had grown a third head. He admits five weeks was intentionally aggressive and he never believed it would stick. Instead the project settled into a merge window followed by release candidates, with a release every nine to ten weeks. It has run that way for 20 years.

The latest proof is Linux 7.3, which shipped on schedule with records for commits, developers, and first time contributors: 18,765 non merge commits from 3,021 developers, 807 of them new. Linus's own description of the last week, according to that coverage, was that it was uneventful.

That is exactly how he likes it. He says he wants the kernel to be boring, and he deliberately avoids big headline features in releases. He prefers small changes that distributions and programs pick up over time. You only notice how much changed if you compare against a distribution from five years ago.


Hohndel waited more than 25 minutes to bring up AI and was proud of it. Linus told him that would end quickly, and it did.

The kernel now has several AI tools reviewing patches in public on the same mailing lists humans use. The main one is Sashiko, built by Google engineers and maintained in the open. Linus says some subsystems will basically no longer accept a patch unless Sashiko has reviewed it in public. The reviews are not perfect and sometimes the complaints are just wrong, but he points out that human reviews are sometimes wrong too.

His description of the dynamic was memorable. The kernel is, to some degree, fighting an AI deluge of patches with its own AI deluge of patch reviews. People joke that bots are talking to bots, and sometimes they literally are.

The numbers back up how big this has become. Sashiko launched this spring, and early reporting said it found about 53 percent of bugs in a test set of 1,000 recent upstream issues. The project describes itself as a review system that uses prompts originally written by kernel developer Chris Mason, with Google funding the computing costs. By early October, a Google engineer reported more than 191,000 patch reviews across 99 mailing lists, and 463 kernel CVEs this year that cite Sashiko.

The flip side is volume. Linus says AI tools are pointing at code nobody has touched in 20 years, in drivers nobody uses, and reporting every memory leak they can find. Some of those reports are real security issues. Others are noise. The result is a better code base but also stressed maintainers, to the point that he calls it a problem. Three quarters of the discussion at the maintainer summit the day before was about making AI tools less stressful and more useful for everyone.

You can see the effect in the release notes. Linux 7.3 was heavier than usual because of AI driven churn, including bug discovery and new patches, along with removal of obsolete drivers. The fourth release candidate arrived with fixes scattered everywhere, many of them found by language models.

This echoes what Linus said in May at Open Source Summit North America, where he and Hohndel noted that companies spend lots of money and tokens pointing out bugs and rarely include a patch.


The final stretch of the talk is where Linus was most personal. He started programming around 1981, when computers were simple enough to understand and the bar for what counted as a decent program was low. His teenage games, he says, were terrible, but nobody felt ashamed. Today a beginner compares their first project with polished phone apps and can feel it is not worth finishing.

That is why he likes AI as a gateway into programming. He is not a big kernel programmer anymore, he says. He describes himself as a technical lead and a collection point for other people's work. But on hobby projects he still loves to code, and he likes what AI does for them.

His example was a guitar pedal. He had written the interface in C on a microcontroller and it looked like something from the 1980s. He does not do front end work, so he asked an AI to help. The first attempt from a single prompt was horrendous. What worked was showing the AI code he already understood and knew was correct, then asking it to give that logic a modern face. He was impressed with the result.

His conclusion is careful. Vibe coding is fine as a toy and as a way into the craft, and he still looks down on it for real projects. Good code still requires understanding the code. His views have moved a long way on this, as one recent retrospective on his comments traces, from calling the AI industry mostly marketing in 2024 to being fairly positive about it for beginners a year later It's FOSS timeline of Torvalds changing views on AI.