I recently got a call from a client who was at his wit’s end. He’d hired a “prompt engineer” to build a custom WooCommerce analytics dashboard using one of those new AI coding tools. On the surface, it looked slick. But the second we tried to filter by customer lifetime value, the whole thing crashed. Hard. Turns out, the logic was held together by nothing but vibes and hallucinations. There was no actual data model. No structure. Just a lopsided horse that could barely stand, let alone run a business.
My first thought was to just jump in and vibe code a fix myself—just a few clever prompts to patch the holes. Trust me on this: that was a mistake. I spent three hours chasing a ghost in the state management before I realized I was just adding more debt to a broken foundation. I had to stop. I needed a real intent prototyping workflow to actually see where the structural failure lived. We aren’t just building pictures of products anymore; we’re architecting blueprints for systems.
The Blueprint Over the Vibe
In a great piece I saw over at Smashing Magazine, the concept of “Intent Prototyping” is laid out as the antidote to this mess. It’s about being disciplined. Instead of asking an LLM to “make a dashboard,” you feed it a holistic expression of your intent: sketches, conceptual models, and clear user flows. You define the Data Access Layer (DAL) before a single pixel is rendered on the screen. It keeps the engineering team from becoming “code archaeologists” trying to dig through layers of AI-generated garbage.
For that broken dashboard, I went back to basics. I sketched out the relationships in Excalidraw—not for the looks, but for the logic. I used an LLM to generate a UML class diagram from that sketch, which became our source of truth. Then, I had it write a spec for the DAL using a pattern similar to this:
/**
* 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.Why Your Workflow Needs This Discipline
The beauty of this intent prototyping workflow is that it separates the “what” from the “how.” By creating a DAL.md and a UI.md spec file before you touch an agentic AI like Gemini CLI or Cursor, you’re giving the AI a house blueprint instead of a single brick. It prevents the conceptual model failures that happen when the AI starts guessing at your vision. And here’s the kicker: if you don’t understand the spec it generates, you ask it to explain the logic before it writes the code. If the logic is flawed, the code will be too. Period.
Look, this stuff gets complicated fast. If you’re tired of debugging someone else’s mess and just want your site to work, drop my team a line. We’ve probably seen it before.
The Bottom Line
Stop treating AI like a magic wand and start treating it like a junior developer who needs a very, very specific set of instructions. Document your intent. Build your model. Test the logic with a “walking skeleton” before you worry about the branding. It’s the only way to build enterprise-grade tools that don’t fall apart the moment a user clicks a button.
- Sketch the Flow: Don’t worry about visual polish; focus on the path.
- Model the Data: Use Mermaid or UML to define how objects talk to each other.
- Plan the Execution: Break the build into small, verifiable increments.
Leave a Reply