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:

1. Scope ruthlessly: Build only the happy path. Every additional screen doubles complexity.
2. Name everything: Give every button, screen, and action a clear name in your prompt. Vague references produce vague results.
3. Use real text: "Lorem ipsum" kills the realism. Use real product copy in the prototype.
4. Share early: A rough prototype with real data is more useful in user testing than a polished static mockup.
5. 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