Linus Torvalds on Vibe Coding: Fine for Learning, Terrible for Production
Linus Torvalds calls vibe coding ‘fairly positive’ for learning but ‘horrible’ for production. Why the Linux creator’s maintenance warning…
Linus Torvalds calls vibe coding ‘fairly positive’ for learning but ‘horrible’ for production. Why the Linux creator’s maintenance warning matters for your code.
Over three decades of kernels. Billions of devices.
The creator of Linux has watched every coding trend come and go. His verdict on AI-assisted “vibe coding” cuts through the hype.
At the Linux Foundation Open Source Summit in Seoul, Linus Torvalds gave the most balanced take on AI coding I have heard from any industry veteran. He called vibe coding “fairly positive” for newcomers learning to program. Then, in the same breath, he labeled it a “horrible, horrible idea from a maintenance standpoint” for production systems.
Two decades in this industry taught me to pay attention when Torvalds speaks. Not because he is always right. Because he has been wrong about things publicly and changed course. That intellectual honesty is rare.
The term “vibe coding” emerged from Andrej Karpathy’s viral post about prompting AI to write entire applications without really understanding the generated code. You describe what you want. AI produces something. You tweak prompts until it works. Ship it.
For personal projects? Maybe fine. For the Linux kernel running your servers, phones, cars, and medical devices? Let me tell you why Torvalds is absolutely correct.
If you found this perspective valuable, consider leaving a clap. It helps others discover this content.
What Torvalds Actually Said
The subtle point in Torvalds’ position gets lost in the headlines. He did not say AI coding tools are useless. He did not condemn them entirely. He made a distinction that experienced engineers understand on instinct but rarely say out loud.
“I think it’s fairly positive that vibe coding means that anybody can get a computer to do something that they otherwise couldn’t have done,” Torvalds explained during the summit interview. For newcomers, for learning, for experimentation, AI tools lower barriers. Someone without formal training can build a working prototype. That democratization matters.
Then came the qualifier.
“But from a maintenance standpoint, vibe coding is horrible, horrible. Because you don’t understand what you’re doing.”
This is the key distinction. Production code lives for years, sometimes decades. The Linux kernel has code from the 1990s still running. Someone has to fix bugs in that code. Someone has to adapt it when requirements change. Someone has to understand it when production goes down.
Torvalds put it bluntly: using vibe coding for critical systems like the Linux kernel would be “a bad idea” because long-term maintainability requires deep understanding.
Why Most Software Work Is Maintenance
Writing code is maybe 20% of the work. Studies consistently show that 60 to 80 percent of software costs go to maintenance, debugging, extending, and eventually replacing code. Non-engineers miss this entirely.
I have inherited codebases where the original developer “vibed” their way through framework documentation. The code worked. Until it did not. And nobody understood why. Debugging sessions turned into archaeology expeditions.
AI-generated code makes this problem worse. When a human writes confusing code, at least some thought process existed. Some mental model, however flawed, guided the decisions. AI-generated code has no thought process. It is a statistical pattern match against training data.
When that pattern match produces something that works but contains subtle assumptions you do not understand, you have created technical debt with interest rates you cannot calculate.
The kernel community reviews every single line of code that enters the mainline. Human reviewers catch bugs that tests miss. They catch design decisions that will cause problems five years from now. They catch security vulnerabilities that automated tools do not recognize.
What happens when the code under review was generated by someone who cannot explain why they wrote it that way? Because they did not write it. They prompted for it.
If this connects with your own experience maintaining code, drop a clap. Let me know I am not alone in this.
Learning vs Production
Torvalds draws a clear line: experimentation and learning on one side, production systems on the other. This distinction matters more than most debates about AI tools acknowledge.
For learning, AI assistance has genuine value. A newcomer can build something functional, see immediate results, stay motivated. The feedback loop tightens dramatically. Instead of spending weeks understanding boilerplate, they can focus on concepts.
I would argue this has limits too. If you never understand the boilerplate, you never understand why certain patterns exist. But that is a pedagogical debate, not a dismissal of the approach entirely.
For production, the calculation changes completely.
Production code must handle edge cases the original developer never imagined. When users find bugs (they always do), someone must trace execution paths through unfamiliar territory. When security vulnerabilities emerge, fixes must be precise and confident.
Vibe-coded production systems create a terrifying scenario: code that works until it does not, maintained by people who cannot explain why it ever worked.
The Linux kernel handles memory management for billions of devices. A subtle bug in memory allocation can crash phones, corrupt data, enable exploits. Understanding is not optional. It is the difference between reliable systems and ones that fail in ways nobody can diagnose.
Torvalds Practices What He Preaches
What makes Torvalds’ position credible is that he tried vibe coding himself. For his AudioNoise project, a side project for random digital audio effects, he noted that the Python visualizer component was “basically written by vibe-coding” while the core C audio filters were manually written.
This is important. He is not condemning AI tools from ignorance. He used them. Found them useful for specific purposes. And still concluded they are inappropriate for production systems.
The side project versus kernel distinction mirrors how I think about these tools. Personal automation scripts? Sure, let AI help. Quick prototypes to validate ideas? Absolutely. Production systems that must be maintained, debugged, and secured for years? Write code you understand.
Torvalds has spent decades reviewing code from thousands of contributors. He has seen every pattern of failure that poorly understood code produces. His position comes from direct, painful experience with what happens when maintainability gets sacrificed for short-term productivity.
Where I Agree and Where I Push Back
I agree with Torvalds on production code. Completely. The maintenance burden alone makes vibe coding untenable for systems that matter.
But I would push back slightly on the learning side. My concern: if newcomers learn to code entirely through AI prompting, they miss foundational understanding that becomes necessary later.
Debugging requires mental models. Knowing why something works helps you figure out why it stopped working. If your only skill is prompting AI until something compiles, you lack the foundation to troubleshoot when the AI suggestions stop helping.
I have seen junior developers hit this wall. They can prompt their way to working code. They cannot explain what that code does. When bugs appear in areas the AI has not seen before, they freeze.
The answer is not to avoid AI tools. The answer is to use them as supplements to learning, not replacements for it. Write code manually first. Understand concepts. Then use AI to accelerate implementation of things you already comprehend.
This is the path that produces engineers who can eventually maintain production systems. Not prompt engineers who are helpless when the AI hallucinations compound into system failures.
The Bigger Industry Context
Torvalds’ comments arrive at an interesting moment. Venture capital pours billions into AI coding tools. Companies sell productivity gains measured in generated lines of code. Entire platforms promise developers will 10x their output.
Maintenance costs never make the pitch deck.
The Linux kernel community, by contrast, prioritizes long-term maintainability over short-term productivity. Patches that work but are hard to understand get rejected. Code clarity matters as much as correctness.
This philosophy served the kernel well for over three decades. The codebase evolved, adapted, grew. Contributors came and went. The system remained maintainable because understanding was always valued over cleverness.
AI tools represent the opposite philosophy. Ship fast, figure it out later. Generate first, understand never.
For startups that might not exist in three years, maybe that tradeoff makes sense. For infrastructure that billions of devices depend on? The kernel approach wins every time.
If this analysis shaped how you think about AI coding tools, a clap helps more people see it.
Practical Takeaways
Based on Torvalds’ insights and my own experience, here is how I approach AI coding tools.
Use AI for: Learning new languages or frameworks. Generating boilerplate you already understand. Prototyping ideas quickly. Personal scripts and automation. Exploring unfamiliar APIs.
Avoid AI for: Production code you or your team will maintain. Security-sensitive systems. Infrastructure other systems depend on. Anything someone will debug under pressure.
Always require: Understanding of what you deploy. Code review by humans who comprehend the implementation. The ability to explain every line if asked.
The future probably holds better AI tools with better explanations. Maybe we will reach a point where generated code comes with sufficient context that maintenance becomes feasible.
We are not there yet. And the kernel maintainer who has seen every failure mode in software development thinks we should be careful.
I think he is right.
I am a human writer who gets motivated to write more with your support! You don’t need to pay. I just need your clap 👏 if you like my story and comment ✍️ if you want to say something. You can follow me on Medium, LinkedIn, Instagram and X.