This guide shows how teams at Microsoft, Anthropic, Atlassian, and others are collapsing design-dev loops right now and how to tell if a design partner really knows what “AI-native” means. It draws from early workflows we’ve used ourselves, plus playbooks from product leaders building in public.

What you’ll get here:

• what AI prototyping is (and isn’t);

• how teams cut design-dev cycles from weeks to days;

• toolchains and workflows you can copy this week;

• where AI breaks, and why human direction still matters;

• what real teams (not just vendors) are learning on the ground.

The goal: show you how to move faster with more confidence in every decision without falling into the traps of messy auto-code or prototypes mistaken for production.

Why product teams are turning to AI prototyping (and what changed)

For most of the last decade, product teams worked in predictable but slow cycles: research → wireframes → prototype → design review → developer handoff. 

2025 broke that pattern.

With today’s AI tools, teams can spin up working demos with navigation, realistic states, believable copy, and even thin data in days or hours. Decisions that once waited for the next design review now happen the same week. 

What shifted:

• Code moved left: Early code used to be a dev luxury. Now, PMs and designers open Cursor and refactor AI-generated UI into usable components before a sprint even begins. That means fewer throwaway builds and less “just wire it up” frustration for engineers.

• Conversation became part of UX: If your product speaks or writes, static screens aren’t enough. Teams now prototype conversation turns (what the user asks, what the assistant does) alongside the interface. 

• Prototypes replaced PRDs: A clickable demo focuses the room. Instead of debating hypotheticals in docs, teams ask better questions: Does the tone feel on‑brand? What happens with missing data? 

• Everyone builds: Design, PM, and engineering meet in the same file. AI-native builders know just enough of each craft to get an idea from prompt → click without handoffs. 

• Lower risk, more experiments: Fake data and safe sandboxes let teams try bolder ideas. Quick experiments are now stress-tested with evals and human checks before they’re trusted to ship.

The rest of this guide shows you how to put that shift into motion without burning cycles or trust.

Sources: Visily, Reddit, Every

What we mean by “AI prototyping”

When we say AI prototyping, we mean clickable, code‑based demos for web or native apps that you can deploy to a private URL and put in front of users this week.

What it’s not: skipping research, replacing designers with prompts, or shipping raw AI‑authored code to production. The purpose is to collapse the gap between idea and testable reality. 

Across Microsoft, Atlassian, Anthropic, and early-stage AI teams, the core cycle looks similar: 

But knowing how to prototype is one thing. Knowing how the best teams do it is another. 

Expert playbooks on how to use AI for rapid prototyping

The following playbooks come straight from product leaders who’ve shipped AI features at scale. They’re specific enough to copy and tested enough to trust.

Aparna Chennapragada (Microsoft): Prompt sets are the new PRDs

“If you aren’t prototyping with AI, you’re doing it wrong.” — Aparna Chennapragada, CPO, Microsoft

PRDs once anchored software projects: dozens of pages, weeks of alignment. But in the world of AI features, Aparna argues that those 20-page specs are already obsolete.

Instead, her teams at Microsoft start with prompt sets to define exactly “what good looks like” and then prototype the UI and the expected conversation transcript side-by-side. 

In practice, that means:

• start with the cases that matter: Three golden flows, three edge cases, plus non-negotiables like tone, accuracy, and safety;

• prototype the flow and the talk: Every click, every AI response, in the same doc or demo;

• test and retire: Prompts that pass become your baseline, the rest get rewritten; 

• go meta: Aparna even suggests using an LLM to help write the eval prompts that will judge its own outputs.

Mike Krieger (Anthropic): When AI writes most of the first pass

“The bottleneck isn’t typing anymore. It’s deciding.” — Mike Krieger, CPO at Anthropic, co-founder of Instagram

In many builds at Anthropic, AI (specifically Claude Code) drafts 90%+ of the first pass. Engineers then spend their energy on what to keep, what to change, and where human judgment still matters.

In practice, that means:

• let AI set the baseline: Claude Code generates components and even tests. The dev job is to review, merge, and guide the AI toward production. As Mike told Business Insider, “You’re still in charge, but you’re starting with 80-90% of the work done;”

• move in fast loops: Instead of waiting for reviews, prototypes go straight to PMs/researchers for “does this feel right?” feedback; 

