Notes — Lazar Jovanovic on Vibe Coding as a Profession, the Genie Framework, and PRD-Driven Development
Four questions [Adler frame]
Q1 — What is it about? A practitioner account of professional vibe coding — building production software without writing code, using AI agents as the implementation layer. The episode documents the methods a full-time professional vibe coder uses to manage the two fundamental constraints: context window limits (the machine) and clarity of intent (the human).
Q2 — How is it argued? From direct operational experience. Jovanovic has no software engineering background and arrived at these workflows by iterating on what broke. The argument is essentially empirical: here is what I tried, here is what the failure mode was, here is what I do instead. The genie metaphor provides the conceptual spine; the PRD system and four-by-four debugging are the practical outputs of testing.
Q3 — Is it true? The core claims — that clarity of intent is more valuable than coding skill, that PRD documents extend the effective context window, that parallel builds converge on design direction more efficiently than iterative refinement — are plausible and consistent with what other vibe coding practitioners report. The specific numbers (80/20 split on planning vs execution, 4 parallel builds as the sweet spot) are his personal calibration and will vary. The “AI is 100% always your fault” claim is rhetorical overstatement; models do hallucinate and make errors independent of prompt quality.
Q4 — What of it? The actionable output is the system design: masterplan.md → implementation.md → design-guidelines.md → user-journey.md → tasks.md → rules.md. This workflow maps onto any context where you want an AI agent to maintain coherent long-horizon work without losing context. The debugging framework (four-by-four) is immediately applicable. The design exposure principle — deliberately consuming world-class design to calibrate your taste — is the harder and more important long-term investment.
Glossary
Vibe coding — Building software by narrating intent to an AI agent without looking at or being responsible for the generated code. Jovanovic’s professional version extends this with structured planning systems. [§ What vibe coding is in practice]
Context window — The finite token budget an AI model has to read, think, and produce output in a single interaction. Managing context allocation is the central skill in professional vibe coding. [§ Context management]
PRD (Product Requirements Document) — In Jovanovic’s usage, not a traditional spec doc but a planning file that acts as persistent context for the agent across sessions. He generates at least four before writing code. [§ PRD-driven development]
Genie framework — The Aladdin analogy for clarity: the genie grants the literal wish, not the intended one. Applied to AI: you get what you specify, not what you mean. [§ Genie framework]
Rules.md — An agent configuration file (native in Cursor, Lovable project settings) that tells the agent how to behave persistently across all sessions. The long-term memory layer. [§ PRD-driven development]
Vibe (exploratory) vs PRD-driven (production) — Two modes Jovanovic distinguishes: vibe is for prototyping and exploration; PRD-driven is for production-quality builds. Using vibe mode on a production project is how you dig the hole. [§ When to use which]
The two constraints [§]
Every failure in vibe coding traces to one of two constraints:
Machine constraint — context window: A finite token budget is allocated across: (1) reading existing files and code, (2) browsing the web, (3) thinking, (4) producing code. In a large codebase with an unclear error, the agent may spend 80% of its budget on reading and have only 20% for reasoning and output. The result is a low-confidence fix that may not actually resolve the problem. The agent will claim it fixed the issue regardless, because models are trained to be agreeable.
Human constraint — clarity: The human does not know what they want precisely enough to specify it. The AI builds the literal interpretation. Vague inputs produce technically correct but misaligned outputs. The 13-feet-tall genie is the canonical example: “make me taller” is an instruction with many valid completions, none of which the asker wanted.
Most vibe coding failures fall into the human constraint category, not the machine constraint.
The genie framework [§]
The Aladdin analogy, applied:
- You rub the lamp (send a prompt).
- The genie appears with finite wishes (the context window).
- You ask for “taller.” The genie makes you 13 feet tall because you were not specific.
Implications:
- Be specific. “I want to be 6’2” with proportional limb lengths and no change to my centre of gravity” is a viable wish. “Be taller” is not.
- Scope each request. Asking for 10 things at once consumes most of the wish budget on interpretation, leaving little for execution.
- Don’t make the genie apologise. When AI apologises and tries to reassure you, it spends tokens on social repair rather than problem-solving. Stay neutral; do not express frustration.
The meta-lesson: spend time on wish-crafting before touching the lamp. Jovanovic spends 80% of his time in planning/chat mode and 20% in execution mode. The ratio feels wrong until you understand that poorly-specified prompts waste far more resources on downstream correction than the planning time costs.
PRD-driven development [§]
Motivation: AI agents forget earlier messages as a session grows. After message 20–30, the earliest context begins to drop out. Without reference documents, the agent optimises for recent context only, producing inconsistent results. PRD files solve this by making context portable and persistent.
The five-document system:
| File | Content | Purpose |
|---|---|---|
masterplan.md | 10,000-foot overview: intent, audience, how the user should feel | Sets the agent’s mental model of the project |
implementation.md | Ordered sequence of technical decisions: backend first, then auth, then API, etc. | Prevents the agent from building in the wrong sequence |
design-guidelines.md | Exact visual rules: fonts, colours, spacing, CSS snippets for critical elements | Controls visual output; prevents overcreative AI design choices |
user-journey.md | Full primary and secondary user flows | Grounds feature decisions in real usage sequences |
tasks.md | Granular subtasks derived from all four documents above | The day-to-day execution queue; agent reads this before every action |
Rules.md (sixth document, different nature): goes in the project settings, tells the agent to read all PRDs before acting, proceed one task at a time, report what was done and how to test it.
Result: Prompts collapse to “proceed with next task.” The agent maintains coherence across sessions without the human needing to re-explain the project. Context allocation shifts from reading/interpreting to reasoning/executing.
How to generate PRDs: Use chat mode with the AI itself. Brain dump the idea; the AI asks clarifying questions and generates the four documents. Jovanovic built a custom GPT (searchable as “Lovable PRD generator”) that does this automatically.
Four parallel builds [§]
Why single-direction refinement fails: You commit tokens to a direction before knowing if it is right. By message 20, the design is established; changing it costs more than starting over.
The four parallel build sequence:
-
Voice/brain dump — Use Lovable’s voice mode or Wispr Flow. Say everything you know about the project without filtering. Press send without waiting for it to finish. Open a new tab.
-
Typed deliberate prompt — Sit with the brain dump output. Identify the clearest thread. Write a more structured prompt: specific features, pages, user types. Attach to a new project.
-
Visual reference — Go to Mobbin (UX flows) or Dribbble (UI aesthetics). Find a screenshot of something close to what you want. Attach it as an image. Most tools accept this as input and will interpret design intent from it.
-
Code snippet — Find a component library (21st.dev, DotBuild) with a component similar to what you need. Export the code snippet. Attach it. The agent interprets code better than natural language for precise visual requirements.
After four builds: The winner is usually obvious within one or two additional calibration prompts. Then: start the PRD process on the winner.
Why it saves tokens: Starting from the right direction eliminates hundreds of correction prompts. The upfront cost of four builds is recovered by session three.
Four-by-four debugging [§]
When something breaks, Jovanovic runs exactly one attempt at each of four steps before escalating:
Step 1 — Try to fix (agent-native): Lovable and similar tools label mistakes in orange with a “Try to Fix” button. Click it. Most small issues resolve here.
Step 2 — Console logging (awareness layer): If the agent does not detect the problem (common with third-party integrations), manually add console.logs to relevant files. Reload the app. Copy the console output. Paste it into the chat. The agent now has the information it was missing to find the issue.
Step 3 — External diagnostic (Codex or Repomix): Export the project to GitHub. Import into Codex (OpenAI) for code review and diagnosis — but do not let Codex make changes. Use it only to identify the problem. Alternatively: use Repomix to compress the entire codebase into a single file; upload to Claude or ChatGPT with the console logs. This is like hiring an outside consultant who can see the whole picture without being the one who will make the fix.
Step 4 — Revert and re-prompt: Go back in version history (Lovable, Cursor, and Claude Code all have this). Return to a state before the problem. Rewrite the original prompt with more precision. The failure is almost always a bad input, not a broken tool.
After every successful fix:
Ask the agent: “What about my prompt caused this? How should I prompt you differently to avoid it?” Update rules.md with the answer. Prevent the same class of error from recurring.
The professional vibe coder role [§]
Jovanovic’s career path is itself an argument for the thesis: a forestry engineer who waited tables, did community management, and stumbled into Lovable via no technical background. The role emerged from building in public — publishing workflows on LinkedIn and YouTube — and being noticed by Elena Verna.
What the role actually covers:
- Internal tools (custom analytics dashboards, feature adoption tracking, enterprise CRM flows)
- External product features (Shopify integration templates, the Lovable merch store)
- GTM assets (product marketing pages, experiment landing pages)
The “build vs buy” calculation: For a professional vibe coder with Jovanovic’s velocity, the setup time for an enterprise SaaS tool (1–2 hours) now competes with just building the tool. He is in the “build” camp for almost everything custom.
The horse analogy: When the steam engine arrived, the horse population in the US collapsed 90% within 20 years. The person who was hired to do a technical job became obsolete six months later — faster than horses. The only career-safe investment is in human-specific capabilities: judgment, taste, emotional intelligence, creativity.
Design as the durable skill [§]
Jovanovic’s hierarchy of skills in the AI coding era:
- Judgment — knowing what to build, whether it should be built, whether the output is world-class or merely good enough
- Design taste — knowing what good looks like; recognising the difference between a gradient with 3 colours and one with 50 colour/opacity layers
- Copy — AI-generated copy is identifiable within three seconds; great copy is a scarce and durable signal of human craft
- Technical orchestration (temporary) — the PRD system, context management, prompt engineering; these will be automated
How to build design taste:
- Follow world-class designers on social media and watch their process videos (not just the output)
- Use Mobbin and Dribbble as a daily reference library
- Try to replicate great designs and observe the gap between your result and the original
- Deliberately build apps in different design styles to understand the vocabulary (Jovanovic built a public UIstyle app cataloguing 18 styles with prompts to replicate each)
The key insight: a Figma gradient that looks “simple” might be built from 50 layers. That gap between what looks simple and what is actually sophisticated is the taste gap. Closing it requires exposure time, not technical skill.