Aakash GuptaIf you can’t AI prototype after this, nothing will help you
CHAPTERS
Why most AI prototypes feel like “slop” (and why that’s fixable)
Aakash introduces Sachin Rekhi and the central objection he hears: AI prototypes look impressive from a simple prompt, yet still aren’t shippable. Sachin frames the episode as a path from generic one-shot outputs to high-craft prototypes that can actually inform real product decisions.
- •Common reaction: “All AI prototypes are slop” despite flashy initial demos
- •Why a simple prompt can create a functional mini-app but still be unusable for real product work
- •Episode promise: move from novelty to repeatable, high-quality prototyping practice
- •Who Sachin is and why he teaches PMs AI prototyping (LinkedIn, Reforge, SF Tech Week)
Anthropic’s “prototype-first” roadmap: prioritizing problem–solution pairs
Sachin contrasts the standard roadmap flow (prioritize problems, then design solutions) with Anthropic’s approach: prototype multiple solutions first, dogfood internally, and only then decide what to productionize. The key shift is prioritizing validated problem–solution pairs rather than abstract problems.
- •Traditional flow: roadmap problem → then ideate solution
- •Anthropic flow: build many prototypes → internal dogfooding → productionize winners
- •Benefit: roadmap decisions are grounded in tested solutions, not guesses
- •Prototyping becomes a prioritization tool, not just a design activity
Product shaping: making Apple-level prototyping feasible for everyone
Sachin introduces “product shaping” as the discipline of prototyping multiple solutions, testing with customers, and deciding what to build. He explains how only elite companies historically could afford extensive prototyping, but AI makes it cheap enough for most teams to adopt.
- •Definition: product shaping = prototype → test → choose what to build
- •Apple lab example and the iPhone origin story (tablet tech → phone pivot)
- •Historically expensive prototypes limited the practice to a few companies
- •AI reduces cost/time so broader teams can shape products this way
Diagnosing “AI slop”: generic design, no differentiation, shallow scenarios
Using a CRM example, Sachin explains why AI-generated apps often fail the bar for real products. The outputs are typically visually generic, undifferentiated versus incumbents, and don’t reflect true customer workflows—yet the underlying tools can still produce great results with the right skills.
- •Generic styling that resembles wireframes, not a crafted product
- •Lack of differentiation: “looks like every other CRM”
- •Basic scenarios don’t match real customer productivity needs
- •Takeaway: AI can create high-quality prototypes, but it requires technique
The AI Prototyping Mastery Ladder: 15 skills from apprentice to master
Sachin lays out a structured ladder for learning AI prototyping as a craft. Apprentice skills include prompting, editing, and design consistency; Journeyman adds versioning/debugging, divergence, and validation; Master includes functional prototypes and product shaping workflows.
- •15 skills grouped into Apprentice → Journeyman → Master levels
- •Apprentice: prompting, iterative editing, achieving design consistency
- •Journeyman: versioning, debugging, diverging, customer validation techniques
- •Master: functional prototypes, scalable shaping and prioritization
Design consistency via baselining: recreate your product, then refine it
Sachin demonstrates baselining in Bolt by recreating a screenshot of his product NoChoy, then iteratively editing details until it matches the real UI. The goal is a reusable template so future prototypes inherit the product’s look and feel automatically.
- •Start by recreating a screenshot for the highest fidelity baseline
- •Iterate through small edits (alignment, colors, buttons) to match the real product
- •Batch related edits to reduce iteration time while keeping changes versionable
- •Turn the refined project into a shared baseline (duplicate/fork or template feature)
Exploration prompts on top of a baseline: prototyping “Ask AI” in-context
With the NoChoy baseline established, Sachin uses an “explore style” prompt to prototype an Ask AI feature with multiple entry points. Because the prototype is built on the baseline, the new feature looks native and quickly reaches meaningful UX interaction decisions.
- •“Explore” prompt = intentionally underspecified to invite solution discovery
- •AI proposes multiple entry points (header and footer buttons)
- •Baseline inheritance yields native styling without extra design-system prompting
- •Prototype creates components and interactions, accelerating real UX decisions
Diverging: generate multiple design directions (Magic Patterns + Bolt)
Sachin shows why divergence is a “secret weapon”: AI should produce many alternatives, not a single mock. He demos Magic Patterns’ built-in divergence to prototype “News in Your Network” on LinkedIn, then repeats the approach in Bolt to show tool-to-tool variation.
- •Diverging replaces one-shot prototyping with many variants to compare
- •Magic Patterns generates multiple UI concepts (feed item, cards, sidebar, etc.)
- •Even without native features, you can prompt tools to output multiple designs
- •Different tools/system prompts produce different ideas—use multiple tools for breadth
From prototype to functional app: deploying and wiring real LLM calls
Sachin levels up the Ask AI prototype into a deployed, functional experience: real note content, real prompts, and responses via OpenAI API, plus a model selector for comparison. He explains the practical workflow of adding API keys and securing secrets in modern prototyping tools.
- •Publish a functional prototype to a live URL for realistic testing
- •Wire OpenAI API calls via prompt-driven implementation and API-key setup
- •Add a model selector to compare outputs across models during product discovery
- •Secrets management: tools increasingly store keys securely (env/secret stores vs client-side)
Customer validation at scale: in-prototype surveys + analytics + session replay
Sachin demonstrates how functional prototypes enable scaled feedback loops beyond 1:1 interviews. He embeds an in-app survey, integrates PostHog for analytics, instruments specific events, and uses heatmaps/session replays to identify friction and simplify the UI.
- •Embed survey prompts inside the prototype to capture immediate reactions
- •Use analytics (DAU/WAU) to gauge return usage and early retention signals
- •Instrument custom events for entry-point decisions and feature engagement
- •Session replays + heatmaps reveal friction and what users actually do (not what they say)
PM vs designer vs collaborative prototyping—and why prototypes are for discovery
They discuss who should prototype: PM-led, design-led, or collaborative, each with tradeoffs. Sachin emphasizes prototypes should primarily support discovery and validation, not replace engineering delivery—since prototype code is often not production-grade.
- •Three operating models: PM-led, design-led, or PM+designer collaboration
- •PM prototyping can reduce “lossiness” translating customer needs to designs
- •Discovery focus: iterate, test, validate, choose direction before engineering invests
- •Prototype code is typically not scalable/maintainable—engineers still build production
Workflows vs agents (and why PRDs aren’t dead): strategy still matters
Sachin addresses the idea that prototypes replace PRDs, arguing prototypes capture UX/functional requirements but not strategic rationale. They outline what still must be documented: differentiation, acquisition/monetization logic, hypotheses, metrics, and open questions—even in an AI-first workflow.
- •Prototypes don’t answer strategic questions (why now, why us, go-to-market, monetization)
- •PRDs can shrink on UX detail but must retain strategy and decision framework
- •Key non-prototype artifacts: hypotheses, North Star/guardrails, diagnostics, open questions
- •Long-term vision: tighter integration with codebases via engineering tools, but discovery value stands today
AI prototyping tools face-off: categories, tradeoffs, and what to choose
Sachin maps the tooling landscape into three buckets: AI app builders, purpose-built prototyping tools for product teams, and engineering AI coding tools. He shares practical selection advice—start with lowest-friction access in your org—then offers opinionated picks depending on needs and technical comfort.
- •Category 1: AI app builders (Bolt, v0, Replit, Lovable, Firebase Studio, AI Studio, GitHub Spark, etc.)
- •Category 2: AI prototyping tools (Reforge Build, Magic Patterns, Figma Make, Alloy) with team-centric features like diverging/templates/context
- •Category 3: AI coding tools (Cursor, Claude Code, Codex CLI) for robustness and codebase reuse, but higher learning curve
- •Hot takes: Cursor as a powerful “upgrade pick”; Magic Patterns as a strong on-ramp for fast divergence
