Professional Vibe Coding: How Lazar Jovanovic Gets Paid to Build with AI
Lazar Jovanovic gets paid to vibe code at Lovable. He's never written code manually. His frameworks for AI success: the three wishes rule, parallel project building, planning with MD files, and a 4x4 debugging workflow.
Lazar Jovanovic works as a professional vibe coder at Lovable, where he gets paid to build products using AI tools. He's never written a line of code manually. His job involves shipping both internal tools and public-facing products by prompting AI to generate everything from marketing templates to complex integrations.
What makes his approach work isn't technical knowledge - it's a set of frameworks for getting AI to produce quality output consistently.
The three wishes rule
Jovanovic uses an Aladdin metaphor to explain how AI context windows work. When you ask a genie for three wishes and say "make me taller," you might end up 13 feet tall because you weren't specific. AI tools face a similar constraint: they have limited tokens to read your code, understand the problem, and execute a solution.
If your codebase has 70 files and you report a vague bug, the AI spends 80% of its token allocation just reading files to find the problem. That leaves only 20% for thinking and fixing it. When the context window fills up, the tool often picks the easiest fix rather than the correct one.
His solution: make the context window dynamic by giving AI exactly what it needs to know.
The parallel project method
When starting a new project, Jovanovic doesn't build one version. He builds five simultaneously:
- A voice brain dump into the AI
- A typed-out version with more structure
- A version using reference designs from Mobbin or Dribbble
- A version using actual code snippets from component libraries
- A version combining the best elements
This approach serves two purposes. First, it clarifies the idea as you see different interpretations. Second, you can pick the right direction before investing tokens in refinement. If you start with the wrong architecture and spend days tweaking it, you've wasted hundreds of credits trying to fix fundamental problems.
Planning with MD files
Once Jovanovic picks a direction, he spends an entire day planning before building anything. He creates four core files:
Master plan: A high-level overview explaining what he's building, who it's for, and how it should feel.
Implementation plan: The order of execution - backend first, then authentication, then API integration.
Design guidelines: Specific CSS elements, colour schemes, and style references so the AI doesn't get over-creative.
User journeys: How people navigate through the app, feature by feature.
These feed into a final tasks.md file that breaks everything into specific subtasks. From that point, his prompts become simple: "Proceed with the next task." The AI reads the documentation, executes the task, and reports what it did.
He built a ChatGPT custom GPT called "Lovable PRD Generator" that creates these files automatically. You brain dump your idea, it asks clarifying questions, and outputs all four documents.
The 4x4 debugging workflow
When something breaks, Jovanovic follows a four-step sequence:
Step one: Click "try to fix" if the agent flags an error. This works for simple issues.
Step two: Add console log statements. Ask the AI to write debugging messages into relevant files so you can see exactly where the problem occurs. Copy the console output and paste it back into the chat.
Step three: Use an external tool. He exports the code to GitHub, imports it into Codex, and asks Codex to diagnose the problem. He doesn't let Codex write the fix - he takes its diagnosis back to Lovable.
Step four: Revert and retry. Go back three versions using built-in version control, take a break, and rethink the prompt. Often the problem was a vague request that led the AI down the wrong path.
After fixing any issue, he asks the AI: "How can you help me prompt you better so we solve this in one go next time?" Then he adds that guidance to the rules.md file so the AI learns from the mistake.
Why non-technical backgrounds help
Jovanovic believes not having a coding background is an advantage. Engineers know what's "supposed" to be impossible, so they don't try. When someone in Lovable's community said they wished the tool could build Chrome extensions, technical people explained why that wouldn't work. Non-technical users just prompted "build me a Chrome extension" and it worked.
The same thing happened with desktop applications and video generation. People without technical knowledge didn't know these things were impossible, so they tried anyway.
The limitation of this approach: you need self-awareness. If you don't know what you don't know, you'll build garbage quickly. Jovanovic spends 80% of his time in chat mode planning and only 20% executing. He optimises for clarity, not speed.
What matters now
Jovanovic's view: in a world where everyone can produce "good enough" with AI, the gap between good enough and world-class is shrinking. The skill that matters is judgment - knowing what to build, how it should feel, and what makes something magical rather than mediocre.
He doesn't read the code AI generates. He reads the agent output - what the AI is thinking and doing. That's where he learns what's possible and how to prompt better next time.
Design became his biggest focus after joining Lovable. He discovered that what looked like a simple gradient actually used 50 layers with different opacity levels. Good design isn't about knowing CSS syntax - it's about understanding emotion and taste.
His advice: expose yourself to great design. Follow designers, study different styles, learn terms like Bauhaus and Glassmorphism. Build an app just to learn design styles. The technical part is solved. The human part - clarity, taste, judgment is what matters.