Hi again! Thanks for stopping by to read another one of my anti-AI posts. This one was written back in July, so if you’re seeing this right when it comes out, you’ll see some references to some “new” clips. I’m putting this disclaimer up front, so you don’t think this is fresh news or something.
Anyway, today I’m talking about a clip of Linus Torvalds that got some attention in the software space. Overall, I liked what he had to say, but if the title of this piece is any indication, there’s at least one statement he made that annoyed me. In any case, let’s get into it!
My History with Linus Torvalds
If you read this heading, you might think I know Linus personally. I don’t. In fact, I really only know about him through the random stories I’ve heard over the years. For example, I had this impression of him that he was kind of a smug guy. I figured because he had built Linux and Git that he had developed a sort of complex around being the best developer ever. This was only amplified by the series of “unprofessional” emails he’s sent as a member of the Linux community.
More recently, I’ve grown to appreciate Linus, especially since he dunked on Elon last year. In fact, I often site him as the example of perhaps the only 10x developer to ever live, while obviously mocking that absurd title. Though, I’ve had students try to convince me of the genius of Terry Davis.
Of course, I think the real reason that I’ve recently latched onto Linus is that he hates C++. When I found this out, I suddenly thought, “maybe he’s not so bad.” After all, I cannot stand that language. It just looks like what happens when you build something without a plan, purpose, or philosophy.
Ultimately, I trust Linus’s opinions and generally the opinions of anyone who has lived long enough to program before compilers and assemblers. They’re very much a dying breed, both literally and in terms of training. After all, we just don’t train students to appreciate the history of software development (which isn’t that long by the way!). Perhaps that speaks to how well older developers did their jobs, but I can’t help but feel like we’re losing something along the way.
Listening to One of the Greats
Recently, I found myself listening to Linus while he was the featured keynote speaker alongside Dirk Hohndel at the Open Source Summit in India. You can watch the video here.
Overall, he had a lot of good stuff to say around the problems with AI in software development. For example, around the 28-minute mark, he talks about how LLMs have affected development on the Linux kernel. According to him, until earlier this year, “we saw more junk being generated by LLMs than we saw useful code.” And even now, he argues that LLMs are taking a lot of time away from developers who are stuck reviewing bug reports.
Also, he acknowledges several times that programming isn’t being replaced. Real humans still need to investigate bugs and understands systems. And in fact, like Linus, Dirk also maintains a lot of healthy skepticism around the ability of LLMs to produce code ready for production
Though, I do find it interesting how Linus uses LLMs. For someone like Linus who clearly knows what they’re doing, I find it fascinating that he would still feel the need to leverage them. But, Linus’s use case seems more or less reasonable. He’s using them to prototype features to see if they make sense before committing the time to actually implementing them. While I still oppose their use generally, I think this is one of the more harmless use cases. In fact, Linus is hoping that people are only using LLMs in this way:
I use LLMs for my toy projects, and I really enjoy that part because I use them as a way to prototype things. And basically I say, “Hey, this is something I want to try out, but it would be too much effort for my toy project for me to write something that I’m not sure will work.” And then I’ll use an LLM to say, “Hey, do this for me,” and quite often the code is not usable in that form. But, it’s a great way to try something out. And I think that is (gestures widely) hopefully how most people use LLMs today.
Linus Torvalds, Open Source Summit India 2026
Likewise, Linus mentions being really happy to have LLMs around to find bugs. As I’ve surely written somewhere on this site before, if prototyping is maybe a harmless use case, looking for bugs is probably the only other good use case I can imagine. You can just add that to the tool belt with static analysis and testing.
Generally, I thought Linus had a lot of good stuff to say, and while I still very much oppose LLMs for general use (i.e., they should be treated as expensive lab equipment at best), I felt most of his takes were very reasonable.
His One Bad Take
The only reason I had watched that summit video was because I was searching for the source of the bad take I saw on Primeagen’s channel. After scrubbing the whole video, I realized I had watched the wrong one. The actual source of the bad take came from a similar keynote a month prior at the Open Source Summit in North America. I assume both keynotes were similar, but I just wanted to acknowledge that I’m not purposely doing some bait and switch.
Anyway, here’s the bad take. It starts around the 25:55 mark in response to the question “do you have something to tell someone at the beginning of their career, here is where you should focus?” I’m going to share it in chunks because it’s quite a long response to the question. To start, Linus opens with a pithy joke:
So, my opinion has always been that hey, AI is a great tool, but it’s a tool. And when I see people say hey, “99% of our code is written by AI,” I literally get angry. Because those same people, I pretty much guarantee that 100% of their code is written by compilers. But they never say that.
Linus Torvalds, Open Source Summit North America 2026
Next, Linus gives a bit of background around his answer:
I grew up writing machine code. And when I saw machine code, I don’t mean assembly language. I mean the numbers. I mean, it leaves an imprint on you. […] It took me a while to understand that writing down the numbers and calculating offsets for branches is kind of stupid. And people had come up with this tool called an assembler. And then later on I figured out compilers are good too. And these days I’m figuring out AI tools are good too. I’m still writing the code. I’m just not doing it the same way I did when I was basically typing in numbers in data statements. I’m personally 100% convinced that AI is changing programming, but it’s not changing the fundamentals. Exactly the same way that you all use compilers to actually generate your code. You will all use, well, not maybe all of you, but a lot of people will use AI to generate the code that the compilers use to generate the code that the assemblers then use to generate the machine code. This is revolutionary in the same sense that we’ve seen revolutions before. And AI will increase your productivity by a factor of 10. And I claim that compilers increase your productivity by a factor of 1,000. So, AI is great, but AI is not changing programming.
Linus Torvalds, Open Source Summit North America 2026
Finally, Linus rounds out his response by talking about what he thinks new folks should actually understand.
And I think you do want to understand how it all works in the end. I don’t program in machine code anymore. But I still look at the generated code. So, when I use a compiler, even when I use AI for my pet toy projects… I will use AI to generate code. I will look at that code. I will actually still look at the assembly language end result because it’s what I grew up with. It’s kind of where my comfort zone. And right now I’m playing with microcontrollers anyway, so you really you really want to actually look at the generated code and make sure it’s doing what you really want it to do. So, I think even when you use AI for coding, if you do a project that you actually maintain long-term, you need to understand not just your prompts, but you need to understand the end result too because that’s the only way you can maintain it long-term. And it’s easy enough, and we see that all the time, where you basically generate a new project, and it’s a throwaway project, and it’s a one time and it’s over. And, AI is great for that, and we call it vibe coding. But if you want to make something serious, you’re going to have to maintain it for 35 years or something. And at that point, it’s a lot more than just writing the prompts to make somebody else generate the code.
Linus Torvalds, Open Source Summit North America 2026
In general, I find this advice to be pretty interesting for someone who is just starting their career. In fact, there are two bits that I really like.
First, this idea in the second quote that compilers are significantly more important to software development than LLMs. I agree. We don’t really appreciate how important they are to the development process.
Second, I like this idea that you still need to understand how things work. I am, of course, a little skeptical that you can use AI at all and pretend to have as much expertise as someone writing the code, but I’ve made that argument in like a dozen other places on this site (e.g., in my pay-to-lose article and in my writing code on paper is good article).
However, I’m really stuck on this idea of comparing compilers (and assemblers) to LLMs. I feel like that kind of analogy does more harm than good, so let’s dissect it in the next section.
Comparing Apples and Oranges
There are several areas of Linus’s response that I would like to reflect on, but let me start with his initial joke about compilers also generating code. When I first heard him say this, I’ll admit that I found it kind of funny. But after like a second, I couldn’t really figure out his point. Is he trying to say that no one writes code? Is he suggesting that there is no difference between writing code and writing prompts? Is he arguing that there’s no difference between LLMs and compilers?
If I had to give my most charitable interpretation, it seems like Linus is upset that people don’t give compilers enough respect. In fact, he almost outright states this later when he claims that AI may 10x your output but compilers 1000x it. In other words, I think he’s trying to suggest that compilers are significantly more important or were significantly more revolutionary than LLMs today. Perhaps that’s why he’s so annoyed by people suggesting that most of their code is generated by AI.
Sure, I can buy that. I also think compilers are awesome, but perhaps I think they’re even more awesome than Linus does. Because in an effort to argue that compilers are better than AI, he sort of diminishes their value at the same time. He does this by conflating the two as the same kind of thing: just another abstraction. In the same way that compilers made it easier to write code, so too does AI.
I find this comparison almost insulting to the field of computer science for several reasons.
First, compilers are not “cloud-based.” We do not need to connect to the internet to compile a program, but we probably have to connect to the internet to use ChatGPT. Sure, self-hosted models exist, but I suspect that the vast majority of people are simply paying subscription fees for the best performance. In other words, saying LLMs are like compilers is like saying, “what if my compiler followed the same model as a live service game?” Using that logic, it won’t be long before OpenAI adopts the Blizzard strategy of releasing “ChatGPT-3 Classic.”
Second, compilers are predictable. I struggled to come up with the right word to use here because I think both static and deterministic fit as well, but the point I’m trying to make is that we can always guarantee the behavior of a compiler by pinning its version. We rely on this in the Sample Programs repo to ensure all programs for a specific language behave correctly. In contrast, even if we manage to self-host some version of Claude, we’re at the mercy of our own hardware—not just the temperature setting of the model. For everyone else relying on cloud-based LLMs, they’re basically guaranteed to lose access to they’re preferred version of the model at some point in time, either when the company chooses to deprecate it OR when they go out of business.
Third, compilers are not a black box. We know how compilers work, and we can even teach undergraduates how to make them. If we run into any problems, chances are that the compiler is open source, and we might even be able to chat with a maintainer. If not, we might be able to decompile it. In other words, there are a lot of ways to get under the hood of a compiler, so they can be fixed. Meanwhile, when an LLM does something weird, we can’t peel back the curtain to diagnose the issue. Hell, even if we could log an issue with the source code, how could they possibly patch it? As far as I know, these models are static once they’re trained, and it’s not like there is anything meaningful that could be done anyway. What weight could you possibly adjust that wouldn’t have catastrophic effects on the rest of the model? There’s a reason we refer to them as black boxes.
Fourth, compilers are a true abstraction, unlike LLMs as others have argued. While LLMs can generate code, it’s not like we commit the prompts to git. We’re still taking the code it spit out and preserving that. It would be incredibly weird to hold onto an intermediate representation produced by the compiler, but we’re stuck doing that with LLMs. Also, for the record, we already have abstraction in software: it’s called bootstrapping. We can already make languages that are significantly more accessible and easier to use by building them on top of languages that already exist. Hell, libraries are a form of abstraction. I’m not sure we ever needed a way to generate high-level code when we can happily build on top of what already exists.
Fifth, compilers don’t “hallucinate.” Y’all know how much I hate this term hallucinate. It makes it sound like a tech oopsies. It’s not. LLMs lie by design because they’re simply statistical models. If the goal of the model is to make a prediction, it will sometimes make an incorrect prediction. This never happens with compilers. Sure, compilers might have bugs, so they might produce incorrect byte code or machine code. But, the compiler is never going spit out a message that reads, “you’re so right. I did miss a syntax error on that last run.”
Sixth, compilers have enough jargon to compete with. Okay, this point is sort of silly, but I have a hard enough time trying to define “compiler” as a concept for my students—especially with all the misinformation on the internet around the differences between just compilers and interpreters. I don’t need them thinking that they’re like LLMs in the same way that many of them think neural networks are like the brain. Though, perhaps the confusion around terminology is the point. Otherwise, how will we stroke our egos as the closest thing to wizards?
Seventh, compilers aren’t built on exploitation. I realize this is probably the weakest point because the average developer has been borrowing code their entire career, but LLMs feel different. After all, I’m in favor of open-source software, so I like working in an environment where we’re all working toward building a better world without having to fight over intellectual property rights. With that said, even Linus understands the value of true open-source software. Otherwise, he wouldn’t have licensed Linux under GPL, a copyleft license. Being able to take code without anyone’s consent to not only profit off it but to claim attribution is exploitation, yet we let LLMs do it. I also just don’t buy the “fair use” argument or the “learns like a human” argument. It’s exploitation; plain and simple. Something a compiler never needed to do.
Ultimately, this critique is clearly a bit nitpicky. I’m not sure it was worthy of its own article, but I am bothered by this idea that compilers and LLMs can be compared simply because text goes in one side and comes out the other. To me, that feels a bit reductive, and it sort of oversells what LLMs are doing while ignoring their harms. While I wasn’t alive when compilers were created, I can’t imagine they caused nearly as much harm as LLMs do now. If you’re wondering what harms I could possibly be referencing, let me end here with my usual list of related articles:
- Why I Rebel Against the Use of Generative AI
- Why Generative AI Makes the Future of Software Development Worse
- The Worst Use Cases for Generative AI That Are Already Mainstream
That said, I should mention once again that I thought Linus’s take here was fairly good, all things considered. I really was only bothered by this comparison, and I understand that he was just using assemblers and compilers to make a broader point about how you still always needed to know how these things worked. That’s good advice, and I’ll probably use this clip as a bit of an appeal to authority in the classroom. After all, if they won’t listen to me, maybe they’ll listen to Linus Torvalds.
Anyway, thanks again for reading. Hopefully, this was interesting! If so, please consider supporting the site by heading over to my list of ways to grow it. Otherwise, take care!
By the way, I’m sneaking a few YouTube comments I saw below because I couldn’t quite figure out where to fit them above. I liked them, so I’m putting them here.
I’m tired of the compiler comparison. With compilers, 95% of the time when code breaks you don’t look at the binary or assembled code, you look at the source code. When genAI code breaks, you don’t look at the prompts to see what went wrong, you still have to look at the source code. What good is an abstraction if I constantly have to concern myself with the specifics? AI is less like a compiler and more like meta programming on steroids with less determinism.
majoraincarnate335
I ask my friend Dave to make me a website. I describe how the website should work in detail. I provide the graphics, I provide detailed notes about behavior. When Dave provides me with prototypes, I point out what doesn’t work and what I’d like changed. I write none of the code myself.
When my website launches, I claim to be the sole developer of the website and an elite programmer, despite knowing no Javascript. “It’s just a higher level of abstraction,” I say. “It’s like compilers. Dave just speeds up the typing for me. I’m still a software engineer at the end of the day.”
CyberDork34, 2026-07-7
The best specification you can write is the code itself
mattymattffs
Recent Blog Posts
Surveys can be fun tools for personality quizzes, but I don't really trust their use for anything serious.
Ever wanted to see me react to a YouTube Video? No? Yeah, I probably won't be doing this again.