From Vibe Coding to Validation: Why the Build Is Only Half the Work

The first time a product appears on screen, it is easy to confuse momentum with truth.

The page works. The flow looks plausible. Someone in the room says, “We could ship this.” With AI-assisted building, that moment now arrives in hours.

What has not accelerated at the same rate is the answer to a harder question: should we keep going?

Building fast changes the bottleneck

On 12 March, we brought product leaders, founders and builders together in Amsterdam for From Vibe Coding to Validation, an evening with Amplitude and Lovable. Elena Avramenko and I opened with what we had learned from workshops and buildathons. Tanya Littlefield and Ash Oliver then joined me for a conversation about how teams build, decide and grow when creating software becomes dramatically faster.

The subject was not whether AI can produce a prototype. That argument is already over. The important question is what happens immediately afterwards.

When production was slow, teams could spend weeks debating an idea before anything existed. Now the product can arrive before the organisation has agreed what it is trying to learn.

Speed has moved the bottleneck from making to judging.

A prototype is a question

A useful prototype is not a small version of the final product. It is a question expressed as something people can touch.

Will someone understand this promise? Can they complete the central action? Do they return? Where do they hesitate? Which part creates enough value for them to continue?

The interface alone cannot answer those questions. It can only create the conditions for observing them.

That distinction sounds obvious, yet it changes the entire workshop. If the objective is “build an app,” participants optimise for visible surface area. If the objective is “learn whether this behaviour happens,” they can remove most of the app and concentrate on one flow.

The build and the evidence should share a room

The most useful demonstration that evening connected the event page and product flow built in Lovable with Amplitude. Jake Lee showed how behavioural data could be brought into the same working environment and questioned in plain language.

Instead of exporting a dashboard and starting another meeting, a builder could ask where people dropped out, inspect the behaviour and propose the next change while still inside the product-making loop.

That does not make analytics automatic. It makes feedback harder to postpone.

Good instrumentation still depends on choices made by a person: what counts as success, which event names remain stable, what context is missing, and whether a pattern is meaningful or merely convenient.

AI can shorten the route from observation to change. It cannot decide which observation deserves authority.

Instrument the promise, not every click

Teams often respond to analytics by collecting everything. The result is a large event taxonomy and very little clarity.

For a new AI-built product, I would start with a much smaller record:

• Did the visitor understand the promise strongly enough to begin?

• Did they reach the moment where the product delivers its core value?

• Where did they stop, retry or ask for help?

• Did they return and repeat the meaningful action?

• What did they say that the behavioural data cannot explain?

Those questions are enough to begin. The tracking plan should follow the decision the team expects to make, not an abstract desire to become data-driven.

Validation is not a vote

Fast building also creates a temptation to put a prototype in front of five friendly people, collect compliments and call the idea validated.

That is not evidence. It is encouragement.

Validation requires a claim that could be wrong. It needs a behaviour, a threshold or a decision attached to the result. If almost nobody finishes the flow, will we change the proposition? If people use the feature once but do not return, will we stop adding surface area and investigate the missing value?

Without a consequence, a metric is decoration.

This is where product judgment becomes more—not less—important. AI gives a team many more things it could build. Evidence is how the team protects itself from maintaining all of them.

What the room clarified

Three ideas stayed with me after the conversation.

1. The cost of a bad idea has changed shape

It is cheaper to make the first version. It may be more expensive to keep dozens of plausible, weakly understood features alive. The waste moves downstream unless the learning loop improves too.

2. Product, growth and community are becoming one system

The event itself illustrated this. The page, the invitation, the live experience and the follow-up were not separate campaigns. Each produced signals about what builders cared about and what they tried next.

3. Data must get closer to the maker

When only specialists can access behavioural evidence, questions queue up. When builders can explore it directly, the conversation changes. Specialists do not become unnecessary; they can spend more time improving the quality of the question and less time retrieving a number.

A practical loop for teams

The procedure I now use is deliberately small:

• Name the user and the problem in one sentence.

• Choose the behaviour that would make the idea worth continuing.

• Build the smallest credible path to that behaviour.

• Instrument the start, the value moment and the failure points.

• Put it in front of real people.

• Review behaviour and conversation together.

• Change the product, change the claim or stop.

Then run the loop again.

The build is not the finish line. It is the first piece of evidence.

What this changes about workshops

A workshop should not end when every team has something attractive on a screen. It should end with a working build, a learning question and a clear next move.

That may be a user test tomorrow. It may be instrumentation before a pilot. It may be the decision to throw away the first approach. All three are more valuable than a polished prototype with no consequence.

The original event listing records the programme and speakers. Angela van Bragt’s event recap captures the live Lovable–Amplitude flow. I have also written a practical note on the Lovable and Amplitude integration.

If your team needs to move from AI interest to a product and an evidence loop, bring us the real problem. We will build the smallest version that can teach you something.