Can You Vibe Code a Product?

Vibe coding: It promises digital products from plain English, but fails to deliver. Not for the reasons people think.

TL;DR: No. You can't today, and you won't in a predictable future. I’d be far from discarding it, though.

And no, it's not going to be a piece from an AI-denialist. Don't worry.

Vibe coding, as a term, has made a hell of a career. Upon picking it from multiple sources in early March 2025, I was shocked to learn that it was coined less than a month earlier.

It's even more fascinating how we perceive the power of the concept. Or rather, the technology that's behind it.

No-Code Quest

It's the first time a non-technical person can prompt a tool in plain English and get working software. We are fulfilling the dream of generations of companies. We have finally reduced our dependence on software developers.

For decades, we've been limited by the scenarios that the authors of the tools could predict. That, in turn, meant that we could only go that far.

Microsoft Access in the 1990s provided a graphical interface for databases. But if it wasn't a database you needed, then good luck to you.

In the 2000s, Wordpress allowed the creation of blogs and simple websites. A growing base of plugins further enhanced its capabilities. However, if you wanted a more complex web application, you had to seek elsewhere.

The next decade brought a go-to solution for anything e-commerce (Shopify). One could easily set up an online shop without learning how to code. Should they need to handle unrelated workflows, not much help from Shopify, sorry.

The limitations made sense. After all, the tool (or plugin) vendors needed to predict the scenarios they wanted to cover and program them before someone could generate such a thing.

And now, suddenly, anyone can seemingly tell an AI tool in plain English what kind of app they want, and voila! It's there. Code generation doesn't rely on pre-programmed scenarios. Finally, the revolution has arrived.

Or has it?

Limitations of Vibe Coding

Lovable is one of the vibe coding tools. To make things spicier, it is a darling of the AI and startup worlds, building its revenues like crazy with but a tiny team.

It's not a surprise. You can go there, tell it what you want, and with just a few prompts, you have a working application anyone can access.

That is, given that your idea was something simple and isolated. A blog, maybe, or a simple e-commerce site. But wait, don't we already have dedicated solutions that do just that, but better?

Joking aside, the power of tools like Lovable lies in their flexibility. They won't create as good a blog as Wordpress or as functional an e-commerce site as Shopify, but they can do both and more.

Before you get all hyped, not that much more for now.

I’ve run an experiment with Lovable, trying to build (or rather, trying to have it built for me) a small app. The only tricky part was that the app was supposed to be authorized through an external service (LinkedIn OpenID Connect) and get some data from there.

Long story short, it was a failure, and the integration with an external service was the core reason (here's the longer version if you're interested). Lovable, as for now, doesn't seem to know its way around the LinkedIn API.

If you know anything about software development, that's borderline shocking. APIs are standardized and documented interfaces built explicitly for other software to connect. And we're not talking about something obscure, but one of the biggest social networks we have.

For a human developer, it would be a straightforward task. For a code generation tool, it seems too much.

Future of No Code

"But Pawel, things will change. At the current trajectory, today's problems will be non-issue within months at worst!"

I wholeheartedly agree. In fact, the task Lovable failed at is precisely a task we expect AI agents to cope with soon enough. The agents, we hope, will be able to autonomously communicate with one another through standardized interfaces.

I'd be genuinely surprised if Lovable weren't able to cope with the LinkedIn authorization level of problems a year from now. The whole MCP-based architecture is all about that.

So, once we fill the technical gaps, Lovable will build what I want it to, right? Maybe. Probably. I wouldn't bet huge money on it anyway. Still, I'll probably try again sometime and report.

The thing is, it doesn't matter.

I mean, it does as long as I build something as a pet project and its only client is myself. I firmly believe that vibe coding is—or will be soon—the answer to the vast majority of such scenarios.

- I need an odd bit of software to assist me with my weird scenario.
- Just tell AI to generate it for you! You’re gonna love it!

It won’t be a product, though.

The code does not equal the product. The features do not equal the product.

The product is something that can sustain the business behind it. The borders will be fuzzy, sure, but it will cover at least part of sales and marketing, customer base, communication, and so on.

Vibe coding does not cover any of these.

But that's not why you can't vibe code a digital product.

Technical Debt is a Tough Cookie

A digital product is never done. Well, it is when it's dead. Till then, it requires continuous work.

