What Linus Torvalds and a hobby project reveal about the changing nature of understanding.
Reading Time:
There’s a moment in every technological shift where the thing that seemed impossible becomes so mundane that we almost miss its significance.
In January 2026, Linus Torvalds—creator of Linux and Git, famously skeptical of most things—casually mentioned in a README file that he’d built part of AudioNoise, his hobby audio effects project, by just describing what he wanted to an AI. No manual coding for the Python visualization layer. Just natural language descriptions that became working code.
The internet, predictably, lost its mind. “Even Linus is vibe coding now!” But I think we’re missing the more interesting story here. This isn’t about adoption rates or tool capabilities. It’s about something deeper: we’re watching the boundary between thinking and implementation dissolve, and we haven’t quite figured out what that means for understanding itself.
The Abstraction We Didn’t See Coming
Let’s start with what “vibe coding” actually is, because the name makes it sound less serious than it deserves.
Traditional coding: You think in syntax. You translate intent into implementation line by line. You debug typos. You remember whether it’s currentDate or current_date in whichever language you’re using today.
Vibe coding: You describe outcomes. The AI generates code. You run it, evaluate it, refine your description. You focus on what you want, not how to build it.
Andrej Karpathy—who coined the term in early 2025—called it
“fully giving in to the vibes, embracing exponentials, and forgetting that the code even exists.”
By year’s end, Collins English Dictionary named it their Word of the Year.
But here’s what makes this actually interesting: it’s not a new tool. It’s a new abstraction layer.
Every major leap in programming has been about raising the level at which we think. We went from machine code to assembly to high-level languages to frameworks. Each time, we traded directness for expressiveness. Each time, skeptics worried we’d lose something essential. Each time, they were both right and wrong.
Vibe coding is that pattern again, but faster and stranger. Because this time, the abstraction layer is language itself.
What Linus Actually Did (And Why It Matters)
Let’s look at what Linus actually did with AudioNoise, because the nuance matters.
He hand-coded all the C logic. All the digital signal processing. All the mathematical filters for audio manipulation. The parts that require deep understanding of how analog circuits work, how signals transform, how filters behave—he wrote every line himself.
But the Python visualization? He described it to Google’s Antigravity and let it generate the code. As he put it:
“I know more about analog filters—and that’s not saying much—than I do about Python.”
This isn’t someone abandoning expertise. This is someone choosing where to apply it.
The parts that matter—the signal processing, the core logic—he owns completely. The parts that are mechanical translation of visual intent into matplotlib boilerplate? He delegated those.
And then, characteristically blunt, he added:
“Vibe coding is fine for getting started, [but it’s a] horrible idea for maintenance.”
This is the distinction that matters. Linus didn’t stop thinking about the hard problems. He stopped typing the easy solutions.
The Gap Between Working and Understanding
Here’s where it gets uncomfortable.
In May 2025, a security researcher scanned 1,645 web applications built with vibe coding tools. 170 of them—about 10%—had critical vulnerabilities that exposed user data to anyone who knew where to look. Names, emails, API keys, sometimes medical records or financial information.
The issue? Missing database access controls. The apps worked. They had login screens, user profiles, data persistence. They looked secure. But the underlying permissions were misconfigured in ways that only someone who understands authorization would catch.
Later analysis found even worse numbers: 2,000+ vulnerabilities across 5,600 applications. Twenty percent had critical security misconfigurations.
The AI generated code that looked right. It followed patterns from its training data. It produced functional applications. But the AI not yet understands the difference between “this compiles” and “this is secure.” It can’t, yet, automatically (without specific prompting and tweaking) see the bigger picture of how systems actually behave under adversarial conditions.
This is the tension at the heart of vibe coding: We’ve democratized capability without democratizing understanding.
Someone can now build a fully functional web application without understanding authentication, authorization, SQL injection, or any of the ways software fails in the real world. The code works until it doesn’t. And when it doesn’t, the failure is catastrophic.
But here’s the thing—this isn’t actually new. We’ve always had this gap. People shipped bugs they didn’t understand. Copy-pasted Stack Overflow solutions introduced vulnerabilities. The difference now is scale and speed. You can create a broken system in an afternoon instead of a month.
The Question of Responsibility
This brings us to the harder question: When the tool gets smart enough to do the work, what’s left for us to do?
The easy answer is “review and understand everything the AI generates.” But that’s not quite right, because it assumes the human developer could write that code themselves if needed. And increasingly, that’s not true.
CNBC reporter Deirdre Bosa—who describes herself as having “zero technical experience”—used AI tools to build the “Evade-o-Meter,” a system that analyzes corporate earnings calls in real-time and flags when executives dodge questions. She built it during a TV segment. It works. She uses it professionally.
Did she review the code? In what sense? She can’t read Python or JavaScript. She evaluated it the only way she could: Does it do what I intended?
This is the new paradigm. The responsibility isn’t “understand every line of generated code.” It’s “understand the problem deeply enough to know when the solution is wrong.”
That’s actually harder than it sounds. Because evaluating outcomes requires a different kind of knowledge than implementing solutions. You need to understand edge cases. Failure modes. What happens when users do unexpected things. What “correct” even means in context.
We need to think clearly about the problem, even if we’re not typing the solution.
The Lazy Productivity Trap
Here’s what I worry about: the seductive comfort of looking productive without actually thinking.
It’s incredibly satisfying to describe a feature and watch code materialize. To see a working prototype in minutes instead of days. To move fast and ship things. The dopamine hit is real!
But there’s a difference between expressing ideas quickly and thinking clearly about problems. And I think we’re at risk of confusing the two.
The best use of vibe coding I’ve seen follows this pattern:
- Think deeply about the problem
- Sketch the architecture by hand (or with some LLM assistance)
- Consider edge cases and failure modes (can brainstorm with LLM if clear context can be provided)
- Then use AI to handle the mechanical implementation
The worst use skips straight to step 4. Describe a vague idea, let AI generate something, see if it seems to work, ship it. No deep thought about what could go wrong. No consideration of edge cases. Just rapid execution of half-formed ideas.
Simon Willison put it well: “If an LLM wrote every line of your code, but you’ve reviewed, tested, and understood it all, that’s not vibe coding—that’s using an LLM as a typing assistant.”
The distinction matters. One keeps your mind sharp. The other lets it atrophy.
What Actually Requires Thinking?
So where should we focus our human attention? What parts of creation can’t be abstracted away?
Problem definition. AI is excellent at implementing solutions. It’s terrible at figuring out what problem actually needs solving. That requires understanding people, context, constraints, trade-offs. That’s still deeply human work, at least, for now.
Architectural decisions. How should systems fit together? What are the boundaries between components? Where should data live? These aren’t coding questions. They’re design questions that shape everything downstream.
Edge cases and failure modes. What happens when the network drops mid-transaction? When two users try to edit the same data simultaneously? When someone tries to game your system? AI generates happy-path code. Humans need to think about the unhappy paths, collaborating with AI can be helpful (with caution).
Security and privacy. This isn’t just about technical controls. It’s about understanding threat models, thinking adversarially, knowing what’s at stake. AI can implement security patterns, but it can’t make security judgments without talking to you.
Maintenance and evolution. Code lives long after it’s written. What happens when requirements change? When you need to debug something six months later? When a new developer needs to understand how it works? That requires intentional design for comprehensibility.
These are the parts that actually matter. And here’s the interesting thing: none of them require typing code.
The Emerging Role
I think we’re watching a role shift, not a job elimination.
The old developer role: Translate requirements into implementation. Write code. Debug code. Refactor code. Think in algorithms and data structures.
The emerging role: Define intent clearly. Provide context. Evaluate outputs. Make architectural decisions. Understand when to trust AI and when to dig deeper.
Some people are calling this the “Orchestrator” role. You’re not typing less code because you’re lazy—you’re operating at a higher level of abstraction.
But—and this is crucial—operating at a higher level of abstraction still requires understanding the lower levels. We can’t evaluate whether generated code is correct if we don’t understand what correct means. We can’t spot security issues if we don’t know what they look like. We can’t make good architectural decisions without understanding how the pieces actually work.
The abstraction doesn’t eliminate the need for expertise. It changes where we apply it.
What We Risk, What We Gain
Here’s the tension I keep coming back to:
What we gain: The ability to focus on problems instead of syntax. Reduced friction between idea and execution. More time for thinking about product, design, user needs. The democratization of creation—people who couldn’t code can now build things.
What we risk: Losing the practice of deep thinking. Creating a generation of builders who know how to describe solutions but not how to construct them. The gap between “it works” and “I understand why it works.” Lazy productivity that mistakes motion for progress.
I don’t think the answer is to reject AI coding tools. That’s fighting the wrong battle. The answer is to be intentional about where we apply our human attention.
Use AI for boilerplate. For CRUD operations you’ve done a thousand times. For UI components with standard patterns. For the mechanical translation of clear intent into working code.
But don’t outsource thinking about the problem. Don’t skip the step where we sketch the architecture. Don’t delegate understanding of why a solution works or fails.
The tool should amplify our thinking, not replace it.
Where This Goes
By late 2026, analysts predict 90% of code in new projects will be AI-generated. Not assisted—generated.
That doesn’t mean 90% fewer developers. It means developers doing different work. More architecture. More evaluation. More security thinking. More product judgment.
The companies that win may not be the ones with the most AI tools. They’ll be the ones who figure out the right balance—when to generate, when to hand-craft, when to review deeply, when to trust. Like what I heard in a Google DevFest workshop in 2024
“as a CTO, you are essentially deciding what to buy and what to build.”
And, yes, now you are your own CTO.
The valuable part was always the thinking. The problem-solving. The judgment about what to build and why.
AI didn’t eliminate that. It just made it impossible to hide behind the illusion that typing code was the same as thinking clearly about problems.
Linus Torvalds used vibe coding for a throwaway visualization in a hobby project. He’s not using it for Linux kernel development. He chose exactly where abstraction helps and where it hurts.
Maybe that’s the model: embrace the tools, but stay intentional about where we apply our understanding.
The abstraction is here. The question is whether we use it to think more clearly, or to stop thinking at all.
Thought Bytes 
Leave a comment