A client walked in last week with what he called a “ready-to-go” MVP. He had spent the weekend in Cursor building a test-tracking tool. “It just needs a few tweaks,” he said, pointing at a screen that did look surprisingly polished. Then I tried to add an ICE score calculation and the whole thing came apart. No database schema, no consistent state management, just a pile of React components held together by whatever the AI guessed at the time.
My first thought was to patch it. Wrap a few functions in a useEffect hook, call it a day. Ten minutes later I was chasing race conditions, because the AI-assisted prototyping had skipped the conceptual model entirely, and nothing downstream of that omission holds up. “Vibe coding” is fast and it feels great. On an enterprise app it will also cost you.
Building without a blueprint
Triple Diamond design has a phase called Solution Discovery, where you test your hypothesis before engineering starts. Plenty of teams now use AI to skip it and go from a “vibe” straight to a live prototype. That is like hiring a bricklayer while you are still describing the house to him one sentence at a time. You may get a wall that looks great, but it will not hold any weight.
Enterprise tools make this worse. A B2C landing page has almost no data model to get wrong. An internal tool has several, plus workflows that loop back on themselves, and pure vibe coding leaves the LLM guessing how any of it relates. Compare a vibe-coded relationship with an explicit one:
// The "Vibe Coded" Mess: Loose associations and fragile logic
const bbioon_save_test = (testData) => {
// AI guesses the relationship on the fly
const ideaName = testData.productIdea;
localStorage.setItem(`test_${ideaName}`, JSON.serialize(testData));
// Good luck syncing this later!
};
// The Intentional Way: Explicit conceptual model
class bbioonProductIdea {
constructor(id, name) {
this.id = id;
this.tests = []; // Explicitly linked
}
}The lopsided horse problem
You know the meme: a beautifully drawn horse’s head that trails off into a stick figure by the hindquarters. Designers do the same thing when they pour effort into high-fidelity mockups and never define the structure underneath. Use AI-assisted prototyping to force those decisions into the open early. If your prototype cannot handle a simple data sync, the finished product will not either.
Vibe coding, a term Andrej Karpathy popularized, is fast. That part is true. On a complex system, though, the speed just buys you technical debt with a nicer UI on top of it. You are left with a black box that some developer has to reverse-engineer later, and that costs more time than the prototype ever saved.
Define the intent first. That is what simple accessible UX research is for, and it happens before you open a coding assistant. Your job here is architect. The prompts come after.
How to prototype with intent
- Define the schema first. Don’t ask the AI for a “test tracker.” Ask for a system where “Tests” have a one-to-many relationship with “Product Ideas.”
- Get the logic right before the pixels. Have the data flow working in a plain text environment before you touch the CSS.
- Keep the prompt chain. Your prompts are the spec now, so store them in order and the engineering team can see what you were thinking.
I have spent 14 years on WordPress and WooCommerce builds, and enterprise systems get complicated faster than anyone plans for. If you are done debugging a prototype held together by vibes and you want the thing to actually work, drop me a line. I have probably seen your exact mess before, and I know how to get you out of it.
Part 2 walks through the workflow I use to turn design intent into code you can maintain, without giving up the speed that makes AI worth using in the first place.
