Phase 0: Vibe Coding Fundamentals · 30 min · Claude Code, Cursor, Lovable, v0, Bolt.new, Replit Agent, or similar
Objective
Your mission
You're going to direct a real build using three roles: describer, reviewer, decider. By the end, you'll have a director_playbook.md with a build description, a review of the AI's output, and specific corrections — proving you can direct, not just accept.
You need: An AI coding tool (Lovable, v0, Bolt.new, Cursor, or similar).
Time: 30 minutes.
Step 1: write the description (5 min)
Before opening any tool, write a description for something small. Use this framework:
- What it is: "A single-page expense tracker"
- Who it's for: "Just me, tracking personal expenses"
- What it does: "Add expense with amount, category, date, note. Show list sorted by date. Show total at top."
- What it looks like: "Clean, mobile-first, light mode, blue accent (#2563eb)"
- What you don't want: "No login, no backend, no charts — localStorage only"
Bad: "Build me a website" Good: "Build a single-page expense tracker. Add expense with amount, category, date, and note. Categories: Food, Transport, Office, Other. Show list sorted by date descending. Show total at top. Clean UI, mobile-first, light mode, blue accent (#2563eb). Use localStorage — no backend, no login, no charts."
Write your description in your file:
## My Build Description
[Your full description here]
Step 2: feed it to the AI and watch (5 min)
Open your tool. Paste your description. Watch it build.
Don't accept yet. Don't iterate yet. Just watch.
Step 3: review the output (10 min)
Now you're the reviewer. Check against your spec:
- Does it do what you described? Go through each feature. Does it work?
- Does it look right? Layout, colors, mobile view?
- Is anything broken? Click every button. Enter values. Try edge cases (empty input, 0, very large number).
- Is anything suspicious? You shouldn't see API keys, passwords, or tokens in the code.
Write your review in your file:
## Review of AI's First Build
What works: [list features that match your spec]
What's wrong: [list things that don't match]
What's missing: [list features from your spec that aren't there]
What's suspicious: [anything odd in the code — or "nothing found"]
Step 4: write specific corrections (5 min)
Don't write "fix it." Write specific, actionable changes.
Bad: "Fix the layout" Good: "Make the categories buttons instead of a dropdown — Food, Transport, Office, Other, each a clickable pill. Move the total to the top, above the expense list. Default the date picker to today."
Write your corrections in your file:
## My Corrections
1. [Specific change 1]
2. [Specific change 2]
3. [Specific change 3]
Then apply them to the AI tool. See if the output improves.
Step 5: reflect on the three roles (5 min)
Which role was easiest? Which was hardest?
## Role Reflection
Describer (writing the spec): [easy/hard — why?]
Reviewer (checking the output): [easy/hard — why?]
Decider (choosing what to change): [easy/hard — why?]
The cost of abdicating all three roles
When you abdicate describing (vague prompt), reviewing (accept everything), and deciding (let the AI pick the approach), you get a build that nobody directed. Every real vibe-coded security incident started with someone abdicating the reviewer role — the AI generated working code that omitted security configuration, and nobody checked.
The app the AI built works, so you accept it without checking it against your spec or looking for exposed keys. Which director role did you give up?
Reviewing means checking the output against the spec and for red flags. Every real vibe-coding security incident in the lesson started with someone skipping that role.