{"id":608,"date":"2025-09-24T17:00:00","date_gmt":"2025-09-24T17:00:00","guid":{"rendered":"http:\/\/guupon.com\/?p=608"},"modified":"2025-10-01T15:36:52","modified_gmt":"2025-10-01T15:36:52","slug":"intent-prototyping-the-allure-and-danger-of-pure-vibe-coding-in-enterprise-ux-part-1","status":"publish","type":"post","link":"http:\/\/guupon.com\/index.php\/2025\/09\/24\/intent-prototyping-the-allure-and-danger-of-pure-vibe-coding-in-enterprise-ux-part-1\/","title":{"rendered":"Intent Prototyping: The Allure And Danger Of Pure Vibe Coding In Enterprise UX (Part 1)"},"content":{"rendered":"
Intent Prototyping: The Allure And Danger Of Pure Vibe Coding In Enterprise UX (Part 1)<\/title><\/p>\n<article>\n<header>\n<h1>Intent Prototyping: The Allure And Danger Of Pure Vibe Coding In Enterprise UX (Part 1)<\/h1>\n<address>Yegor Gilyov<\/address>\n<p> 2025-09-24T17:00:00+00:00<br \/>\n 2025-10-01T15:02:43+00:00<br \/>\n <\/header>\n<p>There is a spectrum of opinions on how dramatically all creative professions will be changed by the coming wave of agentic AI, from the very skeptical to the wildly optimistic and even apocalyptic. I think that even if you are on the \u201cskeptical\u201d end of the spectrum, it makes sense to explore ways this new technology can help with your everyday work. As for my everyday work, I\u2019ve been doing UX and product design for about 25 years now, and I\u2019m always keen to learn new tricks and share them with colleagues. Right now, I\u2019m interested in <strong>AI-assisted prototyping<\/strong>, and I\u2019m here to share my thoughts on how it can change the process of designing digital products.<\/p>\n<p>To set your expectations up front: this exploration focuses on a specific part of the product design lifecycle. Many people know about the Double Diamond framework, which shows the path from problem to solution. However, I think it\u2019s the <a href=\"https:\/\/uxdesign.cc\/why-the-double-diamond-isnt-enough-adaa48a8aec1\">Triple Diamond model<\/a> that makes an important point for our needs. It explicitly separates the solution space into two phases: Solution Discovery (ideating and validating the right concept) and Solution Delivery (engineering the validated concept into a final product). This article is focused squarely on that middle diamond: <strong>Solution Discovery<\/strong>.<\/p>\n<figure class=\"\n \n break-out article__image\n \n \n \"><\/p>\n<p> <a href=\"https:\/\/files.smashing.media\/articles\/intent-prototyping-pure-vibe-coding-enterprise-ux\/01-diagram-triple-diamond-model.png\"><\/p>\n<p> <img decoding=\"async\" loading=\"lazy\" width=\"800\" height=\"593\" src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/intent-prototyping-pure-vibe-coding-enterprise-ux\/01-diagram-triple-diamond-model.png\" alt=\"Diagram of the Triple Diamond model: Problem Discovery, Solution Discovery, and Solution Delivery.\" \/><\/p>\n<p> <\/a><figcaption class=\"op-vertical-bottom\">\n The Triple Diamond model and the prototyping sweet spot. (<a href=\"https:\/\/files.smashing.media\/articles\/intent-prototyping-pure-vibe-coding-enterprise-ux\/01-diagram-triple-diamond-model.png\">Large preview<\/a>)<br \/>\n <\/figcaption><\/figure>\n<p>How AI can help with the preceding (Problem Discovery) and the following (Solution Delivery) stages is out of the scope of this article. Problem Discovery is less about prototyping and more about research, and while I believe AI can revolutionize the research process as well, I\u2019ll leave that to people more knowledgeable in the field. As for Solution Delivery, it is more about engineering optimization. There\u2019s no doubt that software engineering in the AI era is undergoing dramatic changes, but I\u2019m not an engineer — I\u2019m a designer, so let me focus on my \u201csweet spot\u201d.<\/p>\n<p>And my \u201csweet spot\u201d has a specific flavor: <strong>designing enterprise applications<\/strong>. In this world, the main challenge is taming complexity: dealing with complicated data models and guiding users through non-linear workflows. This background has had a big impact on my approach to design, putting a lot of emphasis on the underlying logic and structure. This article explores the potential of AI through this lens.<\/p>\n<p>I\u2019ll start by outlining the typical artifacts designers create during Solution Discovery. Then, I\u2019ll examine the problems with how this part of the process often plays out in practice. Finally, we\u2019ll explore whether AI-powered prototyping can offer a better approach, and if so, whether it aligns with what people call \u201cvibe coding,\u201d or calls for a more deliberate and disciplined way of working.<\/p>\n<div data-audience=\"non-subscriber\" data-remove=\"true\" class=\"feature-panel-container\">\n<aside class=\"feature-panel\">\n<div class=\"feature-panel-left-col\">\n<div class=\"feature-panel-description\">\n<p>Meet <strong><a data-instant href=\"https:\/\/www.smashingconf.com\/online-workshops\/\">Smashing Workshops<\/a><\/strong> on <strong>front-end, design & UX<\/strong>, with practical takeaways, live sessions, <strong>video recordings<\/strong> and a friendly Q&A. With Brad Frost, St\u00e9ph Walter and <a href=\"https:\/\/smashingconf.com\/online-workshops\/workshops\">so many others<\/a>.<\/p>\n<p><a data-instant href=\"smashing-workshops\" class=\"btn btn--green btn--large\">Jump to the workshops \u21ac<\/a><\/div>\n<\/div>\n<div class=\"feature-panel-right-col\"><a data-instant href=\"smashing-workshops\" class=\"feature-panel-image-link\"><\/p>\n<div class=\"feature-panel-image\">\n<img decoding=\"async\" loading=\"lazy\" class=\"feature-panel-image-img\" src=\"\/images\/smashing-cat\/cat-scubadiving-panel.svg\" alt=\"Feature Panel\" width=\"257\" height=\"355\" \/><\/p>\n<\/div>\n<p><\/a>\n<\/div>\n<\/aside>\n<\/div>\n<h2 id=\"what-we-create-during-solution-discovery\">What We Create During Solution Discovery<\/h2>\n<p>The Solution Discovery phase begins with the key output from the preceding research: <strong>a well-defined problem<\/strong> and <strong>a core hypothesis for a solution<\/strong>. This is our starting point. The artifacts we create from here are all aimed at turning that initial hypothesis into a tangible, testable concept.<\/p>\n<p>Traditionally, at this stage, designers can produce artifacts of different kinds, progressively increasing fidelity: from napkin sketches, boxes-and-arrows, and conceptual diagrams to hi-fi mockups, then to interactive prototypes, and in some cases even live prototypes. Artifacts of lower fidelity allow fast iteration and enable the exploration of many alternatives, while artifacts of higher fidelity help to understand, explain, and validate the concept in all its details.<\/p>\n<p>It\u2019s important to <strong>think holistically<\/strong>, considering different aspects of the solution. I would highlight three dimensions:<\/p>\n<ol>\n<li><strong>Conceptual model<\/strong>: Objects, relations, attributes, actions;<\/li>\n<li><strong>Visualization<\/strong>: Screens, from rough sketches to hi-fi mockups;<\/li>\n<li><strong>Flow<\/strong>: From the very high-level user journeys to more detailed ones.<\/li>\n<\/ol>\n<p>One can argue that those are layers rather than dimensions, and each of them builds on the previous ones (for example, according to <a href=\"https:\/\/www.interaction-design.org\/literature\/article\/the-magic-of-semantic-interaction-design?srsltid=AfmBOoq4-4YG8RR7SDZn7CX1GJ1ZKNdiZx-trER7oKCefud3V2TjeumD\">Semantic IxD<\/a> by Daniel Rosenberg), but I see them more as different facets of the same thing, so the design process through them is not necessarily linear: you may need to switch from one perspective to another many times.<\/p>\n<p>This is how different types of design artifacts map to these dimensions:<\/p>\n<figure class=\"\n \n break-out article__image\n \n \n \"><\/p>\n<p> <a href=\"https:\/\/files.smashing.media\/articles\/intent-prototyping-pure-vibe-coding-enterprise-ux\/02-mapping-design-artifacts.png\"><\/p>\n<p> <img decoding=\"async\" loading=\"lazy\" width=\"800\" height=\"596\" src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/intent-prototyping-pure-vibe-coding-enterprise-ux\/02-mapping-design-artifacts.png\" alt=\"Diagram mapping design artifacts to dimensions of Conceptual Model, Visualization, and Flow.\" \/><\/p>\n<p> <\/a><figcaption class=\"op-vertical-bottom\">\n Mapping design artifacts to dimensions of Conceptual Model, Visualization, and Flow. (<a href=\"https:\/\/files.smashing.media\/articles\/intent-prototyping-pure-vibe-coding-enterprise-ux\/02-mapping-design-artifacts.png\">Large preview<\/a>)<br \/>\n <\/figcaption><\/figure>\n<p>As Solution Discovery progresses, designers move from the left part of this map to the right, from low-fidelity to high-fidelity, from ideating to validating, from diverging to converging.<\/p>\n<p>Note that at the beginning of the process, different dimensions are supported by artifacts of different types (boxes-and-arrows, sketches, class diagrams, etc.), and only closer to the end can you build a live prototype that encompasses all three dimensions: conceptual model, visualization, and flow.<\/p>\n<p>This progression shows a classic trade-off, like the difference between a pencil drawing and an oil painting. The drawing lets you explore ideas in the most flexible way, whereas the painting has a lot of detail and overall looks much more realistic, but is hard to adjust. Similarly, as we go towards artifacts that integrate all three dimensions at higher fidelity, our ability to iterate quickly and explore divergent ideas goes down. This inverse relationship has long been an accepted, almost unchallenged, limitation of the design process.<\/p>\n<h2 id=\"the-problem-with-the-mockup-centric-approach\">The Problem With The Mockup-Centric Approach<\/h2>\n<p>Faced with this difficult trade-off, often teams opt for the easiest way out. On the one hand, they need to show that they are making progress and create things that appear detailed. On the other hand, they rarely can afford to build interactive or live prototypes. This leads them to over-invest in one type of artifact that seems to offer the best of both worlds. As a result, the neatly organized \u201cbento box\u201d of design artifacts we saw previously gets shrunk down to just one compartment: creating static high-fidelity mockups.<\/p>\n<figure class=\"\n \n break-out article__image\n \n \n \"><\/p>\n<p> <a href=\"https:\/\/files.smashing.media\/articles\/intent-prototyping-pure-vibe-coding-enterprise-ux\/03-artifact-map-diagram.png\"><\/p>\n<p> <img decoding=\"async\" loading=\"lazy\" width=\"800\" height=\"388\" src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/intent-prototyping-pure-vibe-coding-enterprise-ux\/03-artifact-map-diagram.png\" alt=\"The artifact map diagram, with \u201cHi-fi Mockup\u201d enlarged to show an over-reliance on it.\" \/><\/p>\n<p> <\/a><figcaption class=\"op-vertical-bottom\">\n The mockup-centric approach. (<a href=\"https:\/\/files.smashing.media\/articles\/intent-prototyping-pure-vibe-coding-enterprise-ux\/03-artifact-map-diagram.png\">Large preview<\/a>)<br \/>\n <\/figcaption><\/figure>\n<p>This choice is understandable, as several forces push designers in this direction. Stakeholders are always eager to see nice pictures, while artifacts representing user flows and conceptual models receive much less attention and priority. They are too high-level and hardly usable for validation, and usually, not everyone can understand them.<\/p>\n<p>On the other side of the fidelity spectrum, interactive prototypes require too much effort to create and maintain, and creating live prototypes in code used to require special skills (and again, effort). And even when teams make this investment, they do so at the end of Solution Discovery, during the convergence stage, when it is often too late to experiment with fundamentally different ideas. With so much effort already sunk, there is little appetite to go back to the drawing board.<\/p>\n<p>It\u2019s no surprise, then, that many teams default to the perceived safety of <strong>static mockups<\/strong>, seeing them as a middle ground between the roughness of the sketches and the overwhelming complexity and fragility that prototypes can have.<\/p>\n<p>As a result, validation with users doesn\u2019t provide enough confidence that the solution will actually solve the problem, and teams are forced to make a leap of faith to start building. To make matters worse, they do so without a clear understanding of the conceptual model, the user flows, and the interactions, because from the very beginning, designers\u2019 attention has been heavily skewed toward visualization.<\/p>\n<p>The result is often a design artifact that resembles the famous \u201chorse drawing\u201d meme: beautifully rendered in the parts everyone sees first (the mockups), but dangerously underdeveloped in its underlying structure (the conceptual model and flows).<\/p>\n<figure class=\"\n \n break-out article__image\n \n \n \"><\/p>\n<p> <a href=\"https:\/\/files.smashing.media\/articles\/intent-prototyping-pure-vibe-coding-enterprise-ux\/04-lopsided-horse-problem.jpg\"><\/p>\n<p> <img decoding=\"async\" loading=\"lazy\" width=\"800\" height=\"541\" src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/intent-prototyping-pure-vibe-coding-enterprise-ux\/04-lopsided-horse-problem.jpg\" alt=\"The \u201chorse drawing\u201d meme, where the front is detailed and the back is a simple sketch.\" \/><\/p>\n<p> <\/a><figcaption class=\"op-vertical-bottom\">\n The \u201clopsided horse\u201d problem. (<a href=\"https:\/\/files.smashing.media\/articles\/intent-prototyping-pure-vibe-coding-enterprise-ux\/04-lopsided-horse-problem.jpg\">Large preview<\/a>)<br \/>\n <\/figcaption><\/figure>\n<p>While this is a familiar problem across the industry, its severity <strong>depends on the nature of the project<\/strong>. If your core challenge is to optimize a well-understood, linear flow (like many B2C products), a mockup-centric approach can be perfectly adequate. The risks are contained, and the \u201clopsided horse\u201d problem is unlikely to be fatal.<\/p>\n<p>However, it\u2019s different for the systems I specialize in: complex applications defined by intricate data models and non-linear, interconnected user flows. Here, the biggest risks are not on the surface but in the underlying structure, and a lack of attention to the latter would be a recipe for disaster.<\/p>\n<div class=\"partners__lead-place\"><\/div>\n<h2 id=\"transforming-the-design-process\">Transforming The Design Process<\/h2>\n<p>This situation makes me wonder:<\/p>\n<blockquote class=\"pull-quote\">\n<p>\n <a class=\"pull-quote__link\" aria-label=\"Share on Twitter\" href=\"https:\/\/twitter.com\/share?text=%0aHow%20might%20we%20close%20the%20gap%20between%20our%20design%20intent%20and%20a%20live%20prototype,%20so%20that%20we%20can%20iterate%20on%20real%20functionality%20from%20day%20one?%0a&url=https:\/\/smashingmagazine.com%2f2025%2f09%2fintent-prototyping-pure-vibe-coding-enterprise-ux%2f\"><\/p>\n<p>How might we close the gap between our design intent and a live prototype, so that we can iterate on real functionality from day one?<\/p>\n<p> <\/a>\n <\/p>\n<div class=\"pull-quote__quotation\">\n<div class=\"pull-quote__bg\">\n <span class=\"pull-quote__symbol\">\u201c<\/span><\/div>\n<\/p><\/div>\n<\/blockquote>\n<figure class=\"\n \n break-out article__image\n \n \n \"><\/p>\n<p> <a href=\"https:\/\/files.smashing.media\/articles\/intent-prototyping-pure-vibe-coding-enterprise-ux\/05-design-intent-live-prototype.png\"><\/p>\n<p> <img decoding=\"async\" loading=\"lazy\" width=\"800\" height=\"397\" src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/intent-prototyping-pure-vibe-coding-enterprise-ux\/05-design-intent-live-prototype.png\" alt=\"Diagram showing bridging the gap between \u201cDesign Intent\u201d and \u201cLive Prototype.\u201d\" \/><\/p>\n<p> <\/a><figcaption class=\"op-vertical-bottom\">\n How might we bridge the gap between design intent and a live prototype? (<a href=\"https:\/\/files.smashing.media\/articles\/intent-prototyping-pure-vibe-coding-enterprise-ux\/05-design-intent-live-prototype.png\">Large preview<\/a>)<br \/>\n <\/figcaption><\/figure>\n<p>If we were able to answer this question, we would:<\/p>\n<ul>\n<li><strong>Learn faster.<\/strong><br \/>\nBy going straight from intent to a testable artifact, we cut the feedback loop from weeks to days.<\/li>\n<li><strong>Gain more confidence.<\/strong><br \/>\nUsers interact with real logic, which gives us more proof that the idea works.<\/li>\n<li><strong>Enforce conceptual clarity.<\/strong><br \/>\nA live prototype cannot hide a flawed or ambiguous conceptual model.<\/li>\n<li><strong>Establish a clear and lasting source of truth.<\/strong><br \/>\nA live prototype, combined with a clearly documented design intent, provides the engineering team with an unambiguous specification.<\/li>\n<\/ul>\n<p>Of course, the desire for such a process is not new. This vision of a truly <strong>prototype-driven workflow<\/strong> is especially compelling for enterprise applications, where the benefits of faster learning and forced conceptual clarity are the best defense against costly structural flaws. But this ideal was still out of reach because prototyping in code took so much work and specialized talents. Now, the rise of powerful AI coding assistants changes this equation in a big way.<\/p>\n<h2 id=\"the-seductive-promise-of-vibe-coding\">The Seductive Promise Of \u201cVibe Coding\u201d<\/h2>\n<p>And the answer seems to be obvious: <strong>vibe coding<\/strong>!<\/p>\n<blockquote><p>\u201cVibe coding\u00a0is an\u00a0artificial intelligence-assisted software development\u00a0style popularized by Andrej Karpathy\u00a0in early 2025.\u00a0It describes a fast, improvisational, collaborative approach to creating\u00a0software\u00a0where the developer and a\u00a0large language model\u00a0(LLM) tuned for coding is acting rather like\u00a0pair programmers\u00a0in a conversational loop.\u201d<\/p>\n<p>— <a href=\"https:\/\/en.wikipedia.org\/wiki\/Vibe_coding\">Wikipedia<\/a><\/p><\/blockquote>\n<p>The original tweet by Andrej Karpathy:<\/p>\n<figure class=\"\n \n break-out article__image\n \n \n \"><\/p>\n<p> <a href=\"https:\/\/x.com\/karpathy\/status\/1886192184808149383\"><\/p>\n<p> <img decoding=\"async\" loading=\"lazy\" width=\"800\" height=\"552\" src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/intent-prototyping-pure-vibe-coding-enterprise-ux\/06-andrej-karpathy-tweet.png\" alt=\"Screenshot of Andrej Karpathy's tweet defining Vibe Coding.\" \/><\/p>\n<p> <\/a><figcaption class=\"op-vertical-bottom\">\n Andrej Karpathy\u2019s tweet that popularized the term \u201cvibe coding\u201d. (Image source: <a href=\"https:\/\/x.com\/karpathy\/status\/1886192184808149383\">X<\/a>) (<a href=\"https:\/\/files.smashing.media\/articles\/intent-prototyping-pure-vibe-coding-enterprise-ux\/06-andrej-karpathy-tweet.png\">Large preview<\/a>)<br \/>\n <\/figcaption><\/figure>\n<p>The allure of this approach is undeniable. If you are not a developer, you are bound to feel awe when you describe a solution in plain language, and moments later, you can interact with it. This seems to be the ultimate fulfillment of our goal: a direct, frictionless path from an idea to a live prototype. But <strong>is this method reliable enough<\/strong> to build our new design process around it?<\/p>\n<h3 id=\"the-trap-a-process-without-a-blueprint\">The Trap: A Process Without A Blueprint<\/h3>\n<p>Vibe coding mixes up a description of the UI with a description of the system itself, resulting in a <strong>prototype based on changing assumptions rather than a clear, solid model<\/strong>.<\/p>\n<blockquote class=\"pull-quote\">\n<p>\n <a class=\"pull-quote__link\" aria-label=\"Share on Twitter\" href=\"https:\/\/twitter.com\/share?text=%0aThe%20pitfall%20of%20vibe%20coding%20is%20that%20it%20encourages%20us%20to%20express%20our%20intent%20in%20the%20most%20ambiguous%20way%20possible:%20by%20having%20a%20conversation.%0a&url=https:\/\/smashingmagazine.com%2f2025%2f09%2fintent-prototyping-pure-vibe-coding-enterprise-ux%2f\"><\/p>\n<p>The pitfall of vibe coding is that it encourages us to express our intent in the most ambiguous way possible: by having a conversation.<\/p>\n<p> <\/a>\n <\/p>\n<div class=\"pull-quote__quotation\">\n<div class=\"pull-quote__bg\">\n <span class=\"pull-quote__symbol\">\u201c<\/span><\/div>\n<\/p><\/div>\n<\/blockquote>\n<p>This is like hiring a builder and telling them what to do one sentence at a time without ever presenting them a blueprint. They could make a wall that looks great, but you can\u2019t be sure that it can hold weight.<\/p>\n<p>I\u2019ll give you one example illustrating problems you may face if you try to jump over the chasm between your idea and a live prototype relying on pure vibe coding in the spirit of Andrej Karpathy\u2019s tweet. Imagine I want to prototype a solution to keep track of tests to validate product ideas. I open my vibe coding tool of choice (I intentionally don\u2019t disclose its name, as I believe they all are awesome yet prone to similar pitfalls) and start with the following prompt:<\/p>\n<div class=\"break-out\">\n<pre><code class=\"language-markdown\">I need an app to track tests. For every test, I need to fill out the following data:\n- Hypothesis (we believe that...) \n- Experiment (to verify that, we will...)\n- When (a single date, or a period) \n- Status (New\/Planned\/In Progress\/Proven\/Disproven)\n<\/code><\/pre>\n<\/div>\n<p>And in a minute or so, I get a working prototype:<\/p>\n<figure class=\"\n \n break-out article__image\n \n \n \"><\/p>\n<p> <a href=\"https:\/\/files.smashing.media\/articles\/intent-prototyping-pure-vibe-coding-enterprise-ux\/7-test-tracker.png\"><\/p>\n<p> <img decoding=\"async\" loading=\"lazy\" width=\"800\" height=\"610\" src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/intent-prototyping-pure-vibe-coding-enterprise-ux\/7-test-tracker.png\" alt=\"Screenshot of a simple Test Tracker app.\" \/><\/p>\n<p> <\/a><figcaption class=\"op-vertical-bottom\">\n The initial prototype. (<a href=\"https:\/\/files.smashing.media\/articles\/intent-prototyping-pure-vibe-coding-enterprise-ux\/7-test-tracker.png\">Large preview<\/a>)<br \/>\n <\/figcaption><\/figure>\n<p>Inspired by success, I go further:<\/p>\n<div class=\"break-out\">\n<pre><code class=\"language-markdown\">Please add the ability to specify a product idea for every test. Also, I want to filter tests by product ideas and see how many tests each product idea has in each status.\n<\/code><\/pre>\n<\/div>\n<p>And the result is still pretty good:<\/p>\n<figure class=\"\n \n break-out article__image\n \n \n \"><\/p>\n<p> <a href=\"https:\/\/files.smashing.media\/articles\/intent-prototyping-pure-vibe-coding-enterprise-ux\/8-test-tracker-updated.png\"><\/p>\n<p> <img decoding=\"async\" loading=\"lazy\" width=\"800\" height=\"610\" src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/intent-prototyping-pure-vibe-coding-enterprise-ux\/8-test-tracker-updated.png\" alt=\"The Test Tracker app screenshot, now with filtering by product ideas.\" \/><\/p>\n<p> <\/a><figcaption class=\"op-vertical-bottom\">\n The prototype updated to include filtering tests by product ideas. (<a href=\"https:\/\/files.smashing.media\/articles\/intent-prototyping-pure-vibe-coding-enterprise-ux\/8-test-tracker-updated.png\">Large preview<\/a>)<br \/>\n <\/figcaption><\/figure>\n<p>But then I want to extend the functionality related to product ideas:<\/p>\n<div class=\"break-out\">\n<pre><code class=\"language-markdown\">Okay, one more thing. For every product idea, I want to assess the impact score, the confidence score, and the ease score, and get the overall ICE score. Perhaps I need a separate page focused on the product idea, with all the relevant information and related tests.\n<\/code><\/pre>\n<\/div>\n<p>And from this point on, the results are getting more and more confusing.<\/p>\n<p>The flow of creating tests hasn\u2019t changed much. I can still create a bunch of tests, and they seem to be organized by product ideas. But when I click \u201cProduct Ideas\u201d in the top navigation, I see nothing:<\/p>\n<figure class=\"\n \n break-out article__image\n \n \n \"><\/p>\n<p> <a href=\"https:\/\/files.smashing.media\/articles\/intent-prototyping-pure-vibe-coding-enterprise-ux\/9-product-ideas-page.png\"><\/p>\n<p> <img decoding=\"async\" loading=\"lazy\" width=\"800\" height=\"518\" src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/intent-prototyping-pure-vibe-coding-enterprise-ux\/9-product-ideas-page.png\" alt=\"Screenshot of the app\u2019s blank Product Ideas page.\" \/><\/p>\n<p> <\/a><figcaption class=\"op-vertical-bottom\">\n The Product Ideas page is empty. (<a href=\"https:\/\/files.smashing.media\/articles\/intent-prototyping-pure-vibe-coding-enterprise-ux\/9-product-ideas-page.png\">Large preview<\/a>)<br \/>\n <\/figcaption><\/figure>\n<p>I need to create my ideas from scratch, and they are not connected to the tests I created before:<\/p>\n<figure class=\"\n \n break-out article__image\n \n \n \"><\/p>\n<p> <a href=\"https:\/\/files.smashing.media\/articles\/intent-prototyping-pure-vibe-coding-enterprise-ux\/10-product-ideas-disconnected-tests.png\"><\/p>\n<p> <img decoding=\"async\" loading=\"lazy\" width=\"800\" height=\"519\" src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/intent-prototyping-pure-vibe-coding-enterprise-ux\/10-product-ideas-disconnected-tests.png\" alt=\"Screenshot of the Product Ideas page with newly created ideas not connected to tests.\" \/><\/p>\n<p> <\/a><figcaption class=\"op-vertical-bottom\">\n The newly created product ideas are disconnected from existing tests. (<a href=\"https:\/\/files.smashing.media\/articles\/intent-prototyping-pure-vibe-coding-enterprise-ux\/10-product-ideas-disconnected-tests.png\">Large preview<\/a>)<br \/>\n <\/figcaption><\/figure>\n<p>Moreover, when I go back to \u201cTests\u201d, I see that they are all gone. Clearly something went wrong, and my AI assistant confirms that:<\/p>\n<blockquote><p>No, this is not expected behavior — it\u2019s a bug! The issue is that tests are being stored in two separate places (local state in the Index page and App state), so tests created on the main page don\u2019t sync with the product ideas page.<\/p><\/blockquote>\n<p>Sure, eventually it fixed that bug, but note that we encountered this just on the third step, when we asked to slightly extend the functionality of a very simple app. The more layers of complexity we add, the more roadblocks of this sort we are bound to face.<\/p>\n<p>Also note that this specific problem of a not fully thought-out relationship between two entities (product ideas and tests) is not isolated at the technical level, and therefore, it didn\u2019t go away once the technical bug was fixed. The underlying conceptual model is still broken, and it manifests in the UI as well.<\/p>\n<p>For example, you can still create \u201corphan\u201d tests that are not connected to any item from the \u201cProduct Ideas\u201d page. As a result, you may end up with different numbers of ideas and tests on different pages of the app:<\/p>\n<figure class=\"\n \n break-out article__image\n \n \n \"><\/p>\n<p> <a href=\"https:\/\/files.smashing.media\/articles\/intent-prototyping-pure-vibe-coding-enterprise-ux\/11-conflicting-data-tests-product-ideas-page.png\"><\/p>\n<p> <img decoding=\"async\" loading=\"lazy\" width=\"800\" height=\"305\" src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/intent-prototyping-pure-vibe-coding-enterprise-ux\/11-conflicting-data-tests-product-ideas-page.png\" alt=\"Diagram showing conflicting data between the Tests page and the Product Ideas page.\" \/><\/p>\n<p> <\/a><figcaption class=\"op-vertical-bottom\">\n A poorly defined conceptual model leads to data inconsistencies across the app. (<a href=\"https:\/\/files.smashing.media\/articles\/intent-prototyping-pure-vibe-coding-enterprise-ux\/11-conflicting-data-tests-product-ideas-page.png\">Large preview<\/a>)<br \/>\n <\/figcaption><\/figure>\n<p>Let\u2019s diagnose what really happened here. The AI\u2019s response that this is a \u201cbug\u201d is only half the story. The true root cause is a <strong>conceptual model failure<\/strong>. My prompts never explicitly defined the relationship between product ideas and tests. The AI was forced to guess, which led to the broken experience. For a simple demo, this might be a fixable annoyance. But for a data-heavy enterprise application, this kind of structural ambiguity is fatal. It demonstrates <strong>the fundamental weakness of building without a blueprint<\/strong>, which is precisely what vibe coding encourages.<\/p>\n<p>Don\u2019t take this as a criticism of vibe coding tools. They are creating real magic. However, the fundamental truth about \u201cgarbage in, garbage out\u201d is still valid. If you don\u2019t express your intent clearly enough, chances are the result won\u2019t fulfill your expectations.<\/p>\n<p>Another problem worth mentioning is that even if you wrestle it into a state that works, <strong>the artifact is a black box<\/strong> that can hardly serve as reliable specifications for the final product. The initial meaning is lost in the conversation, and all that\u2019s left is the end result. This makes the development team \u201ccode archaeologists,\u201d who have to figure out what the designer was thinking by reverse-engineering the AI\u2019s code, which is frequently very complicated. Any speed gained at the start is lost right away because of this friction and uncertainty.<\/p>\n<div class=\"partners__lead-place\"><\/div>\n<h2 id=\"from-fast-magic-to-a-solid-foundation\">From Fast Magic To A Solid Foundation<\/h2>\n<p>Pure vibe coding, for all its allure, encourages building without a blueprint. As we\u2019ve seen, this results in <strong>structural ambiguity<\/strong>, which is not acceptable when designing complex applications. We are left with a seemingly quick but fragile process that creates a black box that is difficult to iterate on and even more so to hand off.<\/p>\n<p>This leads us back to our main question: how might we close the gap between our design intent and a live prototype, so that we can iterate on real functionality from day one, without getting caught in the ambiguity trap? The answer lies in a more methodical, disciplined, and therefore trustworthy process.<\/p>\n<p>In <strong>Part 2<\/strong> of this series, \u201cA Practical Guide to Building with Clarity\u201d, I will outline the entire workflow for <strong>Intent Prototyping.<\/strong> This method places the explicit <em>intent<\/em> of the designer at the forefront of the process while embracing the potential of AI-assisted coding.<\/p>\n<p>Thank you for reading, and I look forward to seeing you in Part 2.<\/p>\n<div class=\"signature\">\n <img decoding=\"async\" src=\"https:\/\/www.smashingmagazine.com\/images\/logo\/logo--red.png\" alt=\"Smashing Editorial\" width=\"35\" height=\"46\" loading=\"lazy\" \/><br \/>\n <span>(yk)<\/span>\n<\/div>\n<\/article>\n","protected":false},"excerpt":{"rendered":"<p class=\"text-justify mb-2\" >Intent Prototyping: The Allure And Danger Of Pure Vibe Coding In Enterprise UX (Part 1) Intent Prototyping: The Allure And Danger Of Pure Vibe Coding In Enterprise UX (Part 1) Yegor Gilyov 2025-09-24T17:00:00+00:00 2025-10-01T15:02:43+00:00 There is a spectrum of opinions on how dramatically all creative […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[9],"tags":[],"class_list":["post-608","post","type-post","status-publish","format-standard","hentry","category-accessibility"],"_links":{"self":[{"href":"http:\/\/guupon.com\/index.php\/wp-json\/wp\/v2\/posts\/608","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/guupon.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/guupon.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/guupon.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/guupon.com\/index.php\/wp-json\/wp\/v2\/comments?post=608"}],"version-history":[{"count":1,"href":"http:\/\/guupon.com\/index.php\/wp-json\/wp\/v2\/posts\/608\/revisions"}],"predecessor-version":[{"id":609,"href":"http:\/\/guupon.com\/index.php\/wp-json\/wp\/v2\/posts\/608\/revisions\/609"}],"wp:attachment":[{"href":"http:\/\/guupon.com\/index.php\/wp-json\/wp\/v2\/media?parent=608"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/guupon.com\/index.php\/wp-json\/wp\/v2\/categories?post=608"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/guupon.com\/index.php\/wp-json\/wp\/v2\/tags?post=608"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}