Opinion Vibe coding got a big boost when everyone's favorite open source programmer, Linux's Linus Torvalds, said he'd been using Google's Antigravity LLM on his toy program AudioNoise, which he uses to create "random digital audio effects" using his "random guitar pedal board design."
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?
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.
I used 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.
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 "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."
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 "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.
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."
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 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 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. ®
Source: The register