The Problem Isn't Vibe Coding. It's What Happens Next

Over the last year, we've seen a growing number of clients arrive with working software they've built themselves.

Sometimes it's a workflow created in Claude. Sometimes it's a customer portal built using Lovable. Sometimes it's an internal operations tool that started as an experiment and gradually became part of the business.

The capability of today's frontier AI models is remarkable. What previously required a product manager, designer and engineering team can now be achieved by a single person with a clear problem to solve and a few evenings of persistence.

For businesses, that's a genuinely positive development. Ideas can be explored faster. Processes can be visualised earlier. Teams can interact with something real instead of debating requirements in a document.

The challenge is not the technology. The challenge is understanding where vibe coding ends and software engineering begins.

At Wingspan, there are many situations where we'd actively encourage a client to use vibe coding.

The most obvious is early-stage exploration. Before investing in a software project, it's often valuable to understand what the experience should feel like. A rough prototype can answer questions that would otherwise take weeks of workshops and documentation.

We've also seen significant value in using prototypes to align stakeholders. Rather than discussing hypothetical workflows, teams can interact with a working version and quickly identify what's right, what's wrong and what's missing.

In many cases, the prototype becomes a far more effective communication tool than a slide deck or written specification.

The common thread across all of these examples is simple. The artefact exists to create understanding. It is helping people discover what they want to build.

Problems tend to emerge when a prototype starts doing real work. This usually happens gradually.

• A team builds something useful.
• A few colleagues start using it.
• A new feature gets added. Then another.
• Soon enough, a prototype has become part of the operating model.

At this point, expectations change. The system now needs to be reliable. It needs to handle real data. It needs to support multiple users. It needs to integrate with other systems. It needs to remain maintainable six months from now when nobody remembers exactly how it was originally put together.

This is where we see the biggest misconception around vibe coding. The parts users can see are often very well developed. The interface looks polished. The workflow feels intuitive. The demonstration is convincing. The deeper layers are often much less mature because they were never the focus of the exercise.

That's not a criticism. It's simply a reflection of what the tools are optimised to do.

Think of a vibe-coded prototype like a sponge cake baked to test a recipe. The purpose is to find out whether people like the flavour. It's quick, inexpensive and effective.

The mistake is continually adding layers onto that original cake and expecting it to become a wedding cake. More features are added. More integrations appear. More people start depending on it. The structure underneath never changes.

Eventually, what began as a useful experiment becomes increasingly fragile. Not because the original idea was bad, but because it was never designed to carry that weight.

"We've already built the front end. Can you just do the backend?"

It's a completely reasonable question. From a client's perspective, they've already invested time building something that appears to work. The assumption is that connecting a robust backend should reduce the overall project cost.

Unfortunately, software doesn't work quite like that. The challenge is that architecture is not something that sits underneath the user interface. The front end, backend, data model, integrations and security model all influence each other.

By the time a prototype exists, many important decisions have already been made, whether intentionally or otherwise. When we're asked to build around a vibe-coded front end, we inherit decisions we weren't involved in making. At the same time, we're still judged on the performance of the final product.

That creates a difficult position for both parties. What initially looks like a shortcut often creates more complexity, more risk and ultimately more rework.

This distinction becomes particularly important when deciding what the software is actually for.

Our view is straightforward. The value of a vibe-coded prototype is not the code. The value is the learning.

The workflow has been tested. The user journey has been explored. The business process has become clearer. Those are incredibly valuable outcomes.

When a client decides to move forward, we treat the prototype as a specification rather than a codebase. We take the lessons, decisions and validated workflows and use them to design the production system properly.

In many ways, this is the best of both worlds. The speed of AI-assisted prototyping helps everyone understand what should be built. The engineering process ensures the final system is secure, scalable and maintainable.

Vibe coding has changed the way software ideas are explored. That's a good thing. It allows organisations to move faster, reduce ambiguity and validate concepts before making significant investment decisions.

The mistake is not using vibe coding. The mistake is confusing discovery with delivery.

A prototype can be the fastest way to learn what good looks like. A production system is what happens once you've made that decision.

At Wingspan, we see those as two distinct stages of the same journey. The first helps you discover the right answer. The second ensures you can depend on it for years to come.