Beyond Vibe Coding

AI has completely changed what is possible when it comes to building technology. Things that once required a developer, a product consultant, a detailed brief and a significant investment can now be brought to life in minutes. You can describe an idea in plain English and watch AI turn it into a working interface before your eyes.

Watch the whole recording here.

That is incredibly exciting. It is also where we need to be careful.

The biggest shift I see isn’t simply that code has become easier to create. It’s that more people can now participate in creating technology. Business owners, founders and people with deep industry knowledge can take an idea that has been sitting in their head for years and actually start doing something with it.

But easier access to code doesn’t automatically mean better technology. Knowing what to build is still the hard part.

I’ve spent close to two decades working in technology, and one of the biggest lessons I’ve learned is that the most expensive projects are the ones that don’t work. It doesn’t matter how impressive the technology is if nobody needs it, nobody uses it or it doesn’t create enough value to justify the investment.

I learned that lesson properly about a decade ago.

We were working with a large multinational organisation that wanted a new way to deliver education into developing markets. There was an exciting piece of gesture-based technology available at the time, and the concept felt innovative. We designed the screens, built online and offline functionality, created syncing capabilities and spent about a year developing what was genuinely a very clever piece of technology.

Then it was taken to potential customers.

Not one person bought it.

The problem wasn’t our ability to build it. The problem was that we had started building before we had enough clarity around whether people actually wanted it.

That experience changed the way I think about software. We stopped asking, “Can we build this?” and started asking much harder questions. Who is it for? What problem are we solving? How important is that problem? What does the user actually need? What would make this commercially worthwhile? What does success look like?

AI hasn’t made those questions less important. If anything, it has made them more important because it is now so easy to skip them.

I demonstrated this by asking an AI tool to create a simple sales pipeline interface. Within a couple of minutes, it had produced a working Kanban-style board with example data and drag-and-drop functionality. Years ago, even getting to that visual stage required considerably more effort.

That’s powerful because a prototype helps people see an idea rather than just talk about it. You can put something in front of a colleague, customer or stakeholder and ask, “Is this what you imagined?” You can test assumptions before investing heavily.

The danger comes when we confuse a prototype with a product.

There’s a dopamine hit that comes from seeing something appear so quickly. You have an idea, type a prompt and suddenly there’s something on the screen. So you add another feature. Then another. Then you hit a problem, change direction, add something else and before long you’ve spent hours prompting an idea into existence without ever deciding exactly what “done” looks like.

That’s why I keep coming back to planning first.

Before you start building, define the outcome. What are you trying to create? Who is it for? What problem does it solve? What are the important business rules? What does the basic user journey look like? What are the exceptions? Most importantly, what has to be true for you to say, “Yes, this is finished and it does what we need it to do”?

AI performs much better when it has context. A vague prompt gives it room to make assumptions. A structured plan gives it something meaningful to work from.

In our own work, we’ve been exploring how AI can help accelerate that planning process as well. Rather than starting with code, we start with the idea and unpack it. We look at the problem, the users, the stakeholders, the requirements, the business rules, the flows and the individual capabilities the product needs.

Think of a software product like a jigsaw puzzle. Login might be one piece. Reporting might be another. Creating a note might be another. Summarising those notes might be another. Instead of asking AI to magically build the entire puzzle, we define the pieces and then build them in a structured way.

That is where I think the real opportunity sits. Not in removing thinking from software development, but in using AI to accelerate the journey from thinking to something tangible.

We’re already seeing non-technical people do remarkable things this way. We’ve had people come to us after building a substantial portion of a tool themselves, then ask us to help make it robust enough for real-world use. One person built an invoice management system that could take invoices from an inbox and feed them into an existing business system. They weren’t a developer. They simply knew their industry, understood the problem and were willing to spend the time learning how to create a solution.

That’s a major change.

It doesn’t mean everyone should start building their own CRM tomorrow.

The build-versus-buy question still matters. In many cases, buying existing software remains the smartest option. There are thousands of established products solving common business problems, and rebuilding something that already works may create more complexity than value.

Where I would start is with the gaps.

Look around your business. There’s probably a spreadsheet everyone hates. There might be a process trapped in emails. Perhaps somebody manually prepares the same report every week or every month. Maybe you have valuable intellectual property sitting inside people’s heads that could be turned into something more useful.

Those are interesting places to experiment.

Start small. Build a simple interface over existing data. Create a better reporting tool. Prototype an idea you’ve struggled to explain. Look for an operational process consuming too much time and see whether technology could make it easier.

Small is important because the risk changes dramatically once something touches customers or sensitive business information.

A prototype sitting on your laptop is one thing. A customer-facing application handling personal information, payments, confidential data or critical business processes is something very different. Security, privacy, reliability, testing, architecture and ongoing ownership suddenly matter.

This is where experienced technical support still has an important role. AI can help you travel much further on your own than you could a few years ago, but there is still a point where knowing what you don’t know becomes critical.

So I wouldn’t encourage a non-technical business owner to vibe code an application, connect it to sensitive customer data and send it live. I would absolutely encourage them to use these tools to explore, prototype, test and get ideas out of their head.

That distinction matters.

The opportunity in front of us is enormous because the barrier between an idea and something tangible has collapsed. The people who benefit most won’t necessarily be the ones who generate the most code. I think they’ll be the ones who understand a problem deeply, plan clearly, start small and use AI intelligently to move faster.

So the question I’d leave you with is simple: what could your business turn into software?

It might be an internal process. It might be a small reporting tool. It might be knowledge or intellectual property that could become a completely new offering. You don’t need to build it tomorrow. Just start looking for the places where you’re spending unnecessary time and energy, or where an opportunity keeps presenting itself.

And if you have an idea and want someone to challenge it with you, reach out. I’m always happy to talk through an idea over a call or a coffee at an Uncommon event. Sometimes the most valuable thing you can do before building anything is have someone ask you a few harder questions.

Andrew Romeo on LinkedIn

Share