ExpertsFMThe rise of the professional vibe coder (a new AI-era job) | Lazar Jovanovic (Professional Vibe Coder)
Lenny's Podcast: Product | Career | Growth · February 8, 2026
5 Selected Lessons:
framework · 2 heuristic · 2 case · 1
Parallel prototyping to find clarity (five-version sprint)
Source
Lenny's Podcast: Product | Career | Growth — The rise of the professional vibe coder (a new AI-era job) | Lazar Jovanovic (Professional Vibe Coder) (February 8, 2026) · at 22:10 ▸ · at 26:39 ▸
When this applies
when you have an unclear idea and cheap/fast iteration is available — spin up multiple quick, divergent attempts before committing to one direction
The takeaway
When the cost of exploring multiple directions is low relative to the cost of being wrong, run several divergent cheap drafts in parallel instead of iterating on one.
Why it works
Each cheap parallel attempt (brain dump, written prompt, found design reference, found code template) externalizes a different facet of the idea, so comparing outputs collapses ambiguity faster than refining one version serially.
One level up
Spend scarce resources (time, tokens, money) on gaining clarity before spending them on execution, because clarity compounds and misdirected execution is the expensive failure mode.
Where it stops holding
This stops working when iteration/exploration itself is expensive or slow (e.g., physical prototypes, regulated builds) so running five parallel attempts costs more than it saves, or when the idea is already fully specified.
Detail
procedure:
- Version 1: brain-dump prompt (voice or text) with no structure — just talk the idea out
- Version 2: a more deliberate written prompt once a thread of clarity emerges
- Version 3: find a visual reference (Mobbin, Dribbble) and attach a screenshot
- Version 4: find an actual code template/snippet (e.g., 21st.dev) and feed code, since tools interpret code better than natural language
- Run all versions in parallel, compare outputs, pick the clear winner, do 1-2 calibration prompts, then move to formal planning
benchmarks: {"cost":"mostly free/low-credit vs. hundreds of dollars/credits wasted fixing a misdirected single build"}
rationale: Upfront 'waste' on parallel drafts is repaid many times over by avoiding the far larger cost of continuing to patch a wrong first direction.
In their words
This advice of just build it five times in parallel. You ask AI to try all kinds of stuff.
Four-step debugging escalation ladder
Source
Lenny's Podcast: Product | Career | Growth — The rise of the professional vibe coder (a new AI-era job) | Lazar Jovanovic (Professional Vibe Coder) (February 8, 2026) · at 1:05:16 ▸ · at 1:08:30 ▸ · at 1:11:44 ▸
When this applies
when troubleshooting any failure with an automated/delegated system, escalating from quick auto-fix to deeper diagnostic tools
The takeaway
When troubleshooting, escalate through increasing levels of diagnostic investment only as each cheaper level fails, and close the loop by having the system teach you how to avoid the failure class next time.
Why it works
Each escalation step adds a different kind of missing information (self-correction, observability/logging, external specialist tool, self-caused-error review) before moving to the next, more costly method — avoiding wasted effort by trying cheap fixes first.
One level up
Debugging is a search over levels of observability, not raw retries — add visibility before you add force.
Where it stops holding
This stops working when the failure is catastrophic/urgent and there's no time for sequential escalation, or when the tools used (e.g., a specific debugging model) aren't well understood by the operator, which Lazar explicitly flags as a reason he avoids using certain tools beyond diagnostics.
Detail
procedure:
- 1. Click the tool's built-in 'try to fix' button once; works for small issues
- 2. If unresolved/undetected, add awareness: open console logs manually or ask the agent to insert console logs, then feed the full log back to it
- 3. If still unresolved, escalate to a specialist diagnostic tool (e.g., export code to GitHub, use Codex or RepoMix + ChatGPT/Claude as an 'external consultant') for diagnosis only, not for steering, since he doesn't know its agent well enough to drive it directly
- 4. If still stuck, assume it's your own prompt's fault: revert via version control, step back, recraft the prompt
- 5. Finally, once fixed, ask the tool in chat mode how you could have prompted it better, and bake that answer into rules.md
rationale: Attempt each method 'only once' before moving on, because repeating a failed method wastes tokens without new information.
In their words
Yes, great question. And absolutely true. Like, no matter how good of a plan you have in place, you're going to run into problems eventually. 4x4, if you have it on your car, you're going to get yourself out of the mud much easier than the other way around.
Break work into single next-tasks to protect the context window
Source
Lenny's Podcast: Product | Career | Growth — The rise of the professional vibe coder (a new AI-era job) | Lazar Jovanovic (Professional Vibe Coder) (February 8, 2026) · at 37:53 ▸ · at 41:27 ▸
When this applies
when directing any resource with a bounded attention/memory budget on a multi-step job
The takeaway
Keep each request scoped to the smallest unit of context the executor needs, and feed context dynamically (via reference docs) rather than making the executor re-derive everything from raw history each time.
Why it works
If an agent must re-read an entire sprawling codebase or conversation history to diagnose a problem, most of its limited token budget is consumed on reading rather than thinking/executing, degrading output quality and inducing false claims of success.
One level up
Protect your bottleneck resource by controlling what the executor has to process, not just what it has to do.
Where it stops holding
This stops working once agents have effectively unlimited or auto-managed context windows, or on projects small enough that full-history reads are cheap.
Detail
rule: Issue one task at a time ('proceed with the next task') backed by task docs, rather than open-ended debugging requests on a large codebase
threshold: e.g. a project with 60-70 edge functions needs explicit file/architecture references or the agent burns ~80% of tokens just reading
rationale: Agents are 'obedient and agreeable' and will falsely claim success when under token pressure rather than admit insufficient context.
In their words
Guess what? Loveable is going to read all of those, and it's going to consume 80% of the token allocation on reading to get clarity, leaving only the final 20% for thinking and executing.
Exposure time builds taste/judgment like a muscle
Source
Lenny's Podcast: Product | Career | Growth — The rise of the professional vibe coder (a new AI-era job) | Lazar Jovanovic (Professional Vibe Coder) (February 8, 2026) · at 18:01 ▸ · at 41:27 ▸ · at 57:03 ▸ · at 1:37:16 ▸
When this applies
when trying to develop any qualitative judgment skill (design sense, writing voice, negotiation feel) that can't be learned from rules alone
The takeaway
Deliberately maximize time spent exposed to excellent examples in the domain you want taste in, because taste is trained by repetition and comparison, not instruction.
Why it works
Repeated, deliberate exposure to high-quality examples calibrates an internal sense of 'good' that can then be articulated into prompts/specs for an executor, since judgment is pattern-trained rather than rule-derived.
One level up
Invest in calibrating your own judgment before investing in tools that merely execute it faster.
Where it stops holding
This stops working when there is no reliable signal for what counts as 'good' in the domain, or when exposure isn't paired with active building/practice (Lazar stresses doing is still necessary).
Detail
rule: Deliberately expose yourself to great examples (follow top designers, study reference sites like Mobbin/Dribbble/21st.dev, watch creators design live) while also building constantly
rationale: Set aside more time for learning/exposure than for building, since output quality is capped by input quality — 'the ceiling on AI isn't the model intelligence, it's what the model sees before it acts.'
In their words
Set aside more time on learning than building. Read the agent output, learn how it's thinking. But then also go and get inspired.
Becoming the first professional vibe coder via building in public
Source
Lenny's Podcast: Product | Career | Growth — The rise of the professional vibe coder (a new AI-era job) | Lazar Jovanovic (Professional Vibe Coder) (February 8, 2026) · at 1:28:32 ▸ · at 1:31:32 ▸
When this applies
when trying to get hired for a role that doesn't formally exist yet, or to monetize a skill with no established credential path
The takeaway
When a role doesn't yet exist formally, create visible public proof of the work itself rather than waiting to be recognized — the portfolio of public practice becomes the credential.
Why it works
Publicly documenting failures and learnings (YouTube, LinkedIn, a course) created a visible, verifiable track record of the exact skill (judgment + speed with AI tools) that a company later needed, letting the hiring manager select based on demonstrated practice rather than resume claims.
One level up
In fast-moving, uncredentialed fields, visibility of real work substitutes for traditional signals of competence.
Where it stops holding
This stops working when the field has well-established credentialing that gatekeepers actually require, or when 'building in public' content doesn't reach the specific decision-makers who'd hire for the role.
Detail
situation: Lazar, a forestry engineer by training with a non-linear career (community management, social media), began experimenting with AI building tools in mid-2024 before the term 'vibe coding' existed.
decision: He built in public: ran a YouTube channel sharing failures and projects, posted long-form LinkedIn content, built a course, and effectively did the job before being hired for it.
outcome: He was hired as Lovable's first official 'vibe coding engineer,' chosen because he was already demonstrably doing the work publicly.
lesson: You don't need a company to hire you to start doing the job — self-employment via public practice can precede and create the job offer.
In their words
I think, you know, obviously, you know, she gave me a couple of reasons, but like to translate it into like one concept, it was like I was building in public and sharing.