Fast Prototypes, Unvalidated Products

Somewhere in the last year, "vibe coding" stopped being a meme and became a workflow. You describe what you want, the AI builds something that runs, and within minutes you're clicking through an interactive prototype that used to take a sprint. It's a genuinely good shift for speed. It's also creating a quieter problem that most teams haven't named yet: the moment a prototype feels real, people start treating it as validated — and those are not the same thing.

I want to make the case that this distinction matters more than it looks like it does, using a project of my own as the counter-example, plus recent research that's starting to document exactly this gap.

The Conflation, Stated Plainly

A vibe-coded prototype answers one question extremely well: can this be built, and does it behave the way I described? That's a real and useful answer. It is not an answer to the question that actually matters for a product decision: does this solve the right problem, for the people who'll actually use it, in the context they'll actually use it in?

The first question is about generation fidelity. The second is about validation. AI tooling has made the first one nearly instant — which is great — but the speed and polish of the output creates a kind of gravity that pulls teams toward mistaking one for the other. A prototype that looks finished feels tested, even when no user outside the building has touched it yet.

What This Looked Like Up Close

I've written before about running the first customer rollout of a collaborative maintenance product at an offshore oil operator in Qatar — three trips, watching real usage unfold over the life of a deployment rather than a single workshop. The moment that actually reshaped the product's direction wasn't anything we designed for. It was watching two user groups argue, in person, about internal silos and who was supposed to talk to whom — a completely human, completely unscripted friction that no one had flagged in any requirements doc.

That's the part I keep coming back to now that prototyping has gotten this fast. If that rollout had been a slick, AI-generated interactive prototype demoed to stakeholders instead of a real deployment sat with real users over months, the silo argument almost certainly never surfaces. Nobody argues with a demo. People nod at demos. The friction I actually needed to see only showed up because people were using something in their real working context, under real stakes, with real colleagues they had actual history with — not clicking through a facsimile of it in a conference room.

A fast, convincing prototype would have given us confidence. It would not have given us that finding. And the finding was the whole point.

The Research Is Starting to Catch Up to the Pattern

This isn't just an anecdote-versus-vibes argument. A 2026 study, "Vibe Coding in Product Teams: Reconfiguring AI-Assisted Workflows, Prototyping, and Collaboration" (Li, Hou, Lin, Zhu, Cao & El Ali, accepted to CHIWORK 2026), interviewed 22 product team members across enterprises, startups, and academia specifically about this shift. Their core finding names the exact tension I'm describing: a pull between efficiency-driven prototyping — "intending the right design," getting something plausible-looking out fast — and reflection — "designing the right intention," actually working out whether it's the right thing to build. The same study found this shift introduces new asymmetries in trust and responsibility inside teams: when a prototype is generated rather than built, it's genuinely less clear who's accountable for whether it was actually validated versus just shipped-looking.

There's a second, adjacent data point worth citing here. Industry surveys tracking 2026 adoption have repeatedly found a strange gap: the vast majority of developers now use AI coding tools daily, but trust in the actual output stays comparatively low — one aggregated 2026 industry analysis put daily AI tool usage above 90% while trust in the resulting code sat closer to 30%. That gap is telling. People are shipping things faster than their own confidence in those things is growing. Prototyping speed has outpaced validation, and a lot of teams seem to sense it without having a name for it yet.

Why This Keeps Happening

I don't think it's laziness or bad judgment. It's a structural incentive problem:

• A working prototype is legible progress. 

  A stakeholder can see it, click it, approve it. "We validated this with three users last week and it needs more work" is a much harder update to deliver than a working demo link, even when the demo answers a smaller question.

• Speed compresses the moment where reflection used to happen. 

  The old workflow — wireframe, review, build, test — had built-in pauses where someone had to stop and ask "wait, is this actually right?" Vibe-coded prototyping collapses ideation and implementation into one continuous, fast loop, and the pause doesn't reappear on its own. You have to deliberately put it back.

• A polished artifact borrows credibility it hasn't earned. 

  Low-fidelity sketches invite critique almost by design — they look unfinished, so people poke at them. A working, animated, responsive prototype reads as "done," and people default to reacting to the surface rather than questioning the premise underneath it.

What Actually Needs to Change

Not slower prototyping — that's not realistic and it isn't the point. What needs to change is treating the prototype and the validation as two separate deliverables that happen to now take the same amount of time to produce, instead of one thing:

• Name the gap explicitly on every prototype. 

  Before it goes to stakeholders, state plainly: "this shows what it would look like" vs. "this has been used by real people in a real context." Don't let the second claim get inherited silently from the first.

• Protect the in-context observation, even when it's slower. 

  The silo argument in Qatar didn't happen in a lab. If your validation only ever happens in a conference room or a Zoom usability session, you're still one layer removed from the friction that actually matters — you're testing a simulation of context, not the context itself.

• Assign the reflection step to a specific person, not "the team." 

  The CHIWORK research is blunt about this: when responsibility is diffuse, "we'll validate it later" quietly becomes "no one validated it." Someone needs to own the question of whether this is the right thing, separate from whoever owns whether it works.

The Actual Takeaway

Speed of generation was never a proxy for correctness — we just didn't need to say that out loud when prototyping was slow enough that reflection came along for the ride. Now that a convincing prototype takes minutes instead of weeks, the reflection has to be reintroduced on purpose. The tool got faster. The question of whether you're building the right thing didn't get any easier to answer, and pretending otherwise is exactly how a team ends up very fast at building things nobody actually needed.