• There is a continuous stream of expectations coming from existing users, which puts pressure on adding features.

• Competition actively adds new stuff to their products, prompting a race to see whose solution has more things.

• Customers spot issues and bugs and expect the vendor to fix them.

• The technology stack gets outdated and requires updates, too.

• Oh, and taking care of the security of the customers’ data is a never-ending game, as well.

• To make things worse, we make all the changes to the living system, so it lacks the elegance of the original design (given there was any); the product gradually becomes more of a patchwork that enhances all the problems listed above.

The way we address all these challenges is with a lot of judgment from both product people and developers. There are competing interests on the list, and picking either of the radical paths is a bad idea.

If one tries to maintain the highest possible code quality, pure architecture, and a technology stack up to the latest versions, the progress of new work will be glacial.

On the other hand, disregarding that "maintenance" work may initially yield some quick progress, but things will slow down quickly. A lack of consideration for quality will haunt the product with recurring, interconnected issues. Soon, it will all be firefighting, and the progress won't even be glacial. It will grind to a halt.

It's not without a reason we call these code quality trade-offs "technical debt." As with any other debt:

• We incur it either because we have to or because it creates an attractive opportunity.

• Unless we manage it, it gets out of control and ruins us.

OK, that's all good and fine. The software industry probably figured out decent ways to handle technical debt by now. Why would a non-developer vibe coding their product care?

Vibe Coding Meets Tech Debt

Tech debt is a major problem for almost any vibe coding effort. With a pet project used by but a few people, we can safely ignore it. However, in literally every case where we want to build a business around such a product, it's a different story.

Each time we fix a bug or add a feature to a living software, there are decisions we make. How will this new code cope with everything else, what it can break, how much attention we invest in building a safety net, and later testing and validating it?

To make these decisions, we use context from two perspectives:

• Product: how important this task is, who will be using it, what we want to achieve with it, etc.

• Technical: how much effort it requires in different scenarios (higher vs. lower quality, more or fewer guardrails, etc.), how much tech debt we want to pay back when we're around, how much it affects all the other parts of the code base, etc.

Then, we make a judgment call. It can often be a subconscious decision, yet the goal stays the same. We aim to maintain a sustainable balance of tech debt. We want to keep it manageable.

Now, remove the technical context altogether. With vibe coding, we don't have that. A decision will suddenly become completely unbalanced because we have lost a key piece of information.

In reality, it's even worse. AI models, the way they are right now, are notoriously crappy at judgment.

You see, there is no single good answer to the tech debt question.

That's why we rely on the experience and expertise of individuals who know the technology. Vibe coding promised to remove the need to keep them around.

Well, it lied.

"But Pawel, we can tell Lovable to refactor the code."

Oh, good luck with that.

First, it's not something that such tools will be capable of doing well anytime soon.

Second, we'd first need to know when to tell the tool to do it. And we won't know because we don't have technical context.

No Country For Vibe-Coded Products

The current capabilities of vibe coding tools don't justify building a serious product. But that's not the reason why you should disregard this path.

Considering the pace of progress of AI tools, I would expect many of the current technical limitations to be gone soon enough.

However, the judgment gap isn't going anywhere. That's the reason why any attempt to vibe code a product is doomed to stop at the very early stage.

Mounting tech debt will quickly outweigh any gains one can get from generating code.

I admit, it all does sound harsh to the idea of vibe coding. I'm not a downright critic, though. Contextually, I'd consider myself a fan, even.

First, vibe coding is a perfect tool for prototyping.

In the past, we often relied on all sorts of low-tech experiments to gauge people's interest in a specific solution. Building the software just to learn what was wrong with it was, after all, a really expensive way of learning.

Now, we can easily generate a half-assed but nicely looking app that we use for learning. There's value in having a prototype closer to the eventual solution. On that account, a vibe-coded app will be better than low-fidelity wireframes.

Second, I'd be far from underestimating the "pet projects for me and a couple of my friends" category.

I expect a swath of vibe-coded apps that were never meant to become a product. They'll help keep scores in family games, organize a hobby, facilitate someone's individual work style, and do hundreds of other things.

Some of them will show potential for becoming products even. But then, if one dreams of turning an after-hours plaything into a business, we'll still need to turn to teams who know how to do product development.