Linus Torvalds Says AI Coding Is Great for Fun Projects, but Not for Running Linux

Linus Torvalds has a simple rule for using AI in his own work: he leans on it for tasks he admits he is bad at, not for the job that made him famous. Speaking with ZDNet, the Linux creator described AI-assisted programming as "a wonderful way to find joy in programming," framing the tools as a way to lower the barrier to building things rather than a replacement for his day job. The distinction puts one of the most influential maintainers in open source on the side of AI as a personal productivity aid, not an autonomous developer.

That line is sharper than it first appears. Torvalds separated casual or side-project coding, where AI can help someone get unstuck and stay motivated, from the work of running Linux development itself, which he said should not be handed over to these tools. The exception he allowed is narrow but useful: AI is fine for finding bugs. That carve-out matters because bug hunting is a bounded, checkable task, while kernel maintenance involves architectural judgment, long-term compatibility and decisions with consequences measured in years.

Torvalds has built a reputation for blunt technical opinions, and his stance echoes a pattern emerging across senior open-source maintainers. They are often willing to use AI for drafting, exploration and triage, but resistant to letting models make the calls that define a project's direction. Linux is a particularly sensitive case: the kernel ships to billions of devices, and a bad patch can surface as a regression months later. A maintainer who accepts a plausible-looking change without understanding it is taking on risk that no model will own.

The split Torvalds describes also maps onto how AI coding tools are actually being adopted inside engineering teams. Developers report real gains on greenfield code, tests and debugging, while reviews of AI-generated patches to mature codebases routinely turn up subtle errors, insecure defaults and failures to respect existing conventions. That gap between writing new code and safely changing old code is where most of the friction sits today.

For the AI industry, the takeaway is not that Torvalds rejects the technology. He is using it, just on his own terms, and his framing suggests the value proposition that resonates with experienced engineers is augmentation of weak spots rather than wholesale delegation. Vendors pushing autonomous agents that can maintain large repositories will need to answer for the trust problem he implies: a tool can suggest, but accountability for a merged change still rests with a human.

What to watch next is whether that boundary holds as models improve. If AI systems get measurably better at reasoning about large, long-lived codebases, the case for using them on kernel-level work gets stronger, and maintainers like Torvalds may have to revisit where the line sits. For now, the rule is practical rather than ideological: use AI where it helps you, keep humans on the parts that can break everything.