• review for decisions:  Teams replace slow, line-by-line code reviews with a demo and a simple list: ✅ Keep, ✏️ Change, ❌ Drop. As Wired reported from Anthropic’s first developer event, this turned reviews from a blocker into a fast decision lane.

• lock in quality: Anthropic runs internal evals to ensure core user tasks still work after changes. 

Joel Unger (Atlassian/Trello): Cursor‑first prototyping at 10× speed

“Figma is maybe 10% of the job. The rest is thinking about the problems.” — Joel Unger, Design Leader, Atlassian (Trello)

For many designers, Figma is the default starting point. Joel argues this habit slows teams down when the real goal is a believable demo. His approach: skip static wireframes and start directly in Cursor.

In Claire Vo’s “How I AI,” he showed how static specs became drag-and-drop prototypes that revealed responsive quirks before code freeze. The result is a behavior-first demo that engineering can actually build from (and they did!).

From prototype to product slideshow (Source: YouTube)

What he does:

• opens Cursor, pastes a Figma screenshot, and prompts for a three-panel system with toggleable toolbars;

• iterates live until motion and min-width behavior feel right;

• records a Loom walkthrough so devs can see exactly what happens at every breakpoint;

• uses the prototype to set guardrails and clarify edge cases early.

Elizabeth Lin: interactive sound & data‑viz in Cursor

“How do you teach an LLM to have good taste? I try to send really random things.” — Elizabeth Lin, Designer & Creator

Most prototypes look like silent movies, but Elizabeth’s don’t. By adding sound cues and quick style variations, she makes click-throughs feel finished enough for stakeholders to react honestly.

Elizabeth pushes back against the idea that prototyping is just about layout or information hierarchy. Her focus is on making prototypes behave like living systems.

From prompt to virtual piano slideshow (Source: YouTube)

What she does:

• adds audio feedback (success/error tones) so testers feel the system respond;

• connects Notion or CSV data to charts, so dashboards update with believable numbers;

• generates style variations in one prompt side-by-side and picks the one that speeds decisions.

Colin Matthews: brand fidelity, without the wait

“Screenshots are the easiest way to start building a component library.” — Colin Matthews, Founder, Tech For Product 

One of the hardest balances in prototyping is fidelity. Too rough and it feels like toyware. Too polished and stakeholders mistake it for production. Colin focuses on solving this tension by getting to brand-true prototypes by rebuilding directly from screenshots.

From prompt to a website copy (Source: YouTube)

In practice, that means:

• rebuild from screenshots: Turn screenshots into reusable components (tools like v0 or Magic Patterns can help);

• refactor into components: Break them into buttons, cards, navigation so flows remain flexible;

• lock in styles early: Apply color, spacing, and typography up front;

• experiment safely: Fork branches so bold ideas don’t pollute the baseline.

Wade Chambers (Amplitude): compress research → PRD → prototype into one meeting

“Built in 3-4 weeks of spare time, and then it went viral in a week.” — Claire Vo’s recap of Moda, Amplitude’s internal AI agent

Amplitude’s CEO, Wade Chambers, wanted to collapse the weeks between research → PRD → prototype into hours. The result was Moda, an internal agent that went company-wide within weeks.

Instead of long research docs and follow-up reviews, PMs now run a single session where they surface insights, draft a one-pager, and build a clickable demo live. The cultural push came through AI Week, Amplitude’s internal bootcamp modeled on Meta’s “mobile shift,” which gave every team time and training to try AI on real work.

What they did:

• connected Moda to support tickets, sales notes, and research to surface themes quickly;

• standardized the meeting: themes → PRD outline → three prototype tasks;

• built demos live in the room, not as a follow-up;

• launched socially: internal champions, quick wins, and guardrails (no customer-facing changes without review).

Prerna Kaul (Panasonic Well): regulated blueprint for AI prototyping

“We had to build a nearly 60,000‑page document that would have taken four to six months of effort and nearly 20 experts. Instead, we turned it into a system that outputs it in minutes." — Prerna Kaul, Group Product Manager at Panasonic Well

In highly regulated spaces, safety and compliance are product features. Prerna built an AI pipeline using Claude and Streamlit that automates a 60,000‑page FDA submission in minutes. The system handles PHI redaction, section assembly, and creates an auditable trail for review through a UI usable by non‑technical teams.

From prompt to production-ready prototype (Source: YouTube)

What she does:

• wraps AI in a user-friendly frontend, so legal and clinical stakeholders can work without coding;

