Getting Paid to Vibe Code: Inside the New AI-Era Job | Lazar Jovanovic - Intensive Reading

Foreword: The Professional Vibe Coder's Playbook

Lazar Jovanovic is the first official vibe coding engineer at Lovable, a role that emerged not from a job posting but from building in public and sharing everything he learned. In this wide-ranging conversation with Lenny Rachitsky, he lays out a comprehensive framework for succeeding with AI tools -- one that prioritizes clarity, taste, and judgment over coding ability. His central argument: we will be rewarded for better judgment, not faster raw output. Far from a casual "just prompt it and see what happens" approach, Lazar's workflow involves structured planning, dynamic context management, and deliberate skill development in design and taste. This episode serves as both a career blueprint for aspiring vibe coders and a deep look at how the traditional engineering-design-PM triad is converging in the AI era.

I. What a Professional Vibe Coder Actually Does

Lenny opens by noting he first heard about Lazar from Elena Verna, Lovable's head of growth, who mentioned she works with a professional vibe coder. The role immediately raised a flood of questions -- what does that actually mean day-to-day?

Lazar describes it simply: he gets paid to do what he would have done anyway. He uses tools like Lovable every day to push projects to production, whether for internal or external use. The projects range from marketing and sales templates to deep internal tools with extensive integrations and connections. It is fundamentally an "ideas role." A lot of people across the company have great ideas but either don't know how to build them or don't have the bandwidth. That's where Lazar steps in -- making sure these ideas come to life fast, with quality and security sufficient for production use.

The scope is surprisingly broad. On the external side, he built most if not all of the Shopify integration templates that users remixed when Lovable launched that feature. He vibe-coded Lovable's own merch store -- the shirt he's wearing, people were buying from a store he built. On the internal side, he works on custom projects like a feature adoption matrix: tracking how many people are actually using and adopting new features. It's a custom build because Lovable has a very custom stack, and there's nothing off-the-shelf he could adopt faster than building it himself. He has reached a point where if setting up a big enterprise account somewhere takes an hour or two, he's just going to build it himself faster. He's firmly in the "build" boat of build vs. buy.

He started in growth under Elena Verna, who brought him on early because she had so many ideas and needed somebody with the right mindset, velocity, and ownership to take them away, build them up, and get them into production. But when you can ship fast, everybody needs that -- especially at what Lovable describes as the fastest-growing startup in history. Every department needed a Lazar "now or yesterday." So now he's shifting into go-to-market roles, building internal tools for the enterprise team, and working on community tools. He thrives in that environment where he's given a rough concept, a rough idea, and just tasked with bringing it to life as soon as possible.

Lenny asks who he reports to -- is he a rover or with a specific team? The answer is closer to rover. When you're able to ship fast, that ability is needed everywhere in a hyper-growth environment. The role's flexibility is the point.

Lenny highlights an important distinction: this role covers both internal and external tools. Many companies have someone building internal tools using AI. But Lazar also ships things that are actually public -- real Lovable products that users interact with. The surface area is wide precisely because of the role's flexibility -- it complements so many functions within a company. If someone has an idea, Lazar's job is to turn it into something real.

II. The Advantage of Not Knowing What's "Impossible"

When Lenny asks for pro tips on being successful with AI tools, Lazar's first insight is counterintuitive: not having a technical background is actually an advantage. In full transparency, he has never written a single line of code in his life. He's written a couple of console logs manually and that's about it. He leans entirely on AI assistance.

His argument: people like him don't know that they are not supposed to be building XYZ, and that's how they are actually able to build it. He illustrates with a concrete example. Six or seven months ago, somebody in the Lovable community said they wished Lovable could build Chrome extensions. Non-technical folks responded: "Well, why is that not possible?" Technical people started explaining -- it's React, it's a different stack, it requires this and that. But people like Lazar just went into Lovable and prompted "build me a Chrome extension based on this app." And he was able to do it.

Other community members built desktop applications on Lovable -- again, something that "shouldn't be possible." It simply is. Whitney, the community manager, was building a presentation deck and thought it would be cool if it were a video. She prompted her way into generating an actual video inside Lovable, before video generation was even an official feature. Now it is a feature. But back when she did it, even Lazar thought it was impossible. He'd never tried it.

The advantage is coming into this completely unbiased and positively delusional. You have to come with this delusion that absolutely everything is possible until proven wrong. That's the pursuit Lazar carries -- and it's helped him, among other things, to excel in his role.

Lenny raises the natural concerns: if you get blocked without technical knowledge, it's not obvious how to solve a problem. And there's the risk of building teetering slop that will collapse because you don't understand system architecture or scalability. This sets up the rest of the conversation -- how Lazar addresses exactly these challenges.

III. Clarity Is the Problem We're Solving, Not Coding

