Every Vibe Coder Needs to Hear This (2025 Advice to self)

Show Notes

Parker breaks down when vibe coding works, when it doesn’t, and how to actually ship reliable AI-driven features with solid prep instead of chasing hype.

Quick takes on tools and market

• ChatGPT pricing: reportedly expensive with not clear gains vs. DeepSeek; recent app release and price changes are notable.
• Google Gemini Code Assist: part of Google’s push into code-assist tooling; signals from leaked memos suggest they’re playing free-for-now play to stay competitive.
• Deep Research: a favorite for digging into ideas and turning research into artifacts (e.g., turning Turntable FM research into a 16-page PRD).

Abe Lincoln vibe and the vibe-coding spectrum

• Abe Lincoln vibe concept: thorough prep before “doing” the coding work. Sharpen the axe first.
• Vibe coding effectiveness model (three parameters):
  1. Vibe code effectiveness (0-100%)
  2. Skill level of the person doing the work
  3. Project difficulty
• The takeaway: even with top-tier talent (like Andre), high-difficulty projects rarely reach 100% vibe code. Most people sit toward the left; easy projects can hit 100% with solid prep.
• Practical implication: map projects along difficulty vs. vibe-code readiness; prep-heavy tasks should push the effectiveness toward 100%.

Practical example: AI art gallery page and prompts

• Quick data structure approach:
  • Data: name, prompt, model, image file, metadata
  • Use Shad CN components for UI structure; ensure consistent toast notifications
• Why it matters: small inconsistencies (like different toast libraries) derail accuracy and UX. Define a single pattern early.
• Takeaway: start with data structure and UI scaffolding, then layer in AI-driven generation with a well-defined prompt spec.

Hybrid workflow: PRD + prompt spec

• Core idea: vibe coding plus solid research produces high-quality prompts and results.
• PRD patterns:
  • Pitch format: problem, solution, sketches, customer anecdotes, rabbit holes (things to avoid), timeboxing
  • Variants: PRD + technicals; PR FAQ (Amazon style)
• Human roles:
  • One technical PM to draft the PRD
  • One semi-technical builder to translate into prompt specs and code hooks
• From PRD to prompt spec:
  • Identify files, functions, APIs, and data touched
  • Create a prompt spec that maps to actual code changes
  • Use external sources (GitHub snippets, OSS examples) to bootstrap
• Key practice: the “spec prompt” should orchestrate both the product aim and the technical details to reduce 80%/20% gaps.

Turntable FM as a planning example

• Domain architecture basics:
  • Users, rooms, avatars, activity data, chat, and real-time cues
• UI components and scenes:
  • Room page, chat pane, scoreboard, pulsating speaker, user cards, song banners
• Data modeling notes:
  • Rooms with members (arrays/foreign keys), user avatars, timestamps
• Practical tips:
  • Start with a rough domain model, then map to UI components and routes
  • When evaluating tech, look for OSS real-time chat patterns and reuse where sensible
• Outcome: use the PRD to drive the architecture, then fill in tech details with targeted snippets and external references.

Client memory bank workflow (active context and project brief)

• Concept: keep context current and reusable as you iterate
  • Active context: current focus or task
  • Product context: overview of the project, examples, and constraints
  • Progress: track what’s done and what’s next
  • Project brief: living document that ties the spec prompt to real work
• Example workflow:
  • Create a spec prompt (e.g., “Generate a fake PRD for live chat like Slack, include TS snippets and file tree”)
  • Extract useful snippets and drop them into the project brief
  • Use the brief to guide future iterations and memory recall
• Practical takeaway: evolve a single source of truth (the project brief) that feeds back into prompts and code.

Example prompt spec you can try

• Draft prompt (conceptual):
  • Generate a fake product requirements document for a Slack-like live chat
  • Include TypeScript snippets, component names, and a file tree
• Sample TS scaffold (illustrative):

type PRDSnippet = {
  problem: string;
  solution: string;
  customers: string[];
  features: string[];
  milestones: string[];
  successMetrics: string[];
  risks: string[];
  integrations?: string[];
};

• Use this as a starting point to populate your project brief and drive design decisions.

Quick notes on tooling and approach

• Reading docs and code matters more than chasing a perfect one-shot prompt.
• Domain-driven scaffolding: define models first (users, rooms, avatars, etc.) before UI.
• Consider OSS patterns for real-time features instead of reinventing the wheel.
• Self-host docs and middleware tools (like Compose.io) are interesting but may be overkill if LLMs get robust enough to handle most needs.

Final tips

• Know your stuff: read the docs, study good code, and build a strong prompt spec from real patterns you’ve seen.
• Use the PRD + technicals approach to keep scope tight and reduce derailment.
• Expect to iterate: the project brief is your living artifact that drives the memory bank workflow.

Links

• Google Gemini - Deep Research AI tool
• Google Gemini Code Assist - AI coding assistant
• shadcn/ui - UI component framework
• Composio - Integration platform for AI agents