Tools like Lovable are making it easier than ever to turn an idea into working software. Instead of starting with static wireframes or lengthy specifications, you can describe what you want and see a functional prototype appear almost immediately.

That is impressive, obviously. But it also raises a more interesting question for a software studio like ours: if anyone can build software, what exactly are developers still there for?

We sat down with Elon Mulder, Technical Product Lead at Hatch, to talk about where he sees the real potential of vibe coding, where things tend to get more complicated, and why making software easier to build does not necessarily make good software easier to build.

Getting ideas out of people’s heads

One of the things Elon is genuinely enthusiastic about is also probably the most obvious use case for tools like Lovable: getting from an idea to something tangible much faster.

Clients have always come to us with ideas, but explaining exactly what you have in mind is surprisingly difficult when the thing itself does not exist yet. Traditionally, that meant translating those ideas into wireframes, designs and prototypes before anyone could actually click through them and say, 'yes, this is what I meant!' or, equally useful, 'no, absolutely not.'

Lovable shortens that loop considerably. As Elon puts it, “It helps people get an idea out of their head and into something that works, so they can tell their story.” And for discovery, that is incredibly valuable: you can make assumptions tangible much earlier, have better conversations around them and potentially learn that something is a bad idea before spending months building it.

But the more interesting question is what happens after that...

A prototype is not automatically a product

Because there is an obvious temptation when your prototype already looks remarkably like a finished product: why not just keep building?

And sometimes, according to Elon, there is no particularly good reason not to. A simple website, an application that collects some data or a relatively straightforward internal tool may be perfectly suitable for that approach. The line becomes less comfortable once the software is no longer something your business uses, but something your business actually depends on.

The problem is that what you see on the screen only tells you so much about what has been built underneath it. Two applications can look virtually identical while being very different in the way their architecture, security or data have been handled; differences that may not matter much during a demo, but tend to become considerably more interesting six months later when something breaks.

That is also where Elon makes a distinction between simply vibe coding and what is increasingly being called vibe engineering. A technically experienced person can use exactly the same tools, but prompt them with an understanding of how the architecture should work, which security considerations matter and where problems are likely to appear later on.

“If you have the right person behind the tool, you're going to have a much better outcome.”

In other words, lowering the barrier to building software does not automatically remove the value of knowing how software works.

The uncomfortable part tends to come later

This becomes particularly relevant once software has been around for a while.

Elon has spent enough years in software development to recognise the scenario: you build something, launch it, nobody touches it for a while and then, one perfectly ordinary Tuesday, the client asks for three new features. You open the project again and discover that libraries have become outdated, dependencies have changed and getting the thing to run is suddenly a project in itself.

AI can undoubtedly help fix those things. The catch is that you still need to know that they need fixing.

The same applies when you ask a tool to change an existing application. It may make exactly the change you requested and inadvertently affect something elsewhere in the codebase. Without proper testing, something Elon points out is not simply included by default when you generate a Lovable project, you may not even notice until someone runs into it.

None of this means that vibe-coded products are inherently bad. It does mean that “it works” is a rather limited definition of software quality.

Software is still built for people

There is another part of product development where Elon is reluctant to hand over the reins too quickly, and interestingly, it has little to do with code.

“We build software for people. So you need people to build something for people.”

A tool can generate a perfectly reasonable user flow, but whether that flow actually feels right is a different question. Is it obvious what you are supposed to do next? Does an interaction make sense when you are holding the phone in your hand? Is the product accessible to someone with a physical limitation? Does the haptic feedback feel right?

AI can recognise patterns in how interfaces are typically constructed, but that is not quite the same thing as experiencing them. And, at least today, it quite literally does not have the fingers to find out.

It is a small distinction, perhaps, but an important one when increasingly more products can be generated from the same underlying patterns. Making something that looks like software is becoming remarkably easy. Making something that feels considered is still a different exercise.

So, are we actually going to build faster?

Almost certainly. Just perhaps not in the way the hype sometimes suggests.

Elon expects AI to remove a considerable amount of the repetitive work involved in setting up and building software. Scaffolding, boilerplate and other relatively predictable tasks that could previously take developers days can increasingly be delegated and completed in minutes.

But the thinking does not disappear with them. Someone still has to decide how the product should work, why it should work that way and how all the pieces fit together before AI can start executing those decisions. If anything, Elon sees that distinction becoming more pronounced: humans decide what needs to happen; AI increasingly helps with how it gets done.

His view on that shift is refreshingly uneventful: “AI shouldn't replace people. It should change the way people work.”

And that may actually make experienced engineers more valuable rather than less. When producing code becomes cheaper, being able to recognise whether that code is any good becomes considerably more important. Senior engineers have spent years learning which architectural choices come back to haunt you, which APIs behave differently than expected and which seemingly innocent shortcuts eventually stop being innocent.

Or, as Elon puts it, they can “distinguish the good from the bad.” Not because AI cannot produce good code, but because experience gives you the context to recognise when it hasn't.

About that dragon

So where does that leave the developer?

Probably less occupied with manually producing every piece of software and increasingly responsible for directing, questioning and reviewing what gets produced. Critical thinking, in Elon's view, remains the constant throughout the entire lifecycle of a product, because however good the model becomes, the people delivering the software are ultimately still accountable for what ends up in the hands of the client.

Towards the end of our conversation, Elon found a considerably better metaphor for all of this than we did:

“AI is often a dragon. If you just let it do its thing, a lot can go wrong. Someone really needs to sit on top of it, hold the reins and make sure it goes in the right direction and doesn't burn down a village along the way.”

Which, admittedly, makes dragon rider a far more interesting job description than software developer.