• builds compliance into the workflow, with PHI redaction and policy checks integrated into the prototype;

• measures with product metrics, like time-to-first-submission and error rate, instead of just feasibility.

Volodymyr Merlenko (Cieden): the non‑technical PM’s guide

“These five tools (Claude, Perplexity, v0, Lovable, Cursor) cut out the busywork and get you to feedback faster.” — Volodymyr Merlenko, UX/UI Designer at Cieden

AI prototyping isn’t just for engineers anymore. Volodymyr shows how a PM with no coding background can still deliver a working prototype in under a week that is credible enough for stakeholders and fast enough to keep momentum.

What he does:

• uses Claude to draft product briefs, golden/edge cases, and evaluation prompts;

• runs Perplexity sweeps for competitor insights and community pain points;

• generates first-pass UI in v0 or Lovable, then cleans up and wires states in Cursor;

• ships to a private sandbox link so leaders and users can click through safely.

AI prototyping tool stack (strengths and weaknesses)

There isn’t a single best AI prototyping tool. The trick is knowing which one to start in and when to switch. These first three promise “AI code from a prompt.” But the way they run, and what they leave out, makes them useful at different points in a sprint:

1. v0 (Vercel)

It takes prompts and references and spits out Next.js + Tailwind/shadcn components that look like a real app and are perfect for dashboards and data‑heavy screens. And because it deploys to Vercel automatically, you get a live link the same day without fiddling with hosting.

• best for: Structure and styling. You’ll get cards, tables, filters, skeletons, and surprisingly usable placeholder copy without touching Figma. 

• mind the gotchas: Theming can drift if tokens aren’t explicit, navigation/state coverage isn’t always complete, and small prompt edits can shuffle whole layouts. For production-ready code, you’ll still want a Cursor pass to tighten things up.

Here’s what v0 gave me from a one-liner: “Build a multi-page app where users can add, edit, and delete items in a shared inventory list.”

2. Lovable

What makes Lovable stand out is the integrations. Out of the box, it can set up Supabase auth/storage, sync to a GitHub repo, and drop in AI providers like OpenAI or Anthropic. That makes it a rare tool that can bridge prototype speed with production-ready building blocks.

• best for: Momentum and coverage. You can stand up sign-up and CRUD flows in under an hour, then export code and keep iterating. 

• mind the gotchas: There’s no direct code editor, so you’re prompting instead of editing. Besides, auth can be twitchy, code quality is hit-and-miss, and mobile responsiveness isn’t always great. Most teams end up exporting to Cursor for cleanup once the direction is clear.

Here’s what Lovable spun up from the same one-liner:

3. Bolt

Bolt (from StackBlitz) is an in-browser, AI-powered dev environment. It runs full Node.js stacks via WebContainers, which means you can spin up and deploy real apps entirely from your browser, with zero local setup.

• best for: Fast backend behaviors and breadth. You can prove a thin path (say, a search powered by a knowledge base) without ever bootstrapping a local repo.

• mind the gotchas: Because the server runs in your browser, there’s no persistence, meaning no accounts, no payments, no multi-user chat, no long-lived data. You can patch it with Supabase or external services, but handoff-ready code usually needs cleanup.

Here’s what Bolt generated from the same one-liner:

4. Cursor (IDE)

If v0, Lovable, and Bolt are about getting code fast, Cursor is about making that code usable. 

Think of it less as a prototyping engine and more as your AI-assisted IDE. You bring in the code, and Cursor helps you clean it up and wire up logic.

Cursor runs on top of VS Code, so it feels familiar. It can generate tests, explain confusing code, and keep your tokens and components consistent, shaping AI output into something production-worthy.

• best for: When you already have an early prototype and need to enforce discipline: normalize buttons or clean up auth. It’s also strong for ongoing dev work, since it can help with migrations and integrating APIs without context-switching.

• mind the gotchas: It won’t prototype from scratch (that’s what v0/Lovable/Bolt do). The quality also depends on how much context you give, and small prompts can lead to shallow fixes. It still requires human judgment and won’t magically make architecture decisions for you.

5. Support crew: research, low‑fi, and polish

The core stack gets you working screens. But to have a believable prototype, you also need quick ways to explore ideas and make things feel responsive enough to test. 

Here are some support tools we find useful:

• Claude for thinking through the product. It drafts briefs, golden/edge cases, and eval prompts you’ll use later.

