LLenny's Podcast
← All frameworks
InnovationLazar Jovanovic (Professional Vibe Coder)

Parallel Draft Divergence

Start one idea 4-5 times in parallel, each with more precision, then pick the obvious winner.

Difficulty
Easy
Time to result
~days to results
Steps
5
Confidence
90%

Instead of refining a single build until it's right, spin up multiple parallel builds of the same idea, each seeded with progressively more precise input. Comparing the divergent outputs manufactures clarity faster than staring at a blank prompt, and lets you pick the best design and architecture before you commit tokens to fine-tuning. Because agent runs are slow, you work across tabs while each one builds.

Origin

Developed by Lazar Jovanovic, professional vibe coder at Lovable, who attributes the instinct to his non-technical background — he didn't know you were 'supposed' to build one thing at a time.

Core principles

  • 01Taking action is nearly free — most AI build tools have free tiers, so exploring five concepts costs almost nothing.
  • 02Clarity is discovered by comparing options, not by thinking harder in the abstract.
  • 03Each parallel build should escalate in specificity: vague voice dump → typed features → visual reference → literal code snippet.
  • 04Code communicates intent to the tool more precisely than prose: 'even though English is the number one programming language, Lovable and all other tools still communicate in code the best.'
  • 05Picking the right direction early saves more credits than it spends, because you avoid fighting a wrong first design in perpetuity.

How to run it

  1. 1

    Brain-dump the vague idea

    Open the tool, use voice dictation, and talk out the raw concept. Don't even wait for it to finish generating — the point is to externalize the fuzzy version.

    Pro tip Use the built-in voice function or a tool like Whisper Flow so you can dump the idea faster than you can type it.

  2. 2

    Start a second build with a refined prompt

    Once brain-dumping surfaces a good thread, open a new project and type a clearer prompt naming the specific features and pages you now know you want.

  3. 3

    Start a third build seeded with a visual reference

    Find a strong design reference (he uses Mobin and Dribbble), screenshot it, and attach it as input so the tool builds against real quality rather than a vague description.

  4. 4

    Start a fourth build seeded with actual code

    Pull a code snippet from a component library (21st.dev, build libraries) and hand the tool the literal code for the design and functionality you want, for pixel-perfect interpretation.

    Pro tip Export code snippets, not just screenshots — the tool interprets code far more faithfully than a natural-language description of a design.

  5. 5

    Compare the divergent outputs and pick the winner

    With four to five concepts side by side, the best one is usually obvious. Run one or two calibration prompts on it, then lock that direction before doing any deep work.

    Pro tip Work across tabs while builds run — this doubles as a productivity hack that lets you ship many projects at once.

    Watch out Don't get sentimental about your first attempt; the whole point is to avoid locking into an early design and architecture you'll pay to unwind later.

In the wild

Shipping many projects at once

Lazar describes running six Lovable tabs simultaneously and switching between them, treating the slow agent build time as an opportunity to advance several projects rather than idle.

He credits this parallel workflow for how he ships so many public and internal products at Lovable without losing productivity.

Common mistakes

Treating upfront parallel builds as wasted spend

People obsess that starting multiple projects costs more credits. Lazar argues the opposite: the upfront cost is small, and starting from higher clarity saves hundreds of credits and days you'd otherwise burn fighting a wrong first design.

Sitting with a blank page instead of building

Trying to reach clarity by only thinking or chatting with a model without producing anything leaves you less clear than someone who has five concrete concepts to compare. Clarity comes from doing, not just reading.

Is it for you?

Best for

Non-technical builders and PMs starting a new product in an AI build tool who don't yet know exactly what they want or what 'good' looks like.

Not ideal for

Tightly scoped, already-specified changes to a mature codebase where the direction is settled and parallel exploration just adds noise.

From the transcript

I never built just one project at a time. I built five or six. I have six lovable tabs and I just switch between them.

29:30

even though English is the number one programming language, Lovable and all other tools still communicate in code the best.

as you're comparing them, clarity just keeps coming

25:00

From the episode

The rise of the professional vibe coder (a new AI-era job)

Lazar Jovanovic (Professional Vibe Coder)