Vibe Coding Is a Backlog of Demand

ai innovationLeslie Barry

The unofficial AI tools people make at work can show you where the real friction is.

Last week during our weekly sim racing session, we ended up talking about the value of vibe-coded software.

We were discussing why so many vibe-coded products appear to have customers, even when people like us look at them and wonder who would pay for that. We also wondered why vibe-coding platforms like Lovable, often dismissed as AI slop generators, can attract hundreds of millions of dollars in investment.

Maybe lots of people have always wanted to make software but couldn’t. Now they can, and customers are buying what they make. You can roll your eyes at some of the output, but the behaviour is real.

Vibe-coded products are evidence of previously blocked demand, not just rough software.

That stayed with me because the same thing is happening inside companies.

A few days later I was talking with a client about AI ideas appearing in small pockets across the business. Someone finds an annoying piece of work, opens an AI tool, and builds an agent or rough application to deal with it. Someone else does the same thing in another team. Some of these prototypes look polished enough to feel like products, even though they’re still ideas with a user interface.

I think companies are missing a useful signal here.

I think that effort is admirable. Someone has gone beyond talking and built something to fix their work, often on top of the job they were already doing. They’ve put some skin in the game, which is much stronger evidence than another suggestion on a workshop wall.

But what does that evidence actually prove?

It proves one person cared enough to act. It doesn’t prove that their agent is the right solution, that ten other people have the same problem, or that the company should now fund it as a product.

The current conversation about shadow AI often starts with governance. I would start with the builder. Ask them to show you what they made, why they made it, and what support would help them test it properly.

The prototype tells you where to look.

Start by finding the unofficial tools people have already made. Ask what was irritating enough for them to build something, what they were doing before, and whether anyone else has the same problem.

Then group the tools by the underlying job rather than the proposed technology. Three different agents may turn out to be three attempts to remove the same piece of manual work. That repeated pain is more interesting than any one demo.

From there, treat the strongest problem like any other idea:

  1. Write down who has the problem and what they’re trying to do.
  2. Agree on the behaviour that would show the problem is worth solving.
  3. Put the smallest credible version in front of the likely users.
  4. Measure what they do rather than asking whether they like the demo.
  5. Decide whether to fund it, change it, or stop.

This is the same basic path we use in Rapidly.

A polished AI prototype doesn’t skip validation. It enters the process with a better starting signal than a Post-it note.

Companies still need to know what data and models people are using. A central AI register is more likely to work when it gives the builder something useful in return.

The central team can offer something useful instead: access to better models, tokens, security help, an expert who can sit beside the builder, and a fast route to testing or funding. Bringing the work into one place should help the person move faster.

I want to test this approach with a few companies over the next month.

If people inside your company are already building unofficial tools, ask them to show you. Don’t begin with the model or the feature list. Ask what was painful enough to make them build it, then see who else has the same problem.

If you try it, I’d be interested to hear what you find.