Vibe Coding Doesn't Replace Tech Skills; It Requires More of Them
Vibe coding may deliver a useful prototype but it's not a way to build a sustainable product. Technical skills remain key to succeed with digital product development.
I have no shortage of exchanges about the validity of vibe coding and how far it can take you. In short, my take is that:
Vibe coding is not a feasible approach for building a product.
It is, however, fabulous for prototyping.
The first part, obviously, triggers many AI enthusiasts. Unsurprisingly, the vast majority of those pissed off have no technical background.
I get it. The enthusiasts may perceive my (and others') reluctance to admit vibe-coding power as the defence of the status quo. After all, software engineers were in a privileged position for decades. And privilege doesn't go down easily.
Vibe Coding Dream
It doesn't help that we keep hearing how vibe coding (and AI-generated code in general) is an answer to product development challenges coming from influential sources.
A side note. One could ask whether the founders of the most prominent AI startups would gain anything if people believed that they could vibe code their way to a billion-dollar company. Like, maybe, they would have so many more clients?
Companies such as Lovable, Bolt, and Replit have centered their strategy on allowing users to generate entire apps. It's their modus operandi to promote AI-generated applications as a viable, feasible, and desirable scenario. They can't back off. Not now, when they grow at record speed, and some predict they might reach a billion dollars in yearly revenues as soon as next year.
With all this buzz, there will be plenty of people trying to vibe code their products. In fact, we already get news on how people have succeeded at that. However, when you look closely, they seem to be more of self-marketing than a sustainable endeavor.
Technical Knowledge Remains Key
The basic premise of vibe coding tools is that a non-technical person will be able to generate working software. That's, however, a vague term.
I had fun getting Lovable to create a simple Wordle-like app with my son for his CS class in a primary school. At Lunar, we use v0 and Bolt to rapidly prototype ideas for our clients. Yet, many people visualize 'working software' as production-grade digital applications that they can run a business on.
The fundamental difference between the two is that in the first case, the code is entirely disposable, while it’s not so in the second. When prototyping, we don't plan to keep the outcome long-term. If you, however, plan to build a business around software, it implies it's there to stay.
For such code bases, technical skills are not optional. I would argue that we might need even more of them than before.
Vibe Coding versus AI-Generated Code
Before I continue, a disclaimer. I make a distinction between vibe coding and code generated by AI tools (either autocomplete or coding agents).
Vibe coding means that I prompt an AI tool describing a product I want to get—its features, how it looks, etc. In this case, I don't even need to see the code (although the tools may allow that).
Conversely, with AI-generated code, I prompt tools describing the outcomes in terms of, well, code—classes, functions, endpoints, data structures, etc. Necessarily, the output artifact is the code itself.
The following argument is not against AI-generated code in general. At Lunar Logic, in some projects, we easily pass the mark of 90% code generated (initially) by AI. The thing is, we are still firmly at 0% code pushed anywhere before a human being carefully reviews it.
Vibe coding flips the script. It promises us that we don't even need to look at, let alone review, the code.
Technical Debt
Anyone who has spent any substantial time in software development knows the term technical debt. These are all the hacks, oversimplifications, and dirty solutions that get the job done, but at the same time make the entire code base unnecessarily complex, less readable, and more vulnerable to interconnected issues. In short, the code becomes less maintainable.
Over time, it becomes more difficult and requires more time to make product changes. Up to a point, when it's impossible to change anything without breaking stuff in random places. And yes, I've seen projects where any progress was brought to a grinding halt because of accumulated tech debt.
That's why continuous effort to pay some of the technical debt back is a part of the job of any sensible developer. It is how we sustain code maintainability in the long run.
That is, unless that developer is an AI vibe coder, and we have no technical skills to review what it does or tell it in detail what maintainable code looks like.
In such a case, we should expect the technical debt to mount at breakneck speed. After all the training data of all these tools weren't only the shiniest and the best code bases there are.
Very soon, any change in an app will break other things. And fixing those things will break some other things or revert earlier changes. It becomes an impossible frustration loop. Any further development is impossible.
Code Quality
But wait, why won't we tell the AI tool to keep code quality high? Oh sure, we can. However, it's not like it understands what "high code quality" means.
When our developers use AI coding agents, the zeroeth step is to prepare coding guidelines. These are fairly extensive amounts of context that explain, in code samples, what we mean by expected code quality.
I'm not a developer anymore for way more than two decades, yet I can handle myself in a general conversation about software craft and architecture. Still, it would be completely inept to think I could prepare decent guidelines of that type.
What's more, AI agents will rarely, albeit routinely, hallucinate something going completely against the guidelines. At this stage, even with the best context, no human supervision means deteriorating code quality over time.
Security
One aspect I was curious about when listening to the CreatorHunter vibe coding story was security. I admit I would have bet that the word won't pop up in the conversation.
I would have lost that bet. CreatorHunter founder, Paulius Masalskas, did, in fact, mention security.
"With a little bit of prompting and some scoring, it will make it secure as well."
Paulius Masalskas
Yup, that's it. Do some prompting and some scoring, and you've got it. Go Attaboy! The only problem is that it's an equivalent of telling the vibe coding tool to "make your app secure."
AI does not have a world model that would allow it to understand what we mean when saying "a secure web app." By parrotting the most popular answers, it will surely get some things correct. However, since there's no such thing as a definitive answer to what constitutes a secure web application, we can't rely on AI to give us that.
Even if there were such an answer, beyond some complexity level, AI coding agents will still hallucinate some insecure stuff.
With no oversight from a human being who can reasonably assess the security of the proposed solution, it will be a slippery slope. Sooner rather than later, a potential vulnerability is guaranteed.
Even More Security
That, however, is not even the start of it. As developers rely more on AI coding tools, we have enabled another whole rabbit hole to fall into.
Historically, vulnerabilities have made their way into software products due to omission. A developer wouldn't know better, or they'd make a subconscious mistake, and they wouldn't make their code secure. Thus, it was vulnerable.
Now, we play a different game. We need as much to fend off insecurity by omission as malicious actions stemming from the existence of AI-generated code. Sure, AI (the way it is right now) is not evil. Evil is an abstract term. Yet black hat hackers, understanding how AI models work, prey on those trying to make shortcuts.
Automatic code updates may mean that malicious code will be added to a repository, and hackers would steal data, get access to the code, and, well, do literally anything they want with the product.
Attackers exploit situations when AI hallucinates non-existent libraries (a minor nuisance) and actually create them, except with malicious code. That guarantees a major security incident.
Hackers create publicly available repositories that contain instructions for AI agents hidden from plain sight. A human reading such a file will notice nothing, while a vibe coding tool will treat it as a legitimate instruction.
To make things worse, coding agents, by design, work in a way to produce output that looks good. Whatever malicious changes they may be introducing will be hidden behind a layer of LGTM code.
If you wondered about my earlier claim that we need even more technical skills than before AI, that's one big reason why. Most definitely, though, not the only one.
Compliance
If you’ve had enough security for the time being, let’s talk compliance. Anyone processing credit cards is a subject of PCI compliance. Sure, but that’s what Stripe is for, right? They do the credit card processing, so they care about PCI compliance, right?
Well, not really. Depending on how we implement the payment processing integration, we’re subject to different levels of PCI compliance. Except when vibe coding, we don’t know how exactly the implementation was done.
Heck, unless we’ve done that ourselves in the past, we neither have the insight to consider that as a potential issue nor know how to ask the right questions.
But hey, what’s the worst thing that can happen? For a business relying on credit card processing in a world where as little as a payment made from an unusual place may trigger KYC procedures, the worst-case scenario is probably an extinction-level event.
And we wouldn’t even know there’s something brewing unless something goes south.
Scalability, Performance, Accessibility
I could make a similar meta argument about almost any aspect that's important for the long-term feasibility of a digital product. Terms such as scaling, performance, or accessibility mean things to developers. They're completely abstract for an AI model. That is, unless you tell it what they mean for you.
Even more so, given that there can be no universal consensus on what scalability or performance means. It is heavily dependent on the context of a specific product.
So, can you vibe code a scalable web application? Well, yes, if you don't need any scale.
And most likely, unless you have a fairly broad technical experience, you wouldn't even be able to ask the right questions write the right prompts.
Should you care, for example, about backup and restore strategy in case your AI agent went rogue and deleted your database? The more technical roles a solopreneur wants to cover with vibe-coding-fu, the more they need to understand that software development has evolved into a quite complex discipline.
They may bring that skill set themselves, in which case, vibe coding may be a losing proposition when compared to AI coding agents, or they may hire it outside, one way or another.
Either way, vibe coding probably won’t be around for too long.
The Minefield
Sure, many of these considerations are irrelevant if you just release an MVP to gauge market interest in your latest idea. But that's that—releasing an MVP that will be disposable.
When any traction appears and the idea turns into something of value, we instantly enter the engineering minefield.
Now, an eager vibe coder will likely move forward obliviously and thus carelessly. Which will make something blow off in their face even sooner than it could have. However, even someone conscious of some (or most) of these risks will inevitably trigger one trap or another.
That's why I'm not holding my breath for multimillion-dollar startups run with no tech expertise whatsoever.
Also, for the very same reasons, I don't think the traction of Lovable (and its competitors) is sustainable. Experts will choose tools that give them more control, either because they want to or because they're forced to. Laypeople will find vibe coding tools lacking and/or frustrating as they see the first signs of validation of their product ideas.
If you liked this essay, it was sparked by CreatorHunter’s vibe coding success story, which doesn’t appear to be entirely what the founder claims.
Here’s a follow-up post that explores the product development side of things.
Thank you for highlighting this!
Had an episode recently where a founder was succumbing to the pressure of building and shipping fast leveraging one of these vibe coding tools. The biggest issue I see is Scalability and functionality beyond the demo. A final product that people will use and love not just admire.
💯