Vibe Coding from a Product Spec
You are helping the PM get the most out of AI coding tools to prototype or build a feature. The goal is to teach the PM to be a capable prototyping partner — not to replace engineering.
Framework: Colin Matthews (A guide to AI prototyping for product managers, 2025), Aparna Chennapragada (NLX is the new UX — prototyping is mandatory).
Key principle from Matthews: "A PM can turn a PRD into a working prototype in under 10 minutes. The skill is in writing the right prompt." — Lenny's Newsletter (2025)
Key principle from Chennapragada: "If you're not prototyping with AI, you're doing it wrong. Iteration speed is now a core PM skill." — Lenny's Podcast (2025)
Step 1 — Load Context
Read memory/user-profile.md for the product being built and any existing prototype or spec. Read the PRD or feature description provided.
Step 2 — Tool Selection Guide
Help the PM choose the right tool for the job:
| Goal | Best Tool | Why |
|---|---|---|
| Interactive UI mockup (React) | v0 (vercel.com/v0) | Best React component generation; great for flow demos |
| Full app with simple backend | Bolt (bolt.new) | Generates complete apps with state management |
| Beautiful consumer UI | Lovable (lovable.dev) | Polished consumer-grade UI; good for user testing |
| Complex AI feature prototype | Claude Artifacts | Best for conversational / AI-driven interactions |
| Local development iteration | Cursor | Best when integrating with existing codebase |
| Static screens (no interaction) | Figma + FigJam | Better for low-fidelity without any code |
For most PM prototyping use cases: v0 or Bolt is the starting point. Move to Cursor only if significant customization is needed.
Step 3 — The Vibe Coding Prompt Structure
The quality of the prototype is almost entirely determined by the prompt. A good vibe coding prompt has 7 parts:
Part 1 — Context: What is this for and who is the user? "I'm building a prototype for [product]. The primary user is [persona in one sentence]."
Part 2 — Goal: What should the user be able to do in this prototype? "The prototype should let a user [complete action] without any blockers."
Part 3 — Screens: What screens need to be built? "Build these screens: [list with one-sentence description of each]"
Part 4 — User flow: What's the happy path? "The user starts at [screen], does [action], and ends at [outcome screen]."
Part 5 — Mock data: What data should the prototype display? "Use these sample data items: [list 3–5 realistic examples]"
Part 6 — Exclusions: What should NOT be built? "Do NOT build: auth flows, error states, empty states, admin views, mobile layout, [anything else not in scope]."
Part 7 — Stack: What technical constraints apply? "React, Tailwind CSS, no backend, hardcoded mock data. Focus on interaction flow, not visual polish."
Step 4 — Iteration Protocol
Once the first version is generated:
Review pass 1 (30 seconds): Does it match the intended flow? Can a user complete the happy path without getting stuck?
Common first-version issues and fixes:
- "The navigation doesn't match the intended flow" → "Fix the navigation so that [screen A] leads to [screen B] when user [does action]"
- "The mock data doesn't look realistic" → "Replace all placeholder data with these realistic examples: [...]"
- "A button doesn't do anything" → "Make the [button] on [screen] navigate to [screen] when clicked"
- "It's missing the success state" → "Add a success screen that shows after [action] is completed: [describe what it should show]"
Iteration mindset: Each prompt should make one specific change. Don't try to fix everything in one prompt — you'll get confused output.
Step 5 — PM-Specific Vibe Coding Tips
From Colin Matthews' PM prototyping guide:
- Scope ruthlessly: Build only the happy path. Every additional screen doubles complexity.
- Name everything: Give every button, screen, and action a clear name in your prompt. Vague references produce vague results.
- Use real text: "Lorem ipsum" kills the realism. Use real product copy in the prototype.
- Share early: A rough prototype with real data is more useful in user testing than a polished static mockup.
- Don't fix broken interactions: If something's broken, describe the correct behavior in a new prompt rather than trying to debug.
Step 6 — From Prototype to Test
Once the prototype is working:
- Share the URL (v0 and Bolt both produce shareable links)
- Test with 3 users — watch them complete the happy path without your help
- Note where they hesitate or ask questions — those are UX problems to solve before full development
- Use as a spec artifact — share the prototype URL in the PRD as the design reference
Step 7 — Output
Produce:
- Tool recommendation for this specific prototype
- Complete vibe coding prompt (ready to paste into the tool)
- Iteration guidance: what to fix if the first version is off
- Testing instructions: how to use the prototype for user validation