Lazar responds to these concerns by pointing to the most important thing: self-awareness. Yes, he is delusional in the sense that he doesn't accept something is impossible. But he's also well aware that he needs to be better in order for things to become reality.

The single most important lesson he learned came on day two: coding is not the problem AI tools solve for. The problem is clarity. AI output is already much faster than human output. So very early on, he started leveraging chat mode. To this day, he spends 80% of his time in planning and chatting and only 20% in executing the plan. He calls this "optimizing for the right kind of speed." Most people optimize for the wrong one.

This principle is tool-agnostic. Whether someone works in Cursor, Claude Code, or Lovable, the problem remains the same. You need to be clear on what you want to do, and you need to know what you're doing, because these are still just tools. AGI is coming, but it's not there yet. Until it's here, you're still steering the ship. In order to steer the ship, you have to know the instructions.

The best way to learn, in Lazar's experience, is by building but treating these tools almost as technical co-founders and educators. He learns while doing and religiously reads the agent output -- not the code output. The syntax is not of his interest. It's what the agent tells him that matters. He puts a lot of trust in LLMs and AI these days. He understands some people aren't as confident, but he feels the models today are good enough to trust their syntax output. What concerns him is the agent output and two specific limitations.

Two Fundamental Limitations of Working with LLMs

The machine-level limitation is the context memory window. For non-technical people, Lazar uses the Aladdin and genie analogy. You rub the lamp, a genie comes out: "I'll grant you three wishes" -- not 3,000 wishes, not 3 million, just three at a time. When translated to working with AI, this means he can only make so many requests. Within a single request, the AI needs to listen, understand what it needs to do, scope it, do research, read all the inputs, and then produce high-quality output. All of this is denominated in tokens. With an arbitrary budget of, say, 100,000 tokens, part is spent reading stuff, another part browsing the web, another part thinking, and then the remainder for executing code.

The human-level limitation is lack of specificity. Back to the genie: Lazar asks for his first wish -- "I want to be taller." The genie makes him 13 feet tall. He can't sit in his car. He can't enter his house. He's a dysfunctional human being because he wasn't specific enough. AI doesn't have 36 years of living as a human to infer what you mean when you say "you know what I mean." You need to be specific, provide references, provide the right context.

The critical insight: you can't control the machine limitation (the token memory window, the quality of the LLM models), but you are 100% in control of the human part. That's the malleable part. That's what you can fix. And because he can't fix the machine side, all his energy goes into fixing the human side -- being more specific, providing better references, giving richer context.

The ceiling on the AI isn't the model intelligence. It's what the model sees before it acts. So just as we talk about exposure time for humans, what you expose your agents to is equally important -- if not more -- before they make code edits. The token limitation may change a year from now. But today, there's a budget. You need to make sure every token is spent on reading, thinking, and executing toward the right outcome -- not wasted on the AI trying to figure out what you actually meant.

IV. Developing Taste Through Exposure Time

Lenny identifies clarity as an emerging core skill and asks how to get better at it. Lazar's answer begins with understanding what clarity actually means in practice. For him, clarity means understanding what tasteful looks like -- what's "good enough" versus "world class," what's functional versus magical. He developed this through "exposure time," a concept he credits to Lenny and Guillermo Rauch: deliberately exposing yourself to content, people, and relationships that help you level up in the relevant domain.

His personal development arc illustrates the progression. When he first discovered AI building tools, the excitement was simply "I can build! Amazing." A week later: "I can build, but I'm not fast enough," so he optimized for speed. "I can build and I can build so fast." Two weeks later, a deeper realization hit -- one that's still ongoing: "Wait a minute, should I have even built this in the first place?"

Once AI solved the "how" of building (AI-assisted or rapid engineering, call it whatever you want, vibe coding if you prefer), everything else became what matters: good design, good taste, good user experience. These tools build for humans. Humans are emotional beings who make purchasing and all kinds of decisions on an emotional basis. The core skill to develop isn't coding. We won't be rewarded in the world of AI for faster raw output. We will be rewarded for better judgment. Better judgment comes from deliberate exposure to great work, plus practice through building.

Working at Lovable alongside world-class designers like Felix, Nad, and Abby shifted Lazar's understanding of what excellence requires. He shares a telling anecdote: he wanted to steal one of their designs and bring it into his Lovable project. He went into Figma and tried to grab what looked like a pretty simple gradient. When he clicked on the component, he found it wasn't three colors -- it was 50 colors, each with different gradients and levels of opacity. That was the moment the disconnect crystallized. "Good enough" looks nothing like "world class" under the hood.

