Follow ZDNET: Add us as a preferred source on Google.
ZDNET’s key takeaways
- Torvalds says AI is now genuinely useful for Linux maintainers.
- Linux 6.18 was the kind of release he likes: boring and stable.
- Torvalds is calmer now, but some things still make him testy.
At Open Source Summit Japan in Tokyo, Torvalds shared his latest thoughts on AI.
It has only been a few weeks since Linus Torvalds, creator of Linux and Git, and his longtime friend, Dirk Hohndel, Verizon’s head of open-source programs, discussed AI, Linux, and open source. Since then, Torvalds has had new experiences with AI, which have made him more positive about using AI with Linux than ever before.
When asked about the impact of AI and large language models (LLM), Torvalds said there are already “tons of tools for checking code,” and one of the main topics at the upcoming Kernel Maintainer Summit will be “expanding our tooling and our policies when it comes to using AI for tooling.”
Also: Linus Torvalds warns Linux devs: Stop cluttering patches with automated, useless links
While what exactly that will mean is still up in the air, it’s clear that some AI tools will be blessed for use by developers and maintainers. That said, he still dislikes the buzzword-heavy hype: “I hate the whole subject of AI, not because I hate AI, but because it’s being such a hype word.” Nevertheless, he called himself “a huge believer in AI as a tool.”
Continuing, Torvalds said he’s “much less interested in AI for writing code” and far more excited about “AI as the tool to help maintain code, including automated patch checking and code review before changes ever reach him.”
He cited a recent internal experiment where an AI system reviewed a merge he had objected to: “The AI not only found my objections, it added some of its own,” which he called “a great sign when the tool finds even more than you find as an expert.”
What is that AI tool?
He’s not at liberty to say yet, but we’ll soon know.
The news may break as early as later this week during the Linux Plumbers Conference, which is happening at the same venue.
Even so, Torvalds pushed back on claims that AI will fundamentally transform programming, comparing it instead to a new layer in a long evolution of tools. He argued that compilers were the real revolution: “Compilers are a 1,000x acceleration for programming,” he said, while AI might add “10x or even 100x on top of that,” still it’s “just a tool.”
Also: The best free AI for coding in 2025 – only 3 make the cut now
The real benefit, in his view, is another abstraction layer where humans can “explain things at a higher level,” making checking and review more efficient.
“Please don’t think that AI is something that revolutionizes programming, because we did that already,” he said of compiler authors “decades ago.” Still, he expects AI-powered review to “hopefully be a fairly integral part of our flow” as early as next year, even as he jokes that “if in 10 years, robots will have taken over and killed us all, I was wrong.”
‘I like boring’
Torvalds and Hohndel also talked about how the newly released 6.18 Linux kernel is precisely the kind of uneventful release he wants for an OS that runs everything from phones to supercomputers. “I like boring,” he said when asked for highlights, calling 6.18 “solid progress” with “a surprising amount of cleanups” and the usual churn of new hardware support.
About half of the kernel is now “literally just drivers,” he noted, underscoring how much of the work goes into keeping up with devices.
Torvalds confirmed that 6.18 is the next long-term support (LTS) kernel, maintained for years so “big companies and small companies and individuals can just have a standard base to rely on for a longer term.” He acknowledged the community now “typically” expects the last kernel of the year to become LTS, but stressed the process remains flexible to avoid destabilizing rushes of last-minute features.
Also: Claude Code made an astonishing $1B in 6 months – and my own AI-coded iPhone app shows why
Thinking of the merge window, Torvalds described it as his “really busy period,” when maintainers send all the code they believe is ready for the next release. He no longer writes kernel code himself. Instead, he spends those two weeks merging “between 11 and 13,000 commits” delivered as “a couple hundred pull requests,” often working “from morning to evening the whole week.”
The following seven weeks focus on hunting and fixing bugs before the final release, with weekly release candidates along the way.
He emphasized that the lack of hard feature deadlines has made life easier for contributors: “When the code is ready, it will get merged,” and if something misses, “in another nine weeks, the next release happens, and it’s not a big deal.”
Non-negotiable
What remains non-negotiable is his expectation that maintainers test properly before code reaches him. When he hits bugs while running his own kernels on everyday machines, he sometimes emails maintainers, calling them “you did not do your job,” even as he tries “very hard to be more polite.”
Still, there are times, he admitted, when he gets ticked off. These are times when it got “to the point where I was the first one to know that something was wrong. I get a bit bitter about this, and sometimes I send emails to the maintainer saying, ‘You did not do your job,’ because they really should have known better. Then, I can get a bit testy.”
“But the thing that has always made me completely mad is when someone doesn’t acknowledge the bugs they introduce,” he said.
Also: How chatbots can change your mind – a new study reveals what makes AI so persuasive
“Bugs happen. That’s inevitable. It will always be true. We are not perfect. We do our best to be very good and very careful. But even when you do your best, mistakes happen. That’s life. I don’t get upset about that part. But then, when somebody points out a bug, you need to step up and say, ‘Oh, that was me. I will fix it, right?’ And sometimes I get responses that say that ‘I fixed another bug,’ and that’s not OK.”
He added: “This is not a one-step forward, two-step kind of situation. You can’t make the excuse that you fix the bug and introduce another bug; that’s bad. That just means the system isn’t something you can rely on. I’d rather have a reliable bug that stays around, and people can work around, than bugs that move around.”
Torvalds was also blunt about how his role has changed: “I don’t do any coding anymore,” he said, describing his job as keeping “a high level idea of everything that’s going on” and “making sure that we have a sane release schedule and that it all works.”
The part he still does deeply is conflict resolution in Git. “I do so many of them that I can do them in my sleep,” he said, adding that he’s so practiced he asks submaintainers not to pre-merge their trees.
Merging code trees, as Hohndel observed, is one of the hardest things a maintainer can do, and Torvalds literally does thousands of them in a week. At this point, Torvalds quipped, “I can do merges in my sleep.”
No regressions
Moving on, Torvalds reiterated the kernel’s strict “no regressions” culture.
“No regressions” means you never make “improvements” that will break older programs that rely on how the old library or code worked. He acknowledged that “not all kernel developers love my rule” because it can be hard to maintain over long periods.
Torvalds described cases where behavior changed years earlier, only to break an application when a user finally upgraded from an old LTS kernel — by then, “other applications have started relying on the new behavior,” making any fix risky.
Also: You should still learn to code, says top Google AI exec – here’s why
“We have done absolutely outrageous things to try to stick to it,” he admitted, including code paths where “we will act differently for different programs” depending on how they behave, just to preserve both old and new expectations. While many developers understandably want to “fix” old designs, he warned that when working on kernels and libraries that other people rely on, “you are not just fixing your own bug, you’re breaking all the programs that rely on your project.”
He concluded, “The kernel has always had this rule that, hey, we don’t make those kinds of improvements. Very few other open-source projects, or closed-source projects for that matter, have that approach to life. I wish more did, but I am not yet king of the world, so I can’t make the rules for everybody else. I only make the rules for the kernel.”
And, at that point, both Torvalds and Hohndel agreed that Torvalds considering becoming “king of the world” was a good place to stop.