• Perplexity for research and competitive sweeps. It’s the fastest way we’ve found to get “what good looks like” into a prompt set. Its Social mode pulls from Reddit and niche corners of the internet, so you’re grounding features in how users actually talk.

• Uizard for sketches → wireframes. It’s handy when you want a rough structure from a napkin sketch without spending half a day in layout mode.

• Figma (with First Draft + Ando plugins) for style play. Explore style variations and automate boring bits inside your main design tool.

Hard truths & guardrails (what breaks, and how teams handle it)

AI prototyping is powerful, but it’s not magic. Real teams hit walls, and they’ve been candid about it in public forums, Slack groups, and early adopter blogs. The good news: patterns repeat, and so do the fixes. Here are the biggest friction points and how teams are handling them.

“Figma → code is messy”

One‑click tools promise to turn static mockups into code. But what you might actually get is inline styles and components engineers won’t touch. Designers complain it feels like a shortcut that slows everyone down.

The fix: use AI builders for speed, not handoff. Good teams generate the first pass, then clean in Cursor (or your IDE of choice) with components and tokens, and run a side‑by‑side screenshot diff. It’s faster to admit the auto‑export is scaffolding, not production code.

“Which builder is actually good?” (v0 vs Lovable vs Bolt)

The debates get heated. v0 is praised for structure, Lovable for multi‑page flow, Bolt for full‑stack spikes. But all drift on prompts, and quality varies week to week.

The fix: skip the arguments, run a 1-hour bake-off. Same brief, same brand tokens, same tasks. Score realism (can users complete tasks?), editability (how much cleanup in Cursor?), and drift (does a small prompt nudge wreck the layout?). Most teams keep the best parts of each and merge into one repo. 

“Should designers learn Cursor?”

Short answer: yes, at least enough to wire states and transcripts. A prototype that doesn’t show loading or empty states isn’t believable. Designers don’t need to become engineers, but they do need the muscle to show interactive intent.

“Okay, when are we shipping this?’”

AI demos can look gorgeous in two days, so stakeholders might see it and ask, “Why can’t we ship this now?,” putting unrealistic pressure on engineers.

The fix: frame prototypes as decision tools. Always badge them: Prototype • Non‑prod • Synthetic data. Narrate what’s stubbed and what’s real. Agencies that set these expectations early avoid theater and keep trust intact.

"Are AI prototypes safe for data and IP?"

Prototypes often lean on synthetic or de‑identified data, but teams forget to label it. Worse: some tools log prompts and screens externally, raising privacy and IP concerns. Community threads are full of stories about prototypes “leaking” more than expected.

The fix: prototype only in sandboxes, with synthetic/de-identified data. Agencies worth trusting will say “non-prod” until you’re sick of hearing it. If you don’t, ask.

"How do we measure “good enough”?"

This is where Aman Khan’s mantra lands: “Don’t ship on vibes.” Build evals first. Define what good looks like in plain language (tone, accuracy, safety). Use judge models and human checks to score outputs against that rubric. If human labels and model labels drift, fix the rubric before you scale.

The fix: Treat evals like tests: part of the product, not an afterthought. It’s how you know an AI feature is good enough to trust in the wild.

Who to follow for ongoing AI prototyping Insights

If you want to go deeper, here are a few people and teams consistently running webinars, podcasts, and community sessions that explore AI prototyping in practice:

• Lenny Rachitsky: Curator of "Lenny’s Newsletter," where case studies on product design and prototyping frequently appear. His interviews and deep dives are a go-to for product leaders.

• Claire Vo: Host of "How I AI," a podcast blending strategy and hands-on prototyping examples. Claire regularly shares live demos and practical workflows in her sessions.

• John Zeratsky: Co-hosted a recent webinar, “Product Design in the Age of AI,” moving beyond tool lists to explore design frameworks with real context and creativity

• Peter Van Dijck: Offers a practical framework for thinking about model capabilities, experience design, and evaluation. 

• Pete Pacent & Megan LaFlamme: Leaders at Clarifai sharing on how to get past the “prototype finish line” and actually operationalize AI in live systems.

Future-proofing with AI prototyping

At Cieden, we’ve battle-tested these workflows with startups and global product teams alike. If you’re curious what “AI-native” looks like in practice, let’s talk! We’re happy to show real examples of how these playbooks cut weeks into days without losing trust.