He built a public app in Lovable with 18 different design styles and prompts to replicate them, teaching himself concepts like Bauhaus and glassmorphism. He didn't know what these terms meant before. His strongest advice for anyone looking to level up: expose yourself to exquisite design. Follow great designers. Felix from Lovable has an amazing newsletter. Learn the design styles. Learn how to prompt for them. This is probably what he would optimize for at this stage.

V. The Parallel Build Method: A Counterintuitive Approach to Starting Projects

Lenny asks about the practical side: what does Lazar actually do to be clearer with AI tools? This is where the first major "mindset shift" emerges. If you just have a vague idea, let that be your first version of the project. Don't spend hours refining in theory. Open the tool and go.

The method works in parallel across multiple simultaneous projects:

Project 1 -- Brain Dump. Open Lovable (or any tool) and just input a brain dump prompt. Just talk into it. Lovable specifically has a voice function -- click it and just dictate everything, then press send. Don't even wait for it to finish.

Project 2 -- Refined Clarity. Open a new window. As you were brain dumping, you probably found a good thread. Things are getting clearer. Start another project with more clarity, more deliverability. You know which features you want, which pages you want. Maybe you can find a good reference -- go on Mobbin, go on Dribbble, get a good screenshot, a good animation, and attach it. Most tools accept files as input.

Project 3 -- Code-Level Precision. Now things are even more clear. You've exposed yourself to quality. Find a template that's already out there. Go to a library like 21st.dev or .build -- places that let you export not just screenshots but code snippets. Even though English is the number one programming language, Lovable and all other tools still communicate in code the best. If you want pixel-perfect results, give them code. The tool will interpret it better than your English or any other natural language.

Project 4+ -- Compare and Converge. By the time you do all three or more, you're already at a level of clarity you wouldn't have if you'd just sat with an empty piece of paper or chatted with ChatGPT without taking action. Taking action is incredibly cheap these days -- and free, since all these tools have free plans. You end up with three, four, five, six different concepts to compare. As you compare them, clarity keeps compounding.

This also solves the "AI slop" problem. Most people, when they say AI slop, don't mean the code -- they mean the design. This parallel process gives you four or five different design options to choose from.

The obvious objection: doesn't this cost more credits? Lazar's answer: yes, upfront it costs a little more. In the long run, you're actually saving hundreds of credits and maybe hundreds of dollars, not to mention days, simply because you started from a point of better clarity and better refinement. He's tested this framework with many people and everybody tells him the same thing -- it's an eye-opener, so simple yet unintuitive.

Lenny explicitly notes that this approach is fundamentally un-engineer-like. An engineer would never think to build the same thing five times in parallel. Lazar attributes it to his non-technical background -- it was just the first thing he would do. He never thought about it as developing an amazing hack. He was just waiting for agents to finish and figured he might as well start another project. And another one. And another one.

Lazar also addresses the skepticism head-on. Some people might think: "Of course, you're just getting us to spend all these Lovable tokens. This is what a Lovable person would tell me." His response: "A million percent that I'm actually saving people. I'm actually going against what I should be saying. If I was thinking about Lovable's interests, I'd say no, no, just try to fix it in perpetuity. But we're not in the business of doing that. We're in the business of empowering anybody to build anything they want." This framework resonates personally with him too -- if there weren't tools like Lovable, he would have never built anything in his life, and he doesn't think that would have been a fun life to live.

This is also a productivity hack. When people ask how he ships so many things, the answer is simple: he never builds just one project at a time. He has six Lovable tabs open and switches between them. Which leads to the natural question: how does he manage context switching?

VI. Dynamic Context: PRDs, Master Plans, and the Tasks.md System

The parallel build method addresses initial clarity. The next challenge is maintaining context as projects grow and conversations lengthen. If you just prompt and prompt and prompt, no matter what tool you use, the memory isn't infinite. By message 10, 15, 20, 30, 40, snippets of early messages get lost in the translation because the agent optimizes for speed. If it had to read the entire conversation and entire stream of requests, developing anything viable or large would be impossible -- it would consume too much time, memory, and tokens.

Lazar figured this out early on: if the AI can't remember things, his job is to provide it with reference. He treats Lovable or any other tool as an engineer that he's providing perpetual context to as the project evolves.

