Live data from Hacker News

Linus Torvalds on LLM usage in kernel development

lore.kernel.org

11–14 of 14 posts

Re: Linus Torvalds on LLM usage in kernel development

#11
post #9

Crazy that this hasn't got more traction here. Maybe people missed this thread. Agentic cli based coding "got good" (around Oct/Nov 2025), and after just a short trial period, most devs in our company were convinced enough to start using it. The graph from "not using it much" to "95% of code written by AI" was incredibly steep. It was obvious from around that point, but particularly from around Opus 4.6 that this was…

No one has to agree with this just because torvalds said it. You can also read up here: https://lore.kernel.org/linux-media/20260715125058.3692aa03@... that this thread is about code analysis not generating it and the signal/noise ratio. It's not like his opinion is shared by everyone because these people actually have to look at the PRs generated and filter out all the noise. The issue is not AI finding bugs is bad,…

>You working in some "we replaced MS Access with another high-level language tool"-place is so far off this level of engineering

You might have a point buried in your post somewhere, but I can't find it because your personal attack obscures it.

Re: Linus Torvalds on LLM usage in kernel development

#12
Overall, sensible take.

I think Linus' position even pre-LLM-coding – basically not trusting any code he gets, and not writing any code himself, just reviewing a ton of it – is strikingly similar to how most people now do "software engineering" (or vibe coding/agentic engineering or whatever you want to call what we're doing nowadays).

From his perspective, the only things that changed is that he can more quickly/better review code and find bugs, and maintainers below him are somewhat more annoyed due to the influx of AI slop.

Re: Linus Torvalds on LLM usage in kernel development

#13
post #9

Earlier quoted context omitted.

No one has to agree with this just because torvalds said it. You can also read up here: https://lore.kernel.org/linux-media/20260715125058.3692aa03@... that this thread is about code analysis not generating it and the signal/noise ratio. It's not like his opinion is shared by everyone because these people actually have to look at the PRs generated and filter out all the noise. The issue is not AI finding bugs is bad,…

>You working in some "we replaced MS Access with another high-level language tool"-place is so far off this level of engineering You might have a point buried in your post somewhere, but I can't find it because your personal attack obscures it.

Yeah you're not wrong, that wasn't really necessary and is no way to treat people that may make good engineers.

See if you use your time to write specifications so AI will stay on guardrails - why not just go all the way to memory layout and functional programming? It's great to know what actually happens on the machine.

With natural language or the 4323th framework that makes things "easier" you just end up yourself not actually knowing what your intent is your machine should fulfill. Shouting at some AI the stuff your boss shouts at you? Not exact logic and what people intend today may contradict what they wanted yesterday.

Having domain knowledge and knowing how to translate peoples immediate wishes, predicting what they will want after that into building solid software is a skill you can grow into, but switching the toolset all the time that hides the magic keeps you from learning what was true in the 70s and is true today.

Post reply on HN