Yes-Code: AI-Powered Product Prototyping

My RevvWorks co-founders and I are busy dreaming of product features that will help small business owner/managers live saner lives and get more value out of their hard work. Mark has a deep sales and marketing background, Levi has done a ton of finance and ops and data analytics, and I’m a tech and product nerd. We all have product ideas. In years past we would have prototyped design concepts with Google Slides, Miro, Figma, or perhaps a so-called “no-code” tool like Zapier or Airtable. But just this week all three of us independently created our first real working code prototypes directly in our application codebase, with the help of AI dev tools. It’s “yes-code” prototyping, as opposed to “no-code” or “low-code”.¹

Here’s what the workflow looks like:

1. Design: capture an idea in a text note, a Linear issue, or a hand-drawn sketch
2. Build: feed the idea to an AI development tool – in our case, Claude Code or Google Gemini – and ask the tool to create a prototype within a protected “design hub” portion of our app
3. Play: launch the app and play with the working prototype. Then modify the spec to match any new learnings and design wishes, and repeat steps 1-3 until we’re happy with the result

The “Build” step is shockingly fast… a few minutes, normally, for a full-page mockup. If you already have an idea written down somewhere, you can go from spec to working code in less than 5 minutes. For me, a crappy artist, this step saves hours.

So what do I do with all that extra time? I do more design iterations by refining the specification. I might iterate 10 or 20 times to reach a final result, with each iteration after the first one taking, say, 10 to 60 seconds. An iteration looks like “Align the top edges of the widgets”. Or “Use larger font for the headers”. Or “Remove the Date column from the table and sort everything by name”. I tell the tool what to do, and it does it.

How good is the output? Is it worth it? Link to heading

Quite good, and yes. As an efficient new way to visualize web app design ideas, it’s definitely worth a try.² I don’t get exactly what I am hoping for on the first try, but with a little prescriptive nudging I can get the tool to tweak things to my liking.

On look and feel: If you already have some product UI and/or prototypes built, then your existing look and feel is easily carried into new prototypes by simply telling the AI, “use the existing UI and our standard CSS and components as starting points”. In our app we use the common combo of Daisy UI, Tailwind CSS, and a small set of reusable UI components for things like buttons, links and cards. All of these are automatically incorporated into our prototypes by AI.

On code quality: The output is most definitely not production-ready code, but then again that’s not what I’m seeking. I want a quick, cheap prototype that’s interactive and visually consistent with the rest of my app. This approach checks the box.

In any case, prototype code is meant to be thrown away, right? Well, yes, but … the gap between one of these prototypes and real production code is vastly smaller than anything I would have created in the past. It will be very tempting to just transmogrify these prototypes into shipping code.

Structure and tech stack Link to heading

Here’s how we’re arranging our stuff:

design_hub/
├── prototypes/              # Our prototype code
    └── dashboard.exs/       # Prototype of a dashboard view
    └── onboarding.exs       # Prototype of user onboarding UX
    └── etc. ...             # Prototypes of more good things
lib/
├── app/                     # Core domain layer (resources, business logic - Ash)
└── app_web/                 # Web layer (views, controllers, components - Phoenix)
    └── components/          # Reusable UI components
        └── core_components.ex

The design_hub is where all our prototypes go, and it’s a sister of the production app code in lib. Prototypes in design_hub can depend on components from lib, but not the other way around. This keeps prototype code isolated so it doesn’t negatively impact the rest of the software.

This particular app is built with Elixir, Phoenix and Ash. I built our “design hub” atop the excellent PhoenixStorybook library. It took me about half a day to get this working nicely. There’s nothing magic about this tech stack; one should be able to achieve a similar setup with any modern web app framework.

In terms of LLMs we’re getting good results with Anthropic Sonnet 4.5 and Opus (with Claude) and the just-released Google Gemini 3 (with Anti-Gravity / VS Code). We’re Google Workspace users, so it’s tempting to just use Gemini as it’s bundled with our subscription. We’ll have to see how this plays out.³

Benefits Link to heading

With the caveat that we’ve only just started experimenting with this approach, here’s what the upsides appear to be so far:

1. Speed -> we can explore more of the idea space in much less time
2. Less prone to sunk cost fallacy -> Because these designs are so cheap to make, we’ll hopefully be less emotionally wedded to them. (Hmm… gotta stop polishing though!)
3. Visual consistency -> Our prototypes automatically inherit the behavior, look and feel of our app code, even if the app code changes over time. It’s working code.
4. Shorter time-to-market -> When it’s time to build the production version of a feature we can use the prototype as a very detailed spec and as a source of draft code snippets.

And most importantly,

5. a much lower entry barrier for non-developers and non-designers. Our whole team can yes-code, even though my co-founders vigorously claim not to be software developers.

This makes me selfishly happy, but a little queasy about the future of this slice of web design. I see that product designers will need to move upstream, away from the pixels and towards visual architecture and wielding these new types of tools.

As for costs, these tools aren’t free. Between us we’re spending a few hundred $USD each month on the tools (Claude Max, Claude Pro, Gemini 3). And there is a setup cost: you need a developer to lay the foundation, so this methodology requires a team to have at least 1 dev.

Let’s see where it goes. We’ve only been working this way for a few weeks, so it’s still very new. I’m excited to learn more as we go, and curious to hear what’s working for everyone else too.