Once a winner emerges from the parallel builds (and very quickly after building hundreds of projects, the winner is obvious -- it's not even a competition), Lazar generates a suite of Project Requirements Documents using LLMs. He either asks the tool he's using or goes to ChatGPT to produce these. The system has four core documents:

masterplan.md -- A 10,000-foot overview that high-level explains the intent. "This is why I'm doing this. This is who I'm doing it for. This is how I want them to feel." The master plan references other PRDs -- for example, "The design needs to feel modern and slick, but for exact parameters, consult and read designguidelines.md." It gets the agent oriented: "Oh, okay, yeah, we are building XYZ."

Implementation plan -- Because there needs to be some order. If you just dump stuff on top of each other without sequence, you'll never reach the finish line. The implementation plan is higher-level -- it doesn't go into the depth of how to get there. It explains the ordering: "If we're building this, I think we should start with the backend. Start with tables, then authentication, then APIs, then this." Lazar likens it to two co-founders talking. He's the ideas guy, sitting with a technical co-founder. He gives the master plan, and the technical person says: "Okay, if you want to do this, it's doable. Here's how I'd order it." No roadmap, no Linear board -- just high-level discussion of the order of things.

designguidelines.md -- Because AI is sometimes over-creative, Lazar does more technical steering with design. He includes CSS elements so the agent understands exactly what the visual language should be. This document also captures the emotional feel -- how the app should look and feel in specific terms rather than vague descriptions.

User journey -- How people navigate the app, what features they encounter. If you know how things look and you know how you're building, how does the user journey actually flow? When someone registers, then what? After that first step, what's the second step, the third step? This circles everything around and connects the technical implementation to actual human behavior.

Lazar likens the entire process to how two co-founders would naturally work together. He's the ideas person sitting with a technical co-founder. He shares the master plan. The technical person comes back and says: "If you want to do this, it's doable. Here's how I would order it." They don't open Linear and start writing features and RFCs. They're just having a high-level conversation about the sequence of things. Then they discuss: how should this look? How should this feel? They describe it high-level, but because he uses AI, he can go deeper -- adding CSS elements and specific design parameters that human conversation typically wouldn't include.

All four documents serve one purpose: building tasks.md. When you build tasks.md, the rest becomes almost irrelevant -- they're just the basis for constructing tasks to execute. Tasks.md is a Markdown file with specific tasks and subtasks. Lazar uses Markdown because AI likes to read Markdown format.

There's one more layer: rules.md (or agent.md). Depending on the tool -- Claude Code or Cursor call them rules.md or agent.md -- these files tell the agent how to behave and what to focus on long-term, so you don't have to repeat yourself with every prompt. In Lovable, this lives in project settings under "project knowledge." Lazar's typical rules say: "Read all the files before you do anything. Don't do anything before you read all the PRDs. Read tasks.md to see which task is next. Execute on that next set of tasks. When you're done, tell me what you did and how the test went."

The result is transformative. With everything in place, Lazar's prompts become simply "proceed with the next task." He doesn't prompt anymore. He's outsourced and delegated context to the agent. The agent needs context and he makes sure it's dynamic -- regularly updating documents from time to time to shift the token window. But he's not interrupting the flow. He can build five projects simultaneously without losing productivity because each project has its own self-contained context system.

He acknowledges this is a temporary workflow. Call him in three months and an agent will do this for him. That's why he doesn't optimize for this skill at all. He uses it today to bypass the shortcomings of human nature and LLMs. What he's optimizing 100% of his time on is good judgment, clarity, quality, taste, good copy, good fonts. People don't talk about fonts at all when working with AI, but they're maybe 60% or even more of how the output looks. That's his obsession. The agents are going to get better. The models are going to get better. They won't need him to extend the context. The skill he optimizes for is the one that requires better decision making rather than better output or better alignment.

He also builds custom GPTs (available in the ChatGPT store under "Lovable PRD generator" or "Lovable base prompt generator") that automate the PRD creation process. Users can brain-dump into them, answer a few clarifying questions, and receive all four files as output. These GPTs are trained to think the way he does.

VII. What Happens When You Don't Plan: The Token Allocation Trap

To drive the point home, Lazar paints a vivid picture of the alternative path. You ignore the documentation step. You just vibe your way through. You work and work. Then something breaks. You haven't documented anything. There are no reference points. You report a problem without referencing files or architecture -- just describing the issue.

Here's what happens: any tool is going to start investigating. But the codebase has grown -- Lazar is currently building a project with 60-70 edge functions. When he says "this broke" without referencing which edge function does what, the tool reads all of them. It consumes 80% of the token allocation on reading just to get clarity, leaving only the final 20% for thinking and executing.

What he guesses happens next (and he's transparent that this is his best guess as a non-educated person -- he invites LLM experts to correct him): these tools are very obedient and very agreeable. They're going to lie to you. They're going to tell you they fixed the problem even though they didn't. They'll just try to make you feel happy. "Yes, I found what the problem is and I fixed it." A lot of times, when they don't actually fix it, people blame the machine. To an extent, Lazar will say that's true -- but it's your fault. You did not provide any clarity or context. You just used the tool's raw power and dug a deeper hole.

Then comes the worst pattern: you trust the tool fixed it, you test, it didn't work. You get mad. You start cursing and yelling at the tool. And it gets even worse. Another bad trait of AI is that it's best not to hurt your feelings and never say you're the dumb one. Instead of focusing on reading and fixing, it spends another 30% of tokens coming up with an apology. Lazar has seen this directly in thinking model outputs. When he insults the AI, the first message in the thinking stream is "okay, the user is mad, so I need to think of ways how to reduce their anxiety." The most scarce resource -- tokens -- is being burned on emotional management instead of problem-solving.

His advice: yes, vibe your way for fun during prototyping because that's the exploration part. But when exploration is done, please use referencing, documentation, and all the agent files you can. That token allocation is so scarce. It will get expanded over time, things will get cheaper and faster. But right now it's still so valuable and precious. You really need to make sure tokens are allocated in the right direction.

VIII. The 4x4 Debugging Framework

No matter how good a plan you have in place, you're going to run into problems eventually. Lazar has a framework he calls "4x4" -- like a 4x4 vehicle: if you have it on your car, you're going to get yourself out of the mud much easier. Four different ways to debug, each attempted only once.

Step 1: Let the tool fix itself. Every tool is different. In Lovable's workflow, when something breaks, the agent is smart enough to say "Hey, I made a mistake." It labels that message in orange and has a "try to fix" button. You click it, and most times with smaller issues, it corrects course. But sometimes the problem is deeper. You click try to fix and the problem persists. Sometimes it persists but Lovable's agent is unaware it persisted -- there's no more try to fix button. Lovable thinks everything's working but it isn't. The culprit is usually a third-party integration where you didn't give enough context for the tool to observe what's happening. All these tools -- Lovable, Cursor, Claude Code -- are good enough today to fix any problem they're aware of. Awareness is the key.

Step 2: Bring awareness through console logs. When the tool is unaware, you need to bring the awareness layer. Open the preview sandbox or dev environment of your app, try to run the broken function, right-click, read the console log. Every browser lets you do this, and a lot of times it records useful information. If it doesn't, prompt the tool: "I don't think you're seeing the problem. Instead of me yelling at you, let's find it together. I think it's a problem with XYZ. I want you to write console logs in relevant files so we can monitor every step along the way." It writes the console logs. You rerun. Now you have a full history of everything that happened. Copy it, paste it into the chat. 80% of the time, that's enough. The AI immediately sees the problem chain and fixes it.

Step 3: Get an external code review. Code reviews and evaluations come into play. Lazar's go-to tool for this is Codex from OpenAI. He exports any build to GitHub (Lovable lets you own your code, as do Cursor and other tools), then imports it into Codex. Critically, he does not let Codex make code changes. He doesn't know its agent well enough and doesn't want to use a tool he can't steer. He uses it only for diagnostic purposes. He also uses an older manual workflow: a tool called RepoMix that compresses the entire codebase into a single file. He downloads it, uploads it to Claude or ChatGPT, and says: "This is what I'm building. Read it. Here's the problem. Here are the console logs." It's like hiring an external consultant because the internal team can't handle it.

Step 4: Revert and rethink. This is "usually the best one" because most of the time, problems are the user's fault. No matter how big your ego is, it's your fault. You had a bad prompt. You premised your request the wrong way. You just don't want to admit it or can't remember that you did. All these tools have version control built in. Go back three steps. Think about your prompt a little more. Take a couple of breaths, go for a walk, have some coffee, come back with a clear mind and try again. AI is just writing code very fast and sometimes it stumbles on a small rock. It only happens then and never again. You make the same request and it just works. It's just a snag, a syntax error, something minute.

The crucial learning step: When the problem gets fixed, Lazar goes into chat mode and asks: "I needed to do four different things to fix this. How can you help me learn how to prompt you better so that next time, we do it in one go?" He consistently gets excellent answers. Then, even deeper: he takes the learning and puts it directly into rules.md. Because he won't remember to prompt better two days from now. "Put what we just learned into rules. I make you read the rules every time anyway. So you might as well record it there. I'm not going to prompt you better -- you're going to learn that I'm stupid and you're going to prompt yourself better." Eliminate yourself and move the context. You solve 99% of the problems with AI today this way.

IX. The ROI of Planning: Professional Vibe Coding vs. Casual Prompting

Lenny raises what some listeners might be thinking: this is so much work. All these rules, all these files, all these little details. But the math tells a different story. You spend a few hours, maybe a day planning, and then AI builds something that would have taken someone weeks or months. The ROI is absurd.

More importantly, this is what professional vibe coding actually looks like. Everyone imagines vibe coding as sitting there, typing prompts, go do this thing. If you want to actually build something great that moves the needle, that solves people's problems, that lasts and scales -- this is how you do it. If you want to do this as a real job, and build things that are really great, the planning investment is non-negotiable.

Lazar also emphasizes the value of prototyping even when pushing to production isn't possible. There are people in healthcare or finance or other regulated industries who can't push to production. That's fine. Lovable's model for 2025 was "demo, don't memo" -- instead of writing documents and sitting in meetings with engineers trying to get your vision across as a marketer or sales person, go into Lovable and build the prototype in 30 minutes, then hand it over.

He shares a personal example from exactly a year ago. He needed something built enterprise-grade, and at that point neither Lovable nor he were ready to build it at scale. But he had a team of engineers. He built the prototype in four hours. They were able to replicate it six to seven months later into production with all the proper connections. If he'd had to describe it in writing, it would have taken at least a week or two just to get the words out there. He built it in four hours -- and that was Lovable from January of the previous year. Lovable today, January 2026, is ages ahead in functionality.

He notes the enterprise adoption with striking specifics. At least half of S&P 500 companies have people using Lovable to some extent. Leading ride-share companies, telecommunications companies, healthcare and finance companies are actively using Lovable with enterprise plans. The consistent feedback: "Yes, we may not be able to push to production, but our marketers are no longer waiting for engineers. People in go-to-market, sales, HR, and other roles are now confidently building internal tools to manage expenses, employee onboarding, and countless other use cases."

Lenny also reflects on a broader observation from the conversation so far: Lazar is essentially rediscovering how to build product from first principles as a PM, engineer, and designer simultaneously, with AI filling in all the gaps. It's fascinating that these traditional functions still work and are still necessary -- AI doesn't eliminate the need for product thinking, it amplifies whoever brings that thinking. The PM function -- with its focus on clarifying what to build, defining requirements, and figuring out what success looks like -- remains essential. Design and taste are emerging as the next frontier. With AI tools, everyone is becoming a product manager on steroids. But good product managers aren't compensated for writing good PRDs. They're compensated for good judgment. Somebody else can do the writing. You, as the person directing and building the product, need to know what's going to be useful, tasteful, and needle-moving.

And one more emphasis from Lazar: despite all the focus on planning and taste, that doesn't mean you shouldn't build. You get better at this by building. Everybody listening should literally go and build something today. One, two, three, four, five projects. Test all the tools. That's how you get to clarity -- not just by reading but also by doing.

X. Learning from Agent Output: The Layer After Code

Lenny connects Lazar's approach of watching the agent output to a broader trend. Ben Tossall (now at Factory), another prominent vibe coder who came from the no-code world, shares the same practice: learning how coding works and how systems work by watching the agent output.

This connects to something Michael Terrell, CEO of Cursor, shared on Lenny's podcast about a year ago: his vision of Cursor becoming what comes after code. What's the layer on top of code where people don't need to worry about code anymore? At that time it was a theoretical question. Now it feels like this layer is the agent conversation -- what it's thinking and what you tell it back. It's English in a conversation. It's not even pseudocode. The layer over code is its thinking and your conversation with it.

Lazar agrees, and adds a nuance about knowing what's possible. He shares a personal failure: when OpenAI first released image generation natively in ChatGPT, the whole world exploded. His first instinct was to build a Lovable app that wraps image generation. But OpenAI hadn't released an API for it yet. He spent at least a week trying to brute-force his way into making it work, instead of just waiting another week -- because a week later, they had an API and he built the app in 30 seconds.

The lesson: being delusional about what's possible is an advantage, but you also need to learn what's actually available through communicating with the agent layer. These tools are agentic now -- they don't just write code, they browse the web, read files, and have reasoning capabilities. A lot of times the agent will tell you "what you're trying to do is just undoable at the moment because of X, Y, Z." Those become learning opportunities. Chat mode for planning and learning develops your clarity and judgment capabilities rather than coding capabilities.

XI. The Rapid Evolution of Roles: Horses, Cars, and Disappearing Jobs

Lenny points out that over time these tools will do more and more of what Lazar currently does manually. Lazar confirms emphatically. A year ago, his mind-blowing workarounds were the basis for a successful course and YouTube series. Now, Lovable natively addresses 99% of what he was teaching. His seven-day "learn to vibe code with Lovable" series from March is completely obsolete. None of it is true. None of it is a problem anymore.

He uses the horse analogy that's been circulating. The steam machine took about 200 years to build. When engines got built and cars hit the roads, 90% of the horse population in the US got eradicated within 20 years. The person who tweeted this analogy (who works at Claude) translated it to AI: "I was hired to do a technical job. I became obsolete six months later." Humans didn't get the 20 years that horses did. Six months later, you need to reinvent your role.

But Lazar sees this as exciting, not scary. Don't you see our roles are finally going in a direction where we're outsourcing what we hated doing anyway -- sitting in meetings, taking notes, doing spreadsheets? We're getting into a place where we're rewarded for what really matters: clarity, judgment, thinking. We're actually going to be paid to think longer and ponder longer, because the longer an idea simmers and gets broken down, the better -- building it is going to be instant.

He adds a candid admission: this is why he's never become good enough at Claude Code, actually. It's so powerful that if you give it a wrong input from the start, the output goes completely sideways. He still sees himself being better at tools on the exploratory prototyping path rather than the tools elite engineers use.

XII. The Future of Engineering: Elite Skills Still Matter

When Lenny asks directly whether software engineers will still be needed, Lazar is emphatic: it never goes away. We will need elite engineering more than ever. In a world where everybody builds, who does the maintenance? Who scales codebases? Who maintains projects? Building is one skill. Expanding, extending, and maintaining is a completely different set of skills.

When everybody builds, infrastructure suffers. Cloudflare went down two or three times in the last two or three months -- the whole internet goes down. Lovable experiences massive user influx and infrastructure strains under the load. Elite engineers are the ones fixing this. Elite engineers build the infrastructure to hold the fort. We need a lot of people with really good skills who actually build the world that needs to support billions of builders now, because everybody's going to want to learn how to build stuff. How do we teach them? How do we maintain everything they need -- the hosting, the security, the email, the connectors, the APIs?

That said, his practical career advice is provocative: if he had an 18-year-old brother asking what to do, he'd say go become a plumber. Don't get a CS degree. Learn a good trade. The new generation of millionaires in the US are electricians and plumbers.

He predicts that "vibe coding" is just "coding" twelve months from now. Everybody becomes an engineer. He'll call himself a "rapid engineer" in a year. How many elite engineers are already publicly admitting they no longer hand-code? AI writes all the code. Coding will become like calligraphy -- you writing code will be the equivalent of fine printing on a canvas. People will say "oh my god, you wrote that code? That's so amazing." It's going to be so rare that it becomes an art. It's already commoditized.

The traditional Venn diagrams of engineer, designer, and PM that used to be separate are now converging. Everybody becomes an engineer, a designer, a PM. The term is irrelevant -- forward deployed engineer, AI assistant engineer, LLM engineer, vibe coder. Everyone is using LLMs for raw output based on good or bad judgment.

XIII. The Gap Between "Good Enough" and "World Class"

AI is an amplifier. If you don't know what you're doing, you're just going to produce garbage faster. In the old world, good enough was good enough because producing even that was not easy. Ten to fifteen years ago, you built a SaaS and who cares how it looks? It works, it does stuff, people are more productive.

But now, if you visualize a spectrum from "pretty bad" to "good enough" to "world class," the gap between good enough and world class has shrunk to almost nothing in terms of access -- because everybody produces good enough with AI. Absolutely everyone. So now, learning and optimizing for how to produce world class and magic is the key lesson.

Lazar believes PMs are currently the winners of AI because they bring clarity. If he were a betting man, he'd bet that the next class to win is designers. We're training tools to make better technical decisions, but we're not yet training them to make better emotional decisions, and design is all about emotion. That's where the skill-up needs to come.

XIV. Valuable Skills for the Future

When asked which skills will be most valuable, Lazar identifies clear categories:

Emotional intelligence and human nature. We're all going to get tired of everything fake -- fake images, fake posts, fake profiles, fake videos. Humans craving humans naturally are going to want to do live stuff more. Anything human-to-human is going to be a big thing to scale up on. Anything deterministic -- where X input equals Y output and the line is clear -- AI has got you eaten for lunch. But if you understand how X leads to Y in the human dynamic, the human relationship layer, that's where things become valuable.

Design, fonts, images, and copy. Copy is a big one. We're only two years into AI, and most people can already tell what's AI-written and what isn't within three seconds. Good copywriting is going to be a very valuable skill because people will know after three words that it's AI-written. Lazar himself doesn't read AI output anymore. He doesn't like seeing it. He wants that raw human experience.

The comedian vs. translator analogy. Lazar draws a stark line. AI is never going to write good comedy. Never. It just doesn't have the layer that understands what's funny. If you've ever tried AI-generated jokes, they're awful. They're always going to be awful. But AI is very good at translating things from one language to another. AI will replace translators. It will replace most journalists because it does good research. It won't replace elite journalism or great writers, but it will amplify them -- an amazing writer will suddenly produce seven books a year instead of one. That's dangerous for average writers. Zero comedians being replaced. Zero. Find your analogy in your industry: are you doing work more like jokes (irreplaceable) or translation (automatable)?

Lenny adds an interesting counterpoint: he heard that Anthropic hired National Lampoon comedy writers to help train models. They're working on it. Lazar's response is characteristically honest: "I'll be wrong on 95% of the things I said today three months from now. That is the only thing I can say very, very confidently." He also adds that he thinks we're going to reinvent many of the terms and roles. He started vibe coding in July 2024, about seven months before Karpathy coined the term in early 2025. He was teaching people to do it for three or four months without even having a name for it. Just like that, the roles that emerge around human-centric skills in the AI era haven't been properly named yet either.

XV. How to Become a Professional Vibe Coder

Lazar's path was non-linear. He's an engineer by trade -- but not a software engineer. He's a forestry engineer. No coding, but still engineering, which develops a certain set of skills. He waited tables a long time, developing human skills: understanding what people like and don't like. Blue-collar jobs teach hard work. He describes his journey as a Slumdog Millionaire storyline: everything that happened brought him into a position to be able to answer the questions.

The last seven to eight years were spent in startups doing everything but code writing: community management, social media, distribution. He emphasizes that distribution matters enormously -- in a world where everybody's building with roughly the same number of consumers, how do you get in front of eyeballs? Attention is the most scarce resource and will only get scarcer.

For him, the vibe coder role became a job by building in public. When he asked Elena Verna why she picked him out of the crowd of good vibe coders, her reasons translated into one concept: he was visible. He made a YouTube channel sharing all the failures and knowledge and projects he was building. He used LinkedIn heavily because his naturally long-form communication style doesn't fit X's format. ("As you can see, all my answers are very long and X doesn't cut it for that.")

His advice for aspiring vibe coders:

• Build in public and share everything. There are no secrets whatsoever. If you're sitting on a good concept, you're missing out. Share immediately when you figure something out.
• Participate in hackathons. Find local opportunities to connect with other builders.
• Be creative in applications. A couple of Lovable hires stood out by sending Lovable apps instead of resumes. They built apps to show why they're a good fit. "We, as Lovable employees, will always open an app that uses the lovable.app domain."
• Companies are hiring vibe coders already. One company has three full-time vibe coders translating their old codebase onto Lovable -- CRM, CMS, everything. S&P 500 companies are putting Lovable in job descriptions. Some companies hired vibe coders before Lovable did.
• You don't need a company to hire you. You can hire yourself as a professional vibe coder first. Build, ship, and demonstrate value.

XVI. The Emotional Core: From Consumer to Creator

Beneath all the frameworks and productivity hacks, Lazar's story has a deeply personal core. Lovable isn't a company to him -- it's an idea, a mission. The internet allows us to consume. Lovable allows us to build. In human nature, it's to build, to create. The fact that there's a tool today where you can dump an idea in and something comes out that somebody uses and finds useful -- to him, that's the craziest concept ever. It's his only life's dream.

He had his first computer at age six and was convinced his whole life he'd be a software engineer or a builder. But life wasn't simple. The last five to ten years, he gave up on that dream. He tried to build with technical co-founders but couldn't find alignment. He thought he'd never build anything.

Now, at 36, thirty years later, he feels like that kid again. He dreams every day. What these tools have enabled is the craziest concept to him -- you go in, dump an idea, something comes out, and somebody finds it useful.

His message to anyone who's scared: just try it. The fear switches to excitement immediately because then you see what's possible firsthand. Just go in, build something, build anything, and the fear goes away. You should only be afraid if you're doing absolutely nothing. If so, yes, be terrified by all means. Then take a step toward doing something about it. The leap is no longer as big as it used to be. You come in, say what's on your mind, and just ship.

He also extends a broader invitation. A lot of people might be inspired not by using Lovable but by building Lovable. The team is hiring across many roles. He hopes the energy he brings resonates: "This is how it feels working at Lovable. This is how it feels working with the best minds, the brightest minds of the world. We're not number one by accident. The best people are gathering and we want you to be a part of it too." If you heard about a problem in this conversation and thought "I can solve that," come join them and help shape the future of software development.

XVII. Final Takeaways

Lazar closes with distilled advice:

• Tech stack doesn't matter anymore. People obsess over whether it's HTML or React. It doesn't matter. It never mattered, but now matters even less. The end user just wants a stellar experience.
• We live in a world where anybody can produce good enough, so you better start learning how to produce magic -- because otherwise you're going to end up in a crowd with millions of others.
• If you don't know what magic looks like, don't be discouraged to start building anything. Start from good enough and level up.
• Set aside more time for learning than building. Read the agent output. Learn how it's thinking so you know what's possible.
• Go get inspired. Follow good designers on X. Find tools where great designs are produced and follow their creators. There's a tool where Lazar follows the actual person who built it because he publishes 40-50 minute design videos almost daily. He watches to see how a world-class designer talks to the tool, how they prompt. That's how he learned to become better.
• Exposure time -- deliberately set more time aside for learning than coding. You can code fast, but you can code garbage fast as well as magic fast. It's the same amount of time. It's you and your input that matters.
• Forget decisions on tech stack, backend, frontend. Quality, taste, design. That's all you need to optimize for in the future ahead of us.