Linus Torvalds Using AI for Kernel Code: A Tool, Not a Substitute for Review

News that Linux creator Linus Torvalds is using AI to help improve kernel code is interesting less as a celebrity endorsement than as a practical test of where these tools belong in serious software work. The Linux kernel is not a place where a plausible-looking suggestion is enough. Changes have to fit a large, old, interconnected codebase—and withstand scrutiny from people who understand the consequences of getting them wrong.

That makes the distinction in the wording matter: AI is helping, not replacing the work of maintaining the kernel. A model can suggest a rewrite, explain unfamiliar code, or point out a possible edge case. It cannot, by itself, establish that a patch is correct across the hardware, configurations, and workloads affected by a change. The suggestion still needs a human to judge whether it solves the right problem.

Useful assistance is not the same as trusted authorship

Kernel development already involves plenty of tools that automate parts of the job: compilers, static analysis, testing systems, and scripts that catch routine mistakes. AI fits most naturally into that family when it helps a developer inspect code or explore an idea. It may save time on the first pass, but saving time on a draft is not the same as removing the need for careful review.

That is especially true for generated code suggestions. They can be convincing while overlooking an assumption hidden in a calling convention, a concurrency rule, or a less common configuration. In kernel work, a small change can affect drivers, memory handling, filesystems, or other parts of the system far from the line being edited. A reviewer needs to ask not just “Does this compile?” but “What behavior changes, and for whom?”

The review process remains the important part

The value of AI assistance will depend on how it fits into the maintainer review process. A patch still needs a clear purpose, a reason for the chosen approach, and evidence that it behaves as intended. Tests and discussion among developers matter because they expose context a model may not have: why a previous design was chosen, which users depend on it, and what trade-offs the maintainers are willing to accept.

There is also a difference between using an assistant privately to understand or refine code and submitting work whose origin or limitations are unclear. Open-source projects benefit when contributors can explain their changes and take responsibility for them. If an AI tool helped, that does not automatically make a patch unsuitable; it does make human understanding and accountability more important, not less.

A sensible signal, not a verdict

Torvalds using AI does not prove that AI-generated kernel code is ready to merge wholesale, nor does it mean every developer should adopt the same tools. It is a signal that experienced programmers may find narrow, supervised uses worthwhile. The most useful question is not whether AI touched a change, but whether the result is correct, understandable, reviewable, and maintainable.

That standard is familiar in security-sensitive systems, and it should stay familiar as coding tools improve. AI can help a capable developer move faster or see an option they might have missed. The person proposing the change still has to know what it does—and the project still has to decide whether it belongs in the kernel.