Just because Linus Torvalds vibe codes doesn't mean it's a good idea
- Reference: 1768562110
- News link: https://www.theregister.co.uk/2026/01/16/linus_torvalds_vibe_coding/
- Source link:
This is not exactly Linux or even Git, his other famous project, in terms of the level of work. Still, many people reacted to Torvalds' vibe coding as "wow!" It's certainly noteworthy, but has the case for vibe coding really changed?
Linus Torvalds tries vibe coding, world still intact somehow [3]READ MORE
With vibe coding, the "programmer" describes their requirements in natural language to an AI model. The LLM then generates the code. Unlike AI pair‑programming tools that assume a human will read and refine every line, in vibe coding, you accept the AI's output largely as‑is and iterate by rerunning and adjusting prompts rather than editing the code.
There's nothing new about this idea of simply telling a computer to write a program for you. Natural language processing (NLP) goes all the way back to Alan Turing in 1950. You may have heard of him.
More recently, in the late '70s and early '80s, which is when I came on the scene, fourth-generation languages (4GLs) appeared. 4GLs were high‑level, usually domain‑specific languages that let you specify what you wanted from a database, such as queries, reports, and displays, rather than how to do it procedurally, with a focus on business data tasks. You'd ask for, say, a sales report, and they'd generate the COBOL or SQL to deliver it.
[4]
I used [5]Adabas/Natural on mainframes to deliver NASA data communication reports back in the '80s. 4GLs are still around, and some, such as SAS and SPSS, remain important in production environments.
[6]
[7]
They never really caught on because they were too brittle. In addition, and this is the important part, describing a program in natural language is not easy. Just ask all the people who have been trying for ages to get low-code/no-code off the ground.
Who knew? Well, AI researcher Andrej Karpathy did. He's the guy who coined the phrase "vibe coding." He described this approach as being " [8]not too bad for throwaway weekend projects ... but it's not really coding – I just see stuff, say stuff, run stuff, and copy-paste stuff, and it mostly works."
[9]
Exactly. That's what Torvalds did. It's fun, and for small projects, it's productive. However, today's programs are complex and call upon numerous frameworks and resources. Even if your vibe code works, how do you maintain it? Do you know what's going on inside the code? Chances are you don't. Besides, the LLM you used two weeks ago has been replaced with a new version. The exact same prompts that worked then yield different results today. Come to think of it, it's an LLM. The same prompts and the same LLM will give you different results every time you run it. This is asking for disaster.
Just ask Jason Lemkin. He was the guy who used the vibe coding platform Replit, which went " [10]rogue during a code freeze, shut down, and deleted our entire database ." Whoops!
Yes, Replit and other dedicated vibe programming AIs, such as Cursor and Windsurf, are improving. I'm not at all sure, though, that they've been able to help with those fundamental problems of being fragile and still cannot scale successfully to the demands of production software.
[11]
It's much worse than that. Just because a program runs doesn't mean it's good. As Ruth Suehle, President of the Apache Software Foundation, commented recently on LinkedIn, naive vibe coders "only know whether the output works or doesn't and don't have the skills to evaluate it past that. The potential results are horrifying."
[12]The Microsoft 365 Copilot app rebrand was bad, but there are far worse offenders
[13]The most durable tech is boring, old, and everywhere
[14]What the Linux desktop really needs to challenge Windows
[15]Bots, bias, and bunk: How can you tell what's real on the net?
Why? In another LinkedIn post, Craig McLuckie, co-founder and CEO of Stacklok, wrote: "Today, when we file something as 'good first issue' and in less than 24 hours get absolutely [16]inundated with low-quality vibe-coded slop that takes time away from doing real work. This pattern of 'turning slop into quality code' through the review process hurts productivity and hurts morale."
McLuckie continued: "Code volume is going up, but tensions rise as engineers do the fun work with AI, then push responsibilities onto their team to turn slop into production code through structured review."
So it is that, while the sheer volume of code being turned in is going up, in no small part because of vibe coding, the quality is going down. This, in turn, puts an ever-growing burden on maintainers who must separate AI slop from high-quality code.
Besides, as the only trustworthy, objective study I've seen to date on the "quality" of AI code, last summer's [17]Measuring the Impact of Early-2025 AI on Experienced Open Source Developer Productivity , found that even experienced programmers using AI tools took 19 percent longer to complete tasks.
That's with professional developers who were not vibe coding. When you've got amateurs who wouldn't know Ada from Zsh trying to talk their way into good code, you're just asking for serious trouble.
So, sure, play with vibe coding. Just don't expect, after the initial excitement has worn off, that you'll end up with anything worth keeping except for the smallest and most trivial of programs. ®
Get our [18]Tech Resources
[1] https://github.com/torvalds/AudioNoise
[2] https://www.theregister.com/2025/01/13/linus_torvalds_guitar_pedal_offer/
[3] https://www.theregister.com/2026/01/13/linus_torvalds_vibe_coding/
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/aiml&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2aWpuvnTX7jwD_MtPnvYcGQAAAIM&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[5] https://www.softwareag.com/en/adabas-natural/
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/aiml&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aWpuvnTX7jwD_MtPnvYcGQAAAIM&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[7] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/aiml&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33aWpuvnTX7jwD_MtPnvYcGQAAAIM&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[8] https://www.theregister.com/2025/10/21/book_review_vibe_coding/
[9] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/aiml&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aWpuvnTX7jwD_MtPnvYcGQAAAIM&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[10] https://www.theregister.com/2025/07/21/replit_saastr_vibe_coding_incident/
[11] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/aiml&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33aWpuvnTX7jwD_MtPnvYcGQAAAIM&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[12] https://www.theregister.com/2026/01/09/microsoft_365_copilot_app/
[13] https://www.theregister.com/2025/12/31/long_lived_tech/
[14] https://www.theregister.com/2025/12/22/what_linux_desktop_really_needs/
[15] https://www.theregister.com/2025/12/05/bots_bias_bunk/
[16] https://www.linkedin.com/posts/craigmcluckie_coding-agents-are-crippling-oss-communities-activity-7417250625391915009-pcbA/?utm_source=share&utm_medium=member_desktop&rcm=ACoAAAAAKH4BBvA-ZwpVFbaZDTqwLgneEpGsrHQ
[17] https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
[18] https://whitepapers.theregister.com/
Re: Synthetic Take: Why Vibe Coding Isn’t “Just for Toys”
The vast majority will give up after finding that the original "conjuring trick" is not sustainable, but perhaps a few will discover that it is hard to do programming well, and see an opportunity for learning to do it properly . . . we can hope!
BTW I am not converted, just looking for a silver lining.
Re: Synthetic Take: Why Vibe Coding Isn’t “Just for Toys”
Prototyping and code spikes absolutely are real work, as you say, and prototypes may be one of the few serious software cases for vibe coding (code spikes aren't because a critical part of that process is the developer learning how to use the tools and a developer learns nothing if they don't use the tools.)
The important thing about a prototype, and the one that is misunderstood far too frequently by managers who see them, is that they have to be discarded. Trying to munge a prototype into production-ready code is almost always both worse and slower than just writing it clean. Vibe coding your prototype might bring up the prototype faster and make building it properly slower because you haven't learnt anything from the prototyping process, but it is even more important that a vibrototype is discarded because you cannot risk having any code you do not fully understand in a production code base.
Re: Synthetic Take: Why Vibe Coding Isn’t “Just for Toys”
What do you mean the boss sold the demo *again*?
Re: Synthetic Take: Why Vibe Coding Isn’t “Just for Toys”
So very much this. The sign of a successful prototype is that you've thrown it away! Unfortunately, it is very difficult to get engineers (even good ones) to adopt this approach, and even more difficult to sell to management (just polish the edges and put it into production).
Re: Synthetic Take: Why Vibe Coding Isn’t “Just for Toys”
The same could be said for script kiddying. Why isn't being called a vibe coder as pejorative as being called a script kiddy? The script kiddy required more knowledge & skill.
Re: Synthetic Take: Why Vibe Coding Isn’t “Just for Toys”
Script Kiddying isn't enough, nor is vibe coding.
Now they have "Ralph Wiggumming" [1]https://devinterrupted.substack.com/p/inventing-the-ralph-wiggum-loop-creator
Personally I think "vibe coing" is a ridiculous term, which doesn't make any sense so I don't use it.
I do use the AI tools and they are extremely effective. Saying as much round here seems very triggering though. It's like there's something threatening to eat people's lunches. It's not.
[1] https://devinterrupted.substack.com/p/inventing-the-ralph-wiggum-loop-creator
Re: Synthetic Take: Why Vibe Coding Isn’t “Just for Toys”
Full disclosure — that whole comment was generated by Copilot and not edited. Vibe commenting. The long dash should have given it away. Could anyone tell?
Re: Synthetic Take: Why Vibe Coding Isn’t “Just for Toys”
Actually no - but I have no idea from the context (or do I) whether it is assembling word-by-word or lifting whole paragraphs at a time from a "relevant" article.
Even if I _were_ "convinced" by that fragment, I'm pretty sure if I played the "game" I would discover that pretty quickly that I was talking to a magic 8-ball.
Re: Synthetic Take: Why Vibe Coding Isn’t “Just for Toys”
You can do plenty of useful work using some of the new tools like Antigravity or Opencode. And you absolutely can put the output into production assuming the appropriate level of testing.
Is it better or faster than a human being? It's different. And it still requires a human being.
The experience/output is improving very quickly.
There are problems with it like the monoculture/feedback loop, what it might do to careers longer term and the need to rabidly consume the earths resources at an alarming rate, but I'm sure that'll get figured out at some point because "capitalism".
Re: Synthetic Take: Why Vibe Coding Isn’t “Just for Toys”
The key distinction is learning the difference between using an LLM as a tool and using it as a sub-contractor (and blindly signing off its work unchecked)...
I am reminded of the "dog and pony show" that accompanies every new IDE.
Visual Basic had controls to access a database!
But not for anything other than the simplest cases. Anything even slightly odd and you had to build it custom from scratch instead.
I'm not even sure it's good enough for trivial projects either, I was recently convinced to try it (for a hobby project) and while it got the application up and sort of working, the problems and mistakes were just compounded after attempts to persuade it to fix them, I'd absolutely not trust it for anything to put in production.
Eventually it gave up and just produced lots of error messages.
The documentation it produced was also utter fantasy, when told it had made a very specific error in one part and given the correct information to fix the prpblem it agreed, then produced output that was even less accurate.
All in, it was faster to find (steal) bits of example code on GitHub/the web and write the rest myself instead of tracking down the ridiculous errors.
These tools have got me thinking hard about what software development is as an activity, and I think learning is an essential part of it. We're always learning how to solve the next problem or use a new tool and building up our internal library of well-understood strategies for future use. Looking at it this way, code generators that allow one to bypass learning altogether feel like a dead end.
"amateurs who wouldn't know Ada from Zsh trying to *talk* their way into good code"
Presumably they cannot use the keyboard because they find their elbows are firmly wedged up their arses.
amateur is (mis)used in the common modern sense of one unskilled or unprofessional rather than the literal sense of one who loves.
Just because Linus Torvalds vibe codes doesn't mean it's a good idea
Yeah, I was kind of disappointed when he gave systemd the thumbs up too.
Synthetic Take: Why Vibe Coding Isn’t “Just for Toys”
The “vibe coding isn’t for serious work” argument kind of collapses when you remember that tons of major software projects started as experimental hacks. Vibe coding with an LLM just speeds up the exploratory phase that serious engineering already depends on. It’s not a replacement for reviews, testing, or rigor — it’s a turbocharged brainstorming mode. Calling it “not for real work” misunderstands what real work actually looks like.