How to vibe code a real app: an uncut 2.5-hour build session

Executive overview

Building with AI tools is not linear. This session shows the real texture of vibe coding: version mismatches, CORS errors, debugging loops, and the constant tension between moving fast and understanding what was built.

The workflow pairs a smart planning model (Gemini 2.5 Pro or o1) for spec, blueprint, and detailed prompts, with a faster execution model (Claude 3.5 Sonnet) inside Cursor for implementation. Keep prompts small and the codebase modular — 500-line file limit — so errors stay traceable.

The core insight: outsource thinking to the smartest model; outsource execution to the most obedient one.

The planning workflow before writing any code

• Interview a model (o3 mini high) to produce a spec (the what)
• Feed the spec to Gemini 2.5 Pro or o1 to produce a blueprint (the how)
• Ask the same model to generate detailed per-chunk implementation prompts and a to-do markdown
• Gemini outputs ~65k tokens vs o1's ~10k — more prompts, more granularity
• The to-do file becomes the AI's roadmap; reference it every iteration

Working inside Cursor

• Use 3.7 thinking for diagnosis and open-ended problems; use 3.5 Sonnet for execution
• 3.5 follows blueprint prompts more obediently; 3.7 overthinks and adds noise
• Global rules in Cursor enforce file structure, modularity, and a 500-line cap per file
• Always start a fresh chat between major prompt chunks — smaller context improves one-shot success rate
• Use Super Whisper for dictation; faster than typing long prompts

Debugging strategy

• Ask for root cause first, no fix yet — prevents the AI from guessing and spiralling
• If logs are sparse, ask the AI to add print statements before diagnosing
• Use browser DevTools (console + network) to give the AI concrete error context
• Long chats accumulate bad context; copy a summary into a fresh chat instead of continuing
• When stuck, use repomix/eek to flatten the codebase into a single file and pass it to Gemini for a broader view

Version and dependency issues

• AI models have knowledge cutoffs; they will reference outdated library versions
• Versioning mismatches (e.g. Cloudflare Workers URL format) are a common early blocker
• Always toggle web search when asking about specific library APIs — don't rely on training data
• Add official docs to Cursor's Docs section; fall back to @web when indexing fails
• pip freeze captures the current installed environment into requirements.txt without retyping

Iterating on the UI

• Take screenshots and share them directly with the model — multimodal context is faster than description
• Ask "discuss first, don't change yet" before applying UI fixes — avoids irrelevant or breaking changes
• Use ShadCN + Tailwind; always check for deprecated components (e.g. toast → sonner)
• Be explicit: "be targeted and minimal" with every change request, including to-do updates
• Revert to a known-good checkpoint rather than trying to unwind a bad diff

The extraction pipeline (LlamaParse + Gemini Flash)

• LlamaParse premium mode is significantly more accurate on complex PDFs — default mode produces ordering errors
• Credits are hard to track in the LlamaParse UI; build a tracking mechanism via the API
• Gemini Flash 2.0 is ~5x cheaper than Claude 3.5 Haiku for token-heavy extraction tasks
• Use structured output (response schema) rather than relying on system-prompt formatting instructions
• Set temperature to 0 for deterministic structured extraction
• When the extraction model ignores the schema, switching MIME type to application/json can help