Theo on Linus Torvalds, AI Review and Open-Source Maintainers

I begin with a deliberately sarcastic claim that Linux and Linus Torvalds must be against AI. His recent mailing-list response says the opposite: the kernel project is not categorically anti-AI. I want to explore what that position means for maintainers, code review and the rest of software development.

The immediate context is Sashiko, an open-source, agentic review system for Linux kernel patches. It can examine patches from mailing lists or local Git and works with multiple model providers. The project reports results for a particular test of recent upstream commits marked as fixes.

In the reported test, Sashiko found 53.6% of bugs in the selected set using Gemini 3.1 Pro. Its authors say false positives are harder to quantify and cite limited manual review. These numbers describe that evaluation, not a general comparison proving that AI reviewers outperform humans on all code.

The authors also note that model output is probabilistic: the same input may produce different findings on different runs. That is a healthy qualification. I see value in another reviewer and in additional tests that help a maintainer evaluate a patch, rather than treating a model’s answer as a final verdict.

When I argue for using AI to review code and build verification tools, I am not saying nobody should read a patch before merging it. For many projects human review is still a good idea. The opportunity is to add checks, including temporary tests that need not be committed, around the change.

Theo discusses a report quoting kernel maintainer Greg Kroah-Hartman, who described an improvement in the quality of AI-assisted security reports after an earlier wave of obvious junk. That is the maintainer’s reported experience, not evidence that all generated reports are now reliable.

My guess is that better models reached more developers, who then learned to build workflows around them. That is speculation, not a demonstrated cause of the change Greg observed. The important practical issue is whether a report gives maintainers reproducible evidence rather than another confident but unverified claim.

Even when reports identify real issues, volume creates work. A large, distributed kernel team has more capacity than a small open-source project. Faster automated feedback can help submitters revise a patch before a human review, but maintainers still need time to triage and validate the results.

I point to a large number of Linux CVE records as evidence of the scale of security work and argue that both defenders and attackers can use automation. A CVE count is not the same as a count of newly discovered or actively exploited vulnerabilities; it should not be used alone to infer either.

The mailing-list disagreement began around Sashiko and broadened into an objection to LLMs generally. Torvalds responded that Linux is not an anti-AI project, and that people who disagree can choose another project or fork it. Theo agrees with his position that a useful tool should be judged on its merits.

Torvalds also acknowledges questions about AI’s economics and the pain it can cause maintainers, including a stream of embarrassing bug findings. His proposed direction is to make the tools help maintainers rather than burden them. That is a different claim from requiring every contributor to use them.

I think model providers should have helped open-source maintainers earlier, especially given the importance of open-source code to the ecosystem. Useful support can include direct funding, access to tools, private security work and contributions that are properly checked before they reach a maintainer.

Torvalds argues that kernel decisions should focus on technical merit and says individuals may choose whether to use AI. Another participant, Laurent, objects on ethical grounds. Theo agrees with Torvalds, while the disagreement shows that contributors can evaluate the same tools through different technical and ethical lenses.

I have changed my own expectations as coding models improved, moving from small edits to more ambitious tasks. I expect more developers to find useful applications, but that is my forecast, not proof that every maintainer must adopt the same workflow or reach the same conclusion.

I compare the disagreement with early debates over TypeScript. Experienced JavaScript developers on small teams did not necessarily feel the same need for it as large teams coordinating many contributors. Different tools solve different problems, and a benefit to one group does not mean every individual experiences the same gain.

Theo describes TypeScript as a way to help large teams catch changes that break distant parts of a codebase. He credits Anders Hejlsberg and Microsoft’s need to work at scale. Type definitions can shift work to library maintainers even as they make those libraries easier for others to use.

I recall a discussion with SolidJS creator Ryan Carniato, who said he had used TypeScript for years without being convinced it improved his own productivity. He described an intuitive API that was quick to create but difficult to type well. I see that as a real cost, not a reason to dismiss his experience.

My diagram suggests TypeScript raises the floor for many developers while potentially constraining some highly skilled work at the upper end. This is a conceptual model, not a measured distribution. I use it to explain why I benefited from the tool while another experienced developer could reasonably feel differently.

I see a similar possibility with AI: an expert kernel maintainer may write better kernel code than a model, while a skilled developer from another specialty might find assistance useful. That does not make generated code correct. Domain review and verification remain necessary.

I mention Torvalds using a model for visualization outside his usual specialty as an example of a tool helping someone move more quickly in an unfamiliar area. My own experience with TypeScript, and now AI, has similarly made me more willing to attempt work beyond my established routines.

There are useful applications besides submitting generated code: audit open pull requests, build targeted tests, or investigate whether an existing change behaves as expected. I still do not mean that people should stop reading code. I want teams to use inexpensive generated work to strengthen their verification.

I am optimistic about future model progress, but nobody has to adopt every tool immediately. Experiment where it helps your own work, consider the burden placed on maintainers, and judge the results rather than assuming that more generated output is automatically better.