A client called me recently at his wit’s end. He had hired a “prompt engineer” to build a custom WooCommerce analytics dashboard with one of the new AI coding tools. From the outside it looked slick. Then we tried to filter by customer lifetime value and the whole thing fell over. Nothing underneath it had been designed. There was no data model and no structure holding the logic together, only whatever the tool had guessed at.
My instinct was to vibe code a fix myself, a few clever prompts to patch the holes. That was a mistake. I burned three hours chasing a ghost in the state management before I admitted I was piling more debt onto a broken foundation, so I stopped. What I needed was a real intent prototyping workflow to find out where the structural failure actually lived. A missing data model is a design problem, and more prompting does not fix a design problem.
The blueprint comes first
Smashing Magazine ran a good piece laying out “Intent Prototyping” as the answer to exactly this problem. It comes down to discipline. Instead of asking an LLM to “make a dashboard,” you hand it a full expression of your intent: sketches, conceptual models and user flows. You define the Data Access Layer (DAL) before anything gets rendered on screen. It also keeps your engineers from turning into “code archaeologists” digging through layers of AI-generated junk.
For that broken dashboard I went back to basics. I sketched the relationships in Excalidraw, not for the looks but for the logic. Then I used an LLM to turn the sketch into a UML class diagram, which became our source of truth, and had it write a spec for the DAL along these lines:
/**
* bbioon_intent_spec_v1
* Defining the relationship between orders and custom meta
*/
interface bbioon_AnalyticsDAL {
id: string;
getLifetimeValue(customerId: number): Promise<number>;
updateRetentionMeta(data: bbioon_RetentionData): void;
}
// Logic must be unambiguous before the UI is touched.
// No assumptions. No vibes. Just a stable blueprint.What the discipline buys you
This intent prototyping workflow separates the “what” from the “how.” Writing a DAL.md and a UI.md spec before you open an agentic tool like Gemini CLI or Cursor hands the model a whole blueprint instead of a single brick, and that is what heads off the conceptual model failures you get when it starts guessing at your intent. One more habit worth keeping: if you do not understand the spec it produces, make it explain the logic before it writes any code. Flawed logic produces flawed code.
None of this stays simple for long. If you are tired of untangling someone else’s build and just want the site working, drop my team a line. Odds are we have seen it before.
How to keep it from happening again
Treat the AI like a junior developer who needs very specific instructions rather than a magic wand. Write down your intent, build the model, then test the logic with a “walking skeleton” before you go anywhere near branding. That is what keeps a tool from falling apart the first time a real user clicks something.
- Sketch the flow before you worry about how it looks, because the path matters more than the polish.
- Model the data with Mermaid or UML so you can see how the objects talk to each other.
- Break the build into small increments you can verify one at a time.
