Never seen a non-deterministic compiler though
C/C++ compilers are non deterministic due to support of super macros that change run to run, non-deterministic optimisation strategies or ordering due to parallelism, and linkers often produce different outputs every time they are run where subtle bugs can cause crashes when addresses don’t line up how you expect. And that’s without mentioning projects that use a configuration step.
Can’t most serious compilers produce reproducible builds these days given the same build environment. I know there has been a drive towards reproducible builds in general for security verification purposes.
I’m not very good with C/C++ so please correct me, isn’t that what’s called a “race condition”? Parallelism can cause non-determinism but not in the same sense LLMs generate non-deterministic output. Compilers are not statistical machines.
You don’t need parallelism to have a race condition, just not handling an event with expected timing can cause one - like when two keys are pressed within one polling cycle and you depend on one being pressed before the other for some logic like up and right arrow for a diagonal but they register as right and up so the diagonal movement doesn’t trigger
Compiler optimisation strategies sometimes use statistical machines and link time optimisation does use random number generators for producing output
An LLM is not inherently non-deterministic though - if you don’t randomly sample and instead have a fixed rule (which is what the recent fingerprint embedding approach does), if applied in all cases the output is deterministic, as the neural net at its core is deterministic function. A lot of the randomness beyond that is due to optimizations [source].
LLMs are however unreliable at ‘compiling’. Whether or not it will be able to complete the requested task (translate human language into code) correctly it not guaranteed - at least nowhere near the compilers we use.
There is a parameter in llms called temperature. If you reduce it down to zero it will become deterministic. And probably even worse.
If you do that it will basically produce the most average possible output, given the context. I don’t know if that’s going to be useful in a compiler context…
Exactly this. If you made an LLM that had deterministic code output then I’m all up for saying “AI is a compiler for human language”. But until then AI is most definitely not a compiler.
Setting the temperature parameter to 0.00 makes an LLM deterministic.
Even Linus is conflating “doing more” with “being more productive”. A car factory could, if they wanted, pump 10x more cars out the door. But qualiry would decrease these would be full of defects, so in the end you weren’t more productive
I don’t care if there’s more PRs. It’s just and illusion of productivity
Productivity = Doing more things Efficiency = Doing the right things
I wrote a whole thesis on the subject AMA
Depends on what your metric for “production” is. If you’re producing more cars that have to all be recalled and fixed, you’re not making more money than you would had you made higher quality cars from the start, and you then also lose face and your brand is viewed as inferior, so sales drop, and the spiral goes brr.
I understand what you’re trying to say, and even agree with it, but the car factory example is just wrong. Those have a design speed that is generally limited by cycle times for individual steps. Like a robot has to place say 10 spot welds. You can’t speed that up. To stick with this example: in theory you could add a robot so both place 5 spots, but that rework takes probably a year and costs millions. Plus you don’t have one bottleneck like this, but a lot of them with similar speed (hence the “design speed” of the whole factory).
You can slow the whole factory down to run under capacity (or not run it during night shift), and then you have room to speed it up. But if you’re running at capacity, there is very little you can do.
It’s physically impossible to speed up the factory to 1.5x, let alone 10x.
Most of these robots are purposely slowed down for human safety and other factors. So I do believe you can speed up a factory a lot, perhaps not10x, but still.
Linus seems to be taking a perfectly pragmatic approach, given that AI is not going away short of WW3.
I can imagine some individual sub-system maintainers introducing various AI-roadblocks though.
I also expect this to be increasingly addressed (in general) with model & tooling improvements, giving more weight to higher quality reports and MRs, and more respect for project rules and processes. A mix of soft and hard gates, CLAs, improved early automated bug report & patch reviews and other CI gates.
deleted by creator
Torvalds was careful to frame this as a correction of language rather than a rejection of the technology itself.
Ok…
A maintainer burden few are talking about
Alongside the productivity gains, Torvalds described a less-discussed cost: a rising flood of low-effort, AI-generated bug and vulnerability reports hitting open source projects, including the kernel’s own security channels. He said it has become common for someone to run an AI tool against a codebase, file a report flagging a “possible” issue, and then vanish when a maintainer follows up asking for more detail or a fix.
Everyone is talking about that and it is surprising to me that he doesn’t recognize that as two side of the same coin. Why are you rejecting the low-effort, Ai generated bug reports, Linus, isn’t AI just a productivity tool? What’s wrong? Is it not being productive?
I say “surprising”, it’s not that surprising. It’s a “guns don’t kill people, people kill people” attitude. It’s willfully excluding the impact that technology has on people, and framing the outcome as coming purely from people and the existence of the technology not affecting the outcome.
Why are you rejecting the low-effort, Ai generated bug reports, Linus, isn’t AI just a productivity tool?
Because they are low effort. Good software engineering is never low effort, whether you use AI or not.
If you let AI replace people, and let them mess with software or report issues without understanding what’s going on, without putting in the effort to understand what’s going on, you’re not adding any value; just noise.
But if you use AI to find issues, then investigate the issue, reproduce it, document it, etc, then you’ve got something meaningful that someone can do something with.
… What?
Lazy people using tools in a shitty manner has been an age old problem.
This just lets it scale, which is the problem. There used to be a barrier to entry for those less knowledgeable or experienced, now there isn’t and that’s the result.
It is a productivity tool, and it’s being used as one, by both people that know how and people who don’t.
bingo. and unfortunately the lazy and inexperienced are using it more than others, or using it at a much higher degree. Linus even says it himself. they file a report and then “vanish” because they can’t answer follow up questions or clarifications because they don’t know how. if you deal with LLMs and the people that use them as much as I do for my job you see this constantly. daily even. they “build” something and when it’s reviewed and questioned the answers are just no where to be found because the “coder” can’t answer them.
Like the other day there’s this guy on Youtube who is a huge advocate for Omarchy for whatever reason. older guy but he’s always going on about how great Omarchy is. he posts a video about how “we” built some application for Omarchy but the entire video is him putting prompts into Claude Code and then walking away. never touches it, never writes a line of code. but there were glaring bugs with the build so I reached out to him, asked him how he was going to address these things and hoping he wouldn’t put this app out there because it’s clearly broken. works on a surface level but it WILL break. he essentially told me to “fuck off”.
you’re right an LLM is a tool but one that should be in the hands of those that know what they’re doing. you wouldn’t hand a hammer to a child and tell them to build a house. you wouldn’t hand a gun to a junkie and tell them they’re now a cop. I wouldn’t hand Vim to my mother and tell her to build a website. I feel LLMs should require human training just like any other tools we use. If you want to allow LLMs into your open source project, sure, have at it but it should be YOUR responsibility to vet and interview each individual that wishes to contribute utilizing said tools.
Tools are just tools; there are good ways and bad ways to use them. “Grok, go find bugs in the Linux kernel” isn’t a good one. This isn’t hard to understand…
There were many, partially well-intentioned, mostly fame-seeking, one-off ‘projects’ ‘scanning’ public repos and flooding them with low-quality low-effort PRs and issues; things that no human ever read until the a maintainer did.
“They made a poison and sold us a cure” is absolutely a valid criticism; that’s two sides of the same coin. But pretending that he’s being hypocritical or that LLMs aren’t useful is just being wrong for the sake of hating AI
AI is useful as tool like he said, unfortunately these days in many organisations it is used as a replacement rather than a tool.
His conclusion was that as AI tools get more capable, the people who actually understand how systems work become more valuable, not less — because someone still has to review, maintain, and take responsibility for what the tools produce.
Humans still need to learn how to code.
Tools are just tools
I don’t think that’s true, but we simply disagree on that.
I don’t think he’s hypocritical. He simply doesn’t have to deal with that negative impact he “warns” about. He is in support of using it as a tool and thinks the criticism is invalid. That’s a consistent perspective, even if I don’t agree with it.
If he used LLMs to create bug reports, but also complained about LLM written bug reports he gets, that would be hypocritical.
