Aakash GuptaI Should Be Charging $999 for This AI Prototyping Masterclass
CHAPTERS
- 0:00 – 2:57
Why AI won’t replace developers—but will change what PMs can build
Nadav frames AI as a leverage tool, not a magical “anyone can build anything” button. The core constraint is still understanding: if you can’t reason about what’s being built, you’ll struggle to use AI effectively for real products.
- •AI output is bounded by the builder’s understanding
- •AI is powerful for prototypes and small enabling apps
- •PMs are uniquely positioned to benefit because they already translate ideas to devs
- •Production-grade building still requires foundational technical knowledge
- 2:57 – 6:06
When PMs should use AI prototyping (and why it beats static mockups)
Nadav argues PMs should use AI prototyping constantly because functional prototypes are now the fastest way to test and iterate. The key advantage over Figma-style click-throughs is realism: users can experience behavior, not just screens.
- •Functional prototypes let users experience real interactions
- •AI makes prototypes the cheapest option time-wise
- •Use in ideation for exploring variations and expanding thinking
- •Use again post-design to validate quickly before production
- 6:06 – 8:05
Avoiding the “solution space too early” trap: problem space first
Aakash raises the critique that rapid prototyping can pull teams prematurely into solutions. Nadav agrees research and user understanding are irreplaceable prerequisites; prototyping should start after clarity on the problem and user stories.
- •Research and user communication come before prototyping
- •Prototyping tools (including Figma) can bias teams toward premature solutions
- •By the time visuals matter, the real decision—what to build—should be made
- •Use AI prototyping intentionally, not as a hammer for every task
- 8:05 – 11:43
Live demo setup: start from your existing product/design system (LinkedIn example)
They begin a Dazzle workflow by recreating an existing LinkedIn screen from a screenshot. The emphasis is on not starting from a blank canvas—PMs should anchor prototypes in the real product so new features ‘fit’ immediately.
- •Use screenshots to recreate existing UI quickly
- •Dazzle spins up a server-backed prototype, not just static UI
- •Starting from a base screen speeds future feature iterations
- •Reuse matters: the same starting point becomes a long-lived template
- 11:43 – 12:50
Team workflow: save templates and maintain a living design-system starter
Aakash and Nadav discuss standardizing the initial recreation into an org-wide template. They highlight that visual fidelity can be improved once (often with a designer) and then reused to accelerate all future prototypes.
- •Create reusable templates for teams/orgs
- •Keep templates visually and functionally close to the real product
- •Designers can perfect the template details once for everyone
- •Institutionalizing the starter project increases speed and consistency
- 12:50 – 14:38
Under the hood: theme CSS, validation checks, and why technical awareness helps PMs
Nadav explains what Dazzle generates: theme CSS (design system), components, data, and a validation step (type checks, build checks, broken assets). He also touches on Tailwind tradeoffs versus custom design systems.
- •Theme CSS acts as the prototype’s design system foundation
- •Automatic validation reduces broken states early
- •Tailwind can constrain design sameness; custom systems allow more distinct UI
- •PMs benefit from understanding what’s happening behind the scenes
- 14:38 – 17:43
Fast visual fidelity upgrades: eyedropper colors, image swaps, and layout tweaks
They correct mismatched colors by adding the original screenshot as reference and using visual edits (including an eyedropper). The point: small UI fixes are faster via direct manipulation than repeated prompting.
- •Drag in reference images to compare and match styling
- •Use visual tools (eyedropper, layout controls) for quick corrections
- •Edits are reversible and don’t require re-generation
- •Designers can help bring prototypes to ‘pitch-ready’ fidelity
- 17:43 – 19:53
Feature build #1: add sentiment analysis to posts (simple prompt, real interaction)
Nadav adds a lightweight sentiment analysis feature to LinkedIn posts via a short prompt. Aakash highlights how this unlocks progress even when a PM lacks engineering resources—prototypes become a ‘virtual developer.’
- •Small prompts can add functional UI behavior quickly
- •AI prototyping helps PMs validate ideas before engineers are available
- •Functional prototypes reduce time-to-first-shippable for new teams
- •Prototyping is about being unblocked, not only building big features
- 19:53 – 21:59
Divergent solution exploration: generating multiple implementations quickly
Aakash pushes for branching into different UX patterns, not just polishing the first result. They prompt a second variation: a separate sentiment summary section with an overall trend/graph, reinforcing iteration as the core superpower.
- •Prototype value increases with divergent exploration (2–4+ variants)
- •Use prompts to restructure layouts and information hierarchy
- •Let AI choose implementation details unless you’re very technical
- •Iterate broadly first, then perfect the best candidate
- 21:59 – 24:42
Prompt clarity over “prompt engineering”: discuss mode, ambiguity, and contradictions
They argue the limiting factor isn’t fancy system prompts but clear product intent. Nadav explains AI won’t push back like a developer, so ambiguity gets misinterpreted; he recommends ‘discuss/plan mode’ and using an LLM to find contradictions.
- •AI won’t warn you when requirements don’t make sense
- •Miscommunication is the #1 source of wasted time
- •Use plan/discuss mode before major changes
- •Ask an LLM to critique prompts for ambiguity/contradictions
- 24:42 – 28:00
Why Dazzle differs from Bolt/Lovable/Artifacts: real server apps + AI-aware inspection tools
Nadav positions Dazzle as producing standard server-side + client-side web apps that can run anywhere, not proprietary artifacts. A key differentiator is that debugging/inspection state is exposed to the AI, making it smarter at edits and fixes.
- •Outputs are portable, standard web applications
- •Full server-side capability enables realistic behaviors and integrations
- •Inspection/debugging data is shared with the AI to improve accuracy
- •Strong connection between selected UI element and underlying code
- 28:00 – 42:49
Editing spectrum: visual inspector, persistent CSS changes, and understanding components
They walk through element selection, component vs instance distinctions, and how edits persist directly to code (unlike transient browser devtools). Nadav contrasts this with Cursor’s approach, which ‘visually prompts’ and then waits for an LLM to rewrite code.
- •Component vs instance vs raw HTML (div) matters for safe edits
- •Inspector edits persist immediately into project files
- •Viewing bound data helps debug where flows break (e.g., item counts)
- •Cursor visual edits often require an LLM rewrite—less immediate feedback
- 42:49 – 48:47
When to edit visually vs with AI vs in code (and common PM mistakes)
Nadav argues PMs shouldn’t need to edit code except when something fails; immediacy is the reason to prefer visual editing for small tweaks. He warns against huge prompts and recommends breaking work into steps to avoid AI context-switch failures.
- •Visual editing is best for fast, low-risk UI tweaks
- •AI generation is best for big leaps (initial build, major changes)
- •Code edits are a fallback for debugging or for those already proficient
- •Avoid mega-prompts; split tasks to reduce context-switch errors
- 48:47 – 52:00
Going multi-page and adding edge cases: prototyping end-to-end user flows
They extend the prototype to a multi-page flow: clicking a post navigates to a dynamic page explaining sentiment and showing comments by sentiment. Aakash frames this as the real power of prototyping—surfacing edge cases before engineering builds.
- •Multi-page prototypes model real navigation and behavior
- •Prototypes reveal edge cases early (too few posts, too many, etc.)
- •End-to-end flows reduce downstream engineering questions
- •Clarity in requirements matters more as complexity increases
- 52:00 – 58:25
When to go high-fidelity: selling, usability testing, and avoiding ‘Frankenstein’ prototypes
Nadav explains high fidelity as a strategic tool: it sells ideas internally and produces better usability feedback with users. Their workflow: low-fidelity internal exploration first, then high-fidelity once a direction is chosen to validate quickly.
- •High fidelity helps win buy-in from stakeholders and leadership
- •Usability testing is more valid with realistic fidelity
- •Avoid mixed-fidelity (‘Frankenstein’) experiences
- •Progression: low-fi variations → select winner → high-fi for user validation
- 58:25 – 1:16:45
Engineer handoff and the new standard: prototype + PRD, with specs stored in the project
They cover handoff options: share the published link, export standard code, and (soon) use Git integration. Nadav argues PRDs don’t disappear—they complement prototypes by capturing edge cases and becoming AI-readable context when stored alongside the codebase.
- •Sharing a working prototype answers ~90% of developer questions
- •Exportable standard code enables ‘copy behavior’ via dev AI tools
- •Store specs/decisions as files in the project for reuse and AI context
- •New baseline: prototype covers main flows; PRD documents edge cases
