The Professional Vibe Coder: How Lazar Jovanovic Ships Production Software With AI and No Coding Background
Lenny's Podcast
Lazar Jovanovic's job title is one that did not exist until recently. He says he is the first official vibe coding engineer at Lovable. He is paid full-time to build internal tools and customer-facing products with AI, and he says he has never written code beyond "a couple console logs." In this conversation with Lenny Rachitsky, he explains what the role involves, the workflows he uses to ship production-quality software, and why he thinks the skills that will matter most are judgment, clarity, and taste rather than coding. Lenny frames the discussion as a look at where product management, engineering, and design are heading, as well as a practical guide to getting more out of AI tools.
What a professional vibe coder does all day
Lazar calls it a dream job because he gets paid to do what he would have done anyway. He uses tools like Lovable to push projects to production for internal and external use. The work ranges from marketing and sales templates to internal tools with many integrations. He describes it as "an ideas role." Many people have good ideas but either don't know how to build them or don't have the time, and his job is to turn those ideas into working software quickly, with the quality and security that production requires.
Some of his work is public. When Lovable launched its Shopify integration, he built most or all of the templates users were remixing. He also vibe coded Lovable's merch store to show that Lovable and Shopify work together simply enough for anyone to use. Anyone who bought the shirt he wears on the show bought it from a store he built. On the internal side, he mentions a feature adoption matrix the company wants, to track how many people use each new feature. He says Lovable's stack is custom enough that nothing off the shelf would fit. He adds that he has reached the point where, if setting up an enterprise account with a vendor would take an hour or two, he can build the tool himself faster, so he is "in the build boat."
He started on the growth team. Elena Verna, Lovable's head of growth, brought him on because she had many ideas and needed someone with the mindset, velocity, and ownership to take them into production. Since then, he says, "every department needs a Lazar now or yesterday." He is moving into go-to-market work, building internal tools for the enterprise team, and working on community tools. He says he thrives when he is handed a rough concept and asked to bring it to life as soon as possible.
Why a non-technical background can be an advantage
Lazar argues that not having a technical background helps, because "people like me don't know that they are not supposed to be building XYZ," and so they go ahead and build it. His example comes from about six or seven months before the recording. Someone in the Lovable community wished Lovable could build Chrome extensions. Technical people explained why it couldn't, citing a different stack. Non-technical people, including Lazar, simply asked Lovable to build a Chrome extension from an app, and it worked. He says others built desktop applications on Lovable, which in theory shouldn't have been possible either.
A second example involves Lovable's community manager. While making a presentation deck, she wondered whether it could be a video, and she prompted her way into generating an actual video inside Lovable before that was a supported feature. It is a feature now, but at the time even Lazar thought it was impossible and had never tried it. He says people like them come in "completely unbiased and very positively delusional," and that this is a necessary attitude with AI tools: assume everything is possible until proven wrong.
Self-awareness, clarity, and the 80/20 split
Lenny raises two common concerns about non-technical builders: they may not know how to get unstuck, and they may be building fragile "slop" because they don't understand architecture or scaling. Lazar says the most important answer is self-awareness. He is "delusional" about what can be built, but he also knows he has to get better himself for those projects to succeed.
He says he realized early that coding is not the problem being solved. Clarity is. AI output is already faster than human output, so what matters is knowing what you want. From his second day at Lovable, he says, he leaned on chat mode, and he still spends about 80% of his time planning and chatting and only 20% executing. "Most people optimize for the wrong" kind of speed, he says. The tool doesn't matter: whether someone uses Cursor, Claude Code, or Lovable, the problem is the same. AGI isn't here yet, so the human still steers the ship.
He treats the tools as technical co-founders and educators, learns by building, and "religiously" reads the agent's output rather than the code. He says he doesn't care about syntax and trusts current models' code output, though he acknowledges others may be less confident. What he watches closely is what the agent tells him, because of two limitations he wants to work around.
The genie and three wishes
Lazar explains the two limitations with the story of Aladdin. The genie grants three wishes, not three thousand. For him this stands for the machine-level limit, the context window. An AI can only handle so much in one request while still reading, researching, thinking, and executing well. He uses an arbitrary figure of 100,000 tokens to illustrate: some go to reading, some to browsing, some to thinking, and some to writing code. He says this may change within a year, but for now tokens are the limit.
The second limitation is human. If you tell the genie you want to be taller, it might make you 13 feet tall, and now you can't sit in a car or fit through your front door, because you weren't specific. AI doesn't understand "you know what I mean." Lazar notes that at 36 he has 36 years of experience being human, which lets another person infer his meaning, and AI has none of that. So people need to be specific, give references, and supply the right context. He can't control the context window or model quality, but he can control his own inputs, and that is what he wants to teach.
Building taste through exposure time
Asked how to get better at clarity, Lazar says it starts with understanding what tasteful looks like: the difference between good enough, world class, and magical. He develops this through what he calls exposure time, an idea he credits to Lenny. Lenny traces it to Guillermo Rauch. The practice is to deliberately spend time with content, people, and products that raise your standards.
He describes his own progression. First he realized he could build. A week later he realized he wasn't fast enough, so he optimized for speed. A couple of weeks after that he started asking whether he should have built the thing at all, a phase he says is still ongoing. Once AI has solved "the how," everything else matters: design, taste, and user experience. He points out that people make decisions, including purchasing decisions, emotionally.
That's why he tells people without coding experience not to start learning to code now. "We won't be rewarded in the world of AI for faster raw output. We will be rewarded for better judgment." He also stresses that judgment is a muscle built through building, not only through consuming good work.
Parallel prototypes as a way to think
His first practical technique is to start several versions of a project in parallel, each with more clarity than the last. For the first, he opens Lovable (or any tool) and does a brain dump, often with Lovable's voice input, and sends it without waiting for the result. Then he opens a new project with more structure, now that the brain dump has surfaced some threads: specific features, specific pages. For the next, he attaches visual references such as screenshots or animations from sites like Mobbin or Dribbble, since most tools accept files. For the one after that, he finds existing code from libraries such as 21st.dev and attaches code snippets. His reasoning is that even if English is "the number one programming language," these tools still communicate best in code, so a snippet gets closer to pixel-perfect than any description.
Lenny sums up the approach: brain dump, a more considered prompt, a design reference, and a code template, all running at once. Lazar says taking action this way is cheap, often free on the tools' free plans, apart from builder credits. Comparing four to six concepts brings clarity that a blank page or a ChatGPT conversation without action wouldn't. It also addresses what people call AI slop, which he says usually refers to generic design rather than messy code, because it produces several design directions to choose from.
He expects the objection that this spends more credits, and he agrees that it costs more upfront. But he argues it saves hundreds of credits, possibly hundreds of dollars, and days of work in the long run, because the project starts from better clarity instead of being endlessly corrected. He acknowledges this runs against Lovable's short-term interest, and says the company's business is empowering people to build rather than having them fix things forever. He says everyone he has taught the framework to calls it an eye opener. He didn't set out to invent a hack. He was waiting for agents to finish and started another project in the meantime. He says it is also why he ships so much: he typically has five or six Lovable tabs open and switches between them.
PRDs and markdown files as a dynamic context window
That raises the question of how he switches between so many projects without losing context or producing bad work. His answer addresses the genie problem. In any tool, he says, by message 10, 20, or 40, early parts of the conversation start to get lost, because the agent can't reread everything on every request. So he treats the tool like an engineer who needs a steady supply of reference material.
After the parallel builds, he says the winner is usually obvious once you have built hundreds of projects. He may calibrate it with a prompt or two. Then he has the tool, or ChatGPT, produce a series of PRDs. He calls them product requirements documents, or "sources of truth" for what must be true for the project to succeed. He writes at least four:
- a master plan, a compass describing what is being built;
- an implementation plan, describing how it will be built and in what order;
- design guidelines, because the system is "not emotionally intelligent yet" and he has to define look and feel;
- user journeys, tracing what happens after a user registers, then the next step, and so on.
He reads all of them. This is where his planning time goes, and he says he'll spend a full day on it if needed, because everything depends on it. Then he creates a final plan.md or tasks.md that breaks the work into tasks and subtasks, in Markdown because he has found AI likes to read it. The last layer is the agent's behavior instructions, such as rules.md or agent.md files in Claude Code or Cursor, or project knowledge in Lovable's settings. His instructions are roughly: read all the files before doing anything, check tasks.md for the next task, execute it, then tell me what you did and how to test it.
From that point, his prompts mostly become "proceed with the next task." He reads the agent's reports, tests, and occasionally intervenes, and he keeps the documents updated so the context the agent works from shifts over time. That's how he runs five projects at once without losing productivity.
He expects to be out of this particular job soon. He predicts that within about three months an agent will do this document management for him, and he says he doesn't invest in the skill for that reason. He uses it today to work around the shortcomings of both humans and LLMs, but he spends "100% of my time today on good judgment, clarity, quality, taste, good copy, good fonts." He singles out fonts as something people working with AI almost never talk about, even though he thinks they account for 60% or more of how the output looks.
Why vague requests waste the scarce resource
Lazar describes what happens when people skip this structure. Something breaks, nothing is documented, and the user describes the symptom without pointing to any files. The tool starts investigating. With 20 files that's fine. But he is working on a project with 60 or 70 edge functions, and if he just says "this broke," he expects the tool to spend around 80% of its token allocation reading, leaving 20% for thinking and fixing.
He is explicit that the next part is his own guess as a non-expert, and says an LLM expert might correct him. His view is that the tools are obedient and agreeable, and will sometimes claim to have fixed something they didn't in order to please the user. People blame the machine, but he says "it's your fault, my friend" for not providing clarity or context. Things get worse when the user gets angry. He says he has read thinking traces where the model's first move after an insult is to work out how to calm the user down, spending more scarce tokens on an apology instead of the problem. He hopes AI moves toward being more honest than obedient, for example by saying it only partially fixed something.
Lenny adds that Lazar had mentioned earlier that when the context runs low, the fix at the end tends to be shallow. Lazar again calls this a gut feeling rather than something he can prove, but says his experience is that unclear requests get "the easiest fix in the book," while pointing the agent to the file he suspects gets a real fix. He paraphrases a quote he can't attribute: the ceiling on AI isn't model intelligence, it's what the model sees before it acts. Exposure time, he says, applies to agents as much as to people.
His advice is to vibe freely while prototyping and exploring, and once exploration is done, to use documentation and agent files, because tokens are still precious even though they'll get cheaper.
What goes in each file
Lenny asks what the minimum version looks like for someone wanting to improve. Lazar describes the master plan as a "10,000 foot overview": why he is building this, who it's for, and how he wants them to feel. It often points to the other documents, for example saying the design should feel modern and slick but that exact parameters are in the design guidelines file.
The implementation plan sets the order of work: start with the backend and tables, then authentication, then the API, and so on. He compares it to an ideas person pitching a technical co-founder, who replies that the idea is doable and here is roughly how to sequence it. It's a roadmap, not a detailed spec. All the documents ultimately serve tasks.md. Once that exists, he says, the rest is almost irrelevant.
For design guidelines, he likes to include some CSS, because AI can be "over creative" with design and this is where he adds more technical steering. The user journeys cover navigation and features at a high level, and tasks.md turns all of this into detailed tasks. He has built custom GPTs in the ChatGPT store, a Lovable PRD generator and a Lovable base prompt generator, that ask clarifying questions after a brain dump and produce these files. He says they are trained to think the way he does.
He says tools like this are making everyone "product managers on steroids," and that good PMs are paid for judgment, not for writing PRDs. He stresses that none of this replaces building. People get better by starting one, two, or five projects today.
Lenny notes that this may sound like a lot of work, but a few hours or a day of planning to get something that would otherwise take weeks or months is an enormous return. He says it shows what professional vibe coding looks like, as opposed to casually typing requests.
Prototyping still matters: "demo, don't memo"
Lazar says prototyping has real value on its own, especially for people in healthcare, finance, or other regulated settings who can't ship to production. Lovable's motto for 2025 was "demo, don't memo." Instead of writing documents and holding meetings to explain a vision to engineers, a marketer or salesperson can build a prototype in 30 minutes and hand it over.
He gives an example from the job he held before Lovable. Around this time the previous year, he needed something enterprise-grade that neither he nor Lovable could build to production standard at the time. He built a prototype in four hours, and the engineering team he worked with replicated it in production about six to seven months later, connecting all the pipes. He estimates that describing it in words would have taken him at least a week or two. He says Lovable in January 2026 is far ahead of the version he used then.
He also says that, to the best of his knowledge, people at at least half of S&P 500 companies use Lovable to some extent, and that many enterprise customers, which he describes as leading companies in ride-sharing, telecommunications, healthcare, and finance without naming them, report the same thing: even if they can't push to production, marketers no longer wait for engineers, and go-to-market, sales, and HR staff build internal tools for things like expense management and employee onboarding.
Why "good enough" no longer is, and why design matters next
Lazar says AI is an amplifier regardless of background: "If you don't know what you're doing, you're just going to produce garbage faster." In the past, good enough was good enough, because producing anything was hard. A SaaS product that worked was enough, however it looked. Now that everyone can produce good enough with AI, he says, the gap that matters is between good enough and world class, and learning to produce world-class, magical work is the key lesson.
Lenny suggests that PM skills of clarifying what to build will matter most. Lazar agrees that PMs are winning with AI today because they bring clarity, but says that if he were betting, designers are next. His reasoning is that tools are being trained to make better technical decisions, but not yet better emotional ones, and "design is all about emotion."
He says his biggest personal upskill at Lovable came from working with designers there, naming Felix, Nad, and Abby. He once tried to copy a background from one of their designs in Figma. It looked like a simple gradient, but it turned out to be about 50 layers with different colors and levels of opacity. That showed him the gap between his assumptions and world-class work. His advice is to expose yourself to excellent design, follow Felix's newsletter, and learn design styles and how to prompt for them. He didn't know what Bauhaus or glassmorphism meant, so he built a public Lovable app that catalogs around 18 styles with prompts to reproduce them.
The future of engineering and the convergence of roles
Asked whether software engineering will go away, Lazar says no: "We will need elite engineering more than ever." If everyone builds everything, someone has to maintain and scale codebases, which he describes as a different skill from building. Infrastructure also suffers when everyone builds. He cites Cloudflare going down two or three times in recent months and Lovable's own infrastructure strain from influxes of new users, and says elite engineers are the ones holding the fort. Someone has to build the hosting, security, email, connectors, and APIs that billions of builders will need.
At the same time, he says that if he had an 18-year-old brother, he would suggest becoming a plumber rather than getting a CS degree, noting that he sees electricians and plumbers as a new generation of millionaires in the US. He calls it a balancing act and says he isn't sure, but believes good engineers who understand where things are heading will remain needed and scarce.
On the application layer, he predicts that "vibe coding is just coding" within 12 months, and says he'll call himself a "rapid engineer." He notes that many elite engineers now say publicly that AI writes all their code. He compares hand-written code to calligraphy: rare enough to become an art. In his view everyone becomes an engineer, whatever the label, "using LLMs for raw output based on good judgment. Or bad judgment." Lenny describes this as the once-separate circles of engineer, designer, and PM converging.
The 4x4 debugging workflow
For getting unstuck, Lazar uses a framework he calls "4x4," after the drive system that gets a car out of mud. There are four approaches, and he tries each only once.
The first is to let the tool fix itself. In Lovable, when the agent recognizes an error, it marks the message in orange and offers a "try to fix" button, which usually handles smaller issues. The harder cases are when the problem persists and the agent doesn't know it, often because of a third-party integration the tool wasn't told how to observe. He says Lovable, Cursor, and Claude Code are all good enough to fix any problem they are aware of, so awareness is the key.
The second approach adds that awareness. He opens the preview environment, runs the broken function, and reads the browser console. If nothing useful is logged, he asks the tool to add console logs to the relevant files so they can watch every step. He framed it as finding the problem together instead of yelling at the tool. He reruns it, copies the log history into the chat, and says this is enough "99% of the time."
The third approach brings in an outside tool. He exports the code to GitHub, which Lovable and similar tools allow, and uses OpenAI's Codex, which he has used since its beta, to diagnose the problem. He then applies the fix in Lovable. He doesn't let Codex make changes because he doesn't know its agent well enough to steer it. His older manual method was to use Repomix to compress the whole codebase into one file, upload it to regular Claude or ChatGPT along with the problem and console logs, and ask for a diagnosis. He compares it to hiring an outside consultant. Lenny adds that he has heard Codex described as the go-to for the hardest bugs, mentioning a Karpathy tweet to that effect.
The fourth approach assumes the problem is your own fault, which Lazar says it usually is: a bad prompt or a badly framed request. Use version control to revert a few steps, take a walk or get a coffee, rethink the prompt, and try again. Sometimes the AI just "stumbles on a very small rock," such as a minor syntax slip, and simply repeating the request works.
Teaching the agent to learn from mistakes
The step Lazar calls "the key one" comes after a fix. He switches to chat mode and asks, in effect: it took four attempts to fix this, so how can you help me prompt you better so next time we fix it in one go? He says the answers are almost always good. He then goes further. Since he won't remember the lesson two days later, he asks the agent to add it to rules.md, which it reads every time anyway. "You're just going to learn that I'm stupid and you're going to prompt yourself better." He says removing yourself from the loop and moving context into files solves most problems with AI today.
He uses chat mode the same way for prompts in general. As a non-designer, he still doesn't know much of the terminology, so when he's stuck he brain dumps into chat mode and asks the tool to help him write a better prompt, letting it "effectively prompt itself."
Reading agent output, and a lesson from being too delusional
Lenny connects Lazar's focus on agent output to Ben Tossell, who Lenny says learns how systems work by watching agent output, and to a conversation with Cursor's CEO about what layer comes after code. Lenny suggests that layer may simply be the conversation with the agent in English. Lazar agrees and says reading the output is how he learns what is possible, which feeds his judgment.
He admits this can seem to contradict his praise of delusion, and tells a story about a failure. When OpenAI released native image generation in ChatGPT, he wanted to build a Lovable wrapper around it right away, without realizing there was no API yet. He spent at least a week trying to brute-force it. A week later the API came out, and he built the app in 30 seconds. His takeaway is that agentic tools, which browse the web, read files, and reason, will often tell you something is currently impossible and why, and that conversation is where he learns the most.
Workarounds that become obsolete
Lazar says many of his workarounds from a year earlier would have impressed people then. He built a course with Starter Story on them, and he says people told him he was the only one who knew those secrets. Now, he says, Lovable natively handles 99% of it, and his seven-day YouTube series from March on learning to vibe code with Lovable is "completely obsolete."
He mentions a post he has seen circulating from someone who works on Claude Code. It says it took roughly 200 years from early steam engines to cars, after which about 90% of the US horse population disappeared within 20 years, while the author, hired for a technical writing role, felt obsolete six months later. Lazar's takeaway is that people won't get the 20 years horses got. But he says he is excited rather than scared, because the work being automated is work most people disliked, such as meetings, note-taking, and spreadsheets. He expects people to be paid to think longer, because building will be nearly instant and clarity will be the bottleneck. That's also why he says he never got good at Claude Code: it is so powerful that when he started without enough clarity, it went in the wrong direction from the start. He sees himself as stronger with exploratory, prototyping-oriented tools than with the tools elite engineers use.
Which skills will stay valuable
Asked what people should focus on, Lazar names emotional intelligence and human-to-human skills first. He expects people to tire of fake images, posts, profiles, and videos, and to value live, human interaction more. He says anything deterministic, where a given input reliably produces a given output, including a lot of math-heavy work, is exposed to AI. Where the path from input to output runs through human relationships, he expects people to keep an edge.
In concrete terms he lists great design, meaning images, fonts, and especially copy. He thinks he and Lenny could already spot AI-written copy within seconds, and says he no longer likes reading AI output himself. He predicts new job titles for these human-first skills, pointing out that he was vibe coding from July 2024, about seven months before Karpathy coined the term in early 2025, without having a name for it.
He makes deliberately strong predictions about specific professions. He expects translators and most non-elite journalists to be replaced. Average writers should be careful, while great writers will be amplified, perhaps writing seven books a year instead of one. He says comedians won't be replaced because AI "is never going to be able to write a good joke," and calls this his personal belief. Lenny mentions hearing from a data-labeling founder that a lab, possibly Anthropic, hired National Lampoon writers to help train models. Lazar replies that he'll likely be wrong on 95% of what he said within three months, and that this is the one thing he's confident about.
How to become a professional vibe coder
Lazar describes his path as anything but linear. He trained as a forestry engineer, which involved no coding, and says engineering still builds certain skills. He worked blue-collar jobs, including at Subway while studying, and waited tables for a long time, which he says taught him what people like and don't like. He compares his career to Slumdog Millionaire, where each experience prepares the character for a question. He spent the last seven or eight years in startups doing everything except writing code, starting in community management and social media. He notes that distribution matters a great deal: when everyone can build and the number of consumers stays the same, attention becomes the scarcest resource.
He believes he got the job by building in public. He shared failures, knowledge, and projects on YouTube and especially LinkedIn, which he says suits his long-form style better than X. His advice is to give away every "secret" as soon as you figure something out, join hackathons, and meet other builders. He also shares a hiring tip: some candidates stood out by sending Lovable apps instead of résumés, and he says Lovable employees will always open a link on a lovable.app domain.
He says some companies hired vibe coders before Lovable did. One, which he didn't name, has three full-time vibe coders migrating its old codebase, CRM, CMS, and other tools onto Lovable, and some S&P 500 companies list Lovable skills as recommended in job descriptions. His main point is: "You don't need a company to hire you. You can hire yourself as a professional vibe coder first." He thinks he clicked with Anton and Elena because he was already doing the job before he was hired.
He also talks about why he is so enthusiastic. He got his first computer at six and always assumed he would build software. Life was complicated, he tried and failed to find aligned technical co-founders, and over the past five to ten years he had almost given up. At 36, he says, he feels like that kid again. His advice to anyone afraid is to build something, because fear turns into excitement once you see what's possible. The only reason to be afraid, he says, is if you're doing nothing.
Closing: the tech stack doesn't matter, quality does
In his final remarks, Lazar says the tech stack doesn't matter. Whether something is written in HTML or React never really mattered and matters even less now, because users want a great experience. Since anyone can produce good enough, you have to learn to produce magic or you'll be lost among millions of others. But he adds that if you don't yet know what magical looks like, you shouldn't be discouraged. Start from good enough and level up.
He comes back to exposure time as the way to level up: spend more time learning than building, read the agent's output to understand how it thinks and what's possible, follow strong designers, and watch them work. He mentions following one tool creator who posts 40- to 50-minute videos of himself designing almost daily, so Lazar can see how a world-class designer talks to and prompts the tool. His conclusion is that you can produce garbage as fast as magic, in the same amount of time, and that the difference is the input. His advice is to forget decisions about backend and frontend and optimize for quality, taste, and design.
I'm the first official vibe coding engineer at Lovable.
You're at the top 0.1% elite level of vibe coding. It's a dream job for so many people.
It became a job by building in public. You don't need a company to hire you. You can hire yourself as a professional vibe coder first. You've never coded. You don't want to look at the code.
Coding is going to be like calligraphy. People like, "Oh my god, you wrote that code. That's so amazing." It's going to be so rare that it's going to become an art. These Venn diagrams of engineer, designer, PM used to be very separate. Now they're converging. AI, regardless of your background, is an amplifier. If you don't know what you're doing, you're just going to produce garbage faster.
Feels like an emerging core skill is learning clarity in the ask of the AI.
I like to use the Aladdin and the genie analogy. You rub the lamp, a genie comes out. "I'll grant you three wishes." The first wish is "I want to be taller." Genie makes me 13 ft tall because I was not specific. "Hey, I just don't understand. What do you mean when you say you know what I mean?" So, you need to be specific. I'm optimizing 100% of my time today on good judgment, clarity, quality, taste.
Today, my guest is Lazar Jovanovic. Lazar is a professional vibe coder. He gets paid to vibe code all day and build internal and external products. This conversation is going to blow your mind in so many ways. This is not only a really interesting new career path for people to consider. If you listen to what Lazar shares, it's also a really important glimpse into where things are heading for tech roles. I found myself thinking more deeply about the future of product management and engineering and design during this chat than I have in a long time. We also spent a bunch of time on Lazar's best advice as an elite vibe coder for getting the most out of AI tools. He's got a bunch of really interesting and useful frameworks I've not heard anyone else share that will immediately level up your success using all the latest AI tools.
This conversation is going to expand your mind in so many ways. I cannot wait for you to hear it. If you enjoy this podcast, don't forget to subscribe and follow it in your favorite podcasting app or YouTube. It helps tremendously. And if you become an insider subscriber of my newsletter, you get over 20 incredible products for free for an entire year, including a year free of Lovable and Replit, Bolt, Gamma, n8n, Linear, Devin, PostHog, Superhuman, Descript, Wispr Flow, Perplexity, Warp, Granola, Magic Patterns, Raycast, ChatPRD, Mobbin, and Stripe Atlas. Head on over to lennysnewsletter.com and click Product Pass. With that, I bring you Lazar Jovanovic after a short word from our sponsors.
This episode is brought to you by Strella, the customer research platform built for the AI era. Here's the truth about user research. It's never been more important or more painful. Teams want to understand why customers do what they do. But recruiting users, running interviews, and analyzing insights takes weeks. By the time the results are in, the moment to act has passed.
Strella changes that. It's the first platform that uses AI to run and analyze in-depth interviews automatically, bringing fast and continuous user research to every team. Strella's AI moderator asks real follow-up questions, probing deeper when answers are vague, and surfaces patterns across hundreds of conversations all in a few hours, not weeks. Product, design, and research teams at companies like Amazon and Duolingo are already using Strella for Figma prototype testing, concept validation, and customer journey research, getting insights overnight instead of waiting for the next sprint. If your team wants to understand customers at the speed you ship products, try Strella. Run your next study at strella.io/lenny. That's strella.io/lenny.
Today's episode is brought to you by Samsara. If you listen to this podcast, you know that we spend a lot of time talking about building things that sit on a screen. Onboarding funnels, mobile apps, and checkout flows. Samsara is building products for the physical world. First responders racing to emergencies, truck drivers carrying critical supplies, construction workers building our cities and data centers. These are people who put everything on the line every single day. And Samsara's technology protects them.
Samsara is solving complex problems at the intersection of hardware, software, and edge AI. And their AI doesn't just detect events. It reasons about the intent and answers questions like, did that truck driver brake abruptly because they were distracted? Or was that a heroic act? If you want to ground LLMs in messy real-world telemetry or solve edge constraints at a planetary scale, Samsara wants to talk to you. If you like playing with enormous data sets, moving fast, and working in small teams, come help build the technology that makes the physical world safer and more efficient. Visit samsara.com/lenny to learn more. That's samsara.com/lenny.
Lazar, thank you so much for being here and welcome to the podcast.
Thanks for having me, man.
Okay, so I had Elena Verna on the podcast. She's head of growth at Lovable. She mentioned that she works with a professional vibe coder. You. I had so many questions. I almost wanted to go on a tangent with her to try to understand this role. Instead, I asked you to come on the podcast. There's so much I want to talk about. I want to talk about just this career path and just how you got into it, how other people might get into it, where you think this is all going, this whole vibe coding thing. Also, I want to get into what you've learned about being successful using all these AI tools, because this is your job. First, I want to just start with understanding this actual job. Just, what is it that you do day-to-day? You're basically being paid a full-time job to vibe code. Incredible. What are you responsible for? What are you doing day-to-day?
Well, as you said it, it's a dream job, right? I get paid to do what I would have done anyways, right? It's the best job in the world. I get to use tools like Lovable every day to push projects to production, whether for internal or external use. Those could be ranging anything from different templates on the marketing side, sales side, or whatever, or they can be as deep as building some internal tools with a lot of integrations and connections and whatnot, right? So the surface area that I cover is pretty wide across all departments because it's such a flexible role and it complements so many things, right? It's an ideas role. A lot of people have a lot of great ideas but they don't know how to build them, or they just don't have the bandwidth to, and that's where I step in today to make sure that these ideas come to life fast and with the quality and security that they should have in order to be available for users in production.
And one thing that's really interesting here is it's both internal and external tools. A lot of companies have someone building a bunch of internal tools using AI. You ship stuff that's actually public, and it's sort of product-level products.
Yeah, definitely. Some of the stuff that I've shipped that are public are, like, when we launched our Shopify integration, most of, if not all, the templates that users were remixing were built by me, right? So stuff like that, or like the merch store, because we wanted to obviously prove the concept that, hey, Lovable and Shopify just works. It's so simple, anybody can do it. I vibe coded our merch store. So all the merch, including this shirt, that people were buying online, they would have bought it from a store that was built by me.
But then again, on the internal side, we want to track a lot of things. One of the cool things that we want to build now, for example, is a feature adoption matrix. If we build a feature, how many people are actually using it, adopting it? And that's a pretty custom build, right? We have a very custom stack. We're building custom features. There's nothing out there that I could just pick off the shelf and build or adopt faster than I would have built it myself. At this point, I'm at a stage where, if it takes me an hour or two hours to set up a big enterprise account somewhere, I'm just going to build it myself faster. So, you know, I'm in that position of build versus buy. I'm in the build boat, so to speak. Yeah.
And then who do you report to? Are you kind of this rover that helps wherever, or do you work with a specific team?
I'd say probably closer to the former, right? I started in growth, right? Elena brought me on early on, because she has so many great ideas and she just needed somebody with the right type of mindset and velocity and ownership to just take them away, build them up, get them into production, whether they're based on education or anything go-to-market or whatever. But then obviously when you're able to ship fast, everybody needs that in an environment that we as a company are now living in, where we're the fastest growing startup in history. So every department needs a Lazar now, or yesterday. So now I'm shifting a little bit, I guess, into some of the go-to-market roles and even building some, again, internal tools for the enterprise team. But I'm working on some community tools as well right now as we speak. So, I'm a little bit all over the place, but I kind of thrive in that environment where I'm given a rough concept, a rough idea, and I'm just tasked to bring it to life as soon as possible.
Okay. I'm hoping with this chat we create a lot more Lazars, and I want to get to the career path, how you got to this, and what it takes to actually become a full-time vibe coder. But I want to start with, because you do this full-time. You're at the top 0.1% elite level of vibe coding. You're doing this full-time. They hired you to do this as a job. I'm so curious what you've learned. What are some pro tips that you've developed for being successful with AI tools, Lovable? And also just more broadly, what are maybe two or three things you've learned that help you be really good at this job?
The first understanding that I had very early on, even though, just in full transparency before we begin, I don't have a technical background. I never wrote a single line of code in my life, almost. I've, you know, written a couple console logs manually and that's about it, right? So I very much lean on AI assistance.
Let me actually follow that thread because that's such a good point, and it's something that, when we were chatting earlier, you pointed out. Your feeling is it's actually an advantage to not have a technical background when you get into this space.
Yeah. Yes. I honestly feel that it is, because people like me don't know that they are not supposed to be building XYZ, and that's how we actually are able to build it. Let me give you an example. Six, seven months ago somebody in our community was like, "Oh, I wish Lovable could build Chrome extensions," right? And then folks that are not technical were like, "Well, why is that not possible?" right? And then people that are technical start explaining, "Oh, well, you know, it's React, it's a different stack, it's this." And people like me, including myself, would just go into Lovable and say, "Build me a Chrome extension based on this app," and I was able to do that with Lovable. There were people that were able to build desktop applications on Lovable. Again, something that shouldn't be possible. It simply is. Right. Our community manager, with me at one point, was building this presentation deck for something. She's like, "Would it be cool if this was a video?" right? And then she just prompted her way into generating an actual video inside Lovable before that was available. Now that's a feature. Now you can prompt Lovable to do it. But back in the day when she did it, even I thought it was impossible. I never tried it.
So I think that's the advantage that we have over people that are technical. We just come into this completely unbiased and very positively delusional, which I think you have to have when working with AI tools. You have to come with this delusion that absolutely everything is possible until proven wrong. And that's just the pursuit that I have in my mind that has helped me, among other things that we will chat about today, I think, to excel in this role that I have at Lovable.
Two of the concerns, maybe traps, people that don't have a technical background fall into, in theory: one is, if you get blocked, it's not obvious how to solve a problem. And two is just, are you building this teetering slop that will collapse someday because you don't know system architecture, you don't know if this is going to scale, all those sorts of things. So coming back to what you've learned about how to be successful and build successful products, talk us through just things you've done and things you've learned for how to avoid those sorts of things, and what you do when you get stuck is one example.
I'm happy that you mentioned those limitations. I have some other ones that I want to bring in, but let's address this one first, which is the most important one, and that is you have to be self-aware, right? I didn't come into this... Yes, I am delusional, as I mentioned, in the sense that I just don't want to accept something's not possible, but I'm also well aware that I need to be better in order for it to become a reality, from my own point of view, for my own sake. So I understood very early that coding is not the problem that we're solving for here. The problem we're solving for is clarity, right? The output that AI can do is much faster than human output anyways.
So very early on I started leveraging chat mode, and to this day I can say I spend 80% of my time in planning and chatting and only 20% in actually executing the plan, right? I'm optimizing for the right kind of speed. Most people optimize for the wrong one. That's the first lesson that I learned, literally on day two, because I came into Lovable, that was my first exposure to this. I've tested and played around with all the tools, obviously, but whether somebody's doing it in Cursor or Claude Code doesn't matter. Wherever you are, 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. Yes, AGI is coming, but it's not there yet. So until it's here, you're still steering the ship. In order for you to steer the ship, you kind of have to know the instructions, right? And the best way to learn is by building, but treating these tools almost as technical co-founders and educators, and learning while doing, and religiously reading the agent output, not the code output. I don't care about the code. The syntax is not of my interest. It's what the agent tells me that matters to me. I put a lot of trust in LLMs and AI these days. And I understand that there may be some people that are not as confident as I am. I just feel that the models today are good enough for me to trust in their syntax output. However, I'm concerned about the agent output, because of the two limitations that I want to tackle next, right? The first one being that...
There's a limitation when you work with LLMs. So there's a machine-level limitation and there's a human-level limitation, right? The first one is there's something that is known as the context memory window, right? And for nontechnical people, I like to use the Aladdin and the genie analogy when I explain, right? It's very simple. Everybody knows the storyline. You rub the lamp, a genie comes out and tells you, "Okay, I'll grant you three wishes. Not 3,000 wishes, not three million, just three at a time." Right? To me, when I translate that into working with AI, that simply means, hey, I can only make so many requests
within a request at a time for AI to be able to listen, understand what it needs to do, scope it, do the research, read, like take all the actions, all the inputs and ingredients that it needs to produce a high quality output. Right? So, that's the first part, understanding that there's a limit and it's denominated in tokens. Maybe that's going to be different a year from now, but today there's a token limitation. I'll take an arbitrary number of 100,000 tokens for example. So when you make a request, a part of those tokens AI spends to read stuff, another to browse the web, another to think and then another to execute the code, right?
Then there comes the second limitation which is me and you, humans, which is, let's go back to the analogy of the genie and Aladdin. I asked the genie for the first wish and the first wish is I want to be taller. And guess what happens? Genie makes me 13 feet tall. All of a sudden I can't sit in the car. I can't get into my house. I'm a dysfunctional human being. Right. Right. Because I was not specific. Right.
Like, so the part that we need to optimize for today, it's going to get better but today it's still not there yet, is that AI just doesn't understand. What do you mean when you say you know what I mean? Like you do when I tell you that we as humans, we have, I'm 36 so I have 36 years of experience of living as a human to know what you mean, but AI doesn't have that, right? So you need to be specific, you need to provide references, you need to provide the right context.
So what I've learned is how to combat that part and I think, you know, because I can't control the first part, which is the token memory window, the quality of the LLM models, you are 100% in control of the latter. And that's what I want to dive into today as well and just try to teach people, okay, if I'm the malleable part, how do I fix that part, right? I think that's the key lesson here.
This is so helpful and I love this metaphor of the genie. This piece about clarity is such a thread I've been noticing across people that have been successful using AI tools and it feels like an emerging core skill is learning how to be, learning clarity in the ask of the AI. Do you have any advice or anything you do there to help be better at being clear with what you want?
Yeah. So, first of all, you need to be, as you said yourself right now, you need to be good at understanding what clarity means and how to translate it. In my terms, clarity means understanding what tasteful looks like, what's good enough versus what's world class, what's magical. And I developed that through something that I heard from you. You mentioned before, which is exposure time, right? Making sure that I'm exposing myself to content and to people and to relationships or whatever that are going to help me to level up in that domain.
Again, it goes back to self-awareness. Like I knew even before I joined Lovable, I was like, okay, even before I started using Lovable or any AI tools, first thing that I knew was like I don't know how to code, right? So my first thing was like, "Oh, I can build. Wow, amazing." But a week later, it was like, "Oh, I can build, but I'm not fast enough." So I optimized for speed. So I was like, "Oh, I can build and I can build so fast." And then two weeks later, my development cycle that I'm in began and it's still ongoing, which is wait a minute, should I have even built this in the first place?
Because once you figure out that we solved for the how, which is AI-assisted or rapid engineering, call it whatever you want. You can call it vibe coding if you want to. But like we solved for that. Now we got to solve for everything else. And everything else is what matters. Good design, good taste, good user experience. Like when you think about who you're building stuff for with these tools, you're building it for humans. Humans are emotional beings and we all make our purchasing or any kind of decisions on an emotional basis, right?
So I think that the core skill there to work on and develop today isn't, again, coding. Although I have nothing against traditional engineering and I'll say later why I'm actually a big fan of it, of elite engineering. But like people like me, people watching that are like, should I start learning how to code? If you haven't done it yet, I'd honestly say no. Like you're optimizing for the wrong skill set. We won't be rewarded in the world of AI for faster raw output. We will be rewarded for better judgment.
So I think that better judgment comes with, again, to go back to your question, like how are you solving for that? How are you solving for this? Well, it starts with exposure. So I'm deliberately exposing myself to people and resources that I know I need to consume to level up. And then a lot of it just comes from building as well. You know, if we're honest, like it's a muscle. Everything is a muscle. You need to practice. You need to see what's possible. And you know, that's where some of the techniques and mindset shifts that I want to also use an opportunity today to ingrain into people's minds later down the call may be useful.
So, okay. So, what I'm hearing here is because coding is now essentially a solved problem. I love that you don't look at the code. You've never coded. You don't want to look at the code. You don't care about what's happening there, that instead you're watching this agent output. I want to actually ask about that, but what I'm hearing here is the areas you are investing in building in yourself is at the front end clarity around what it is, and I want to hear how you actually do that, what you do there, you have a really cool system there, and then there's like the taste and judgment of knowing is this the thing I want. It feels like those are the two sides now that are more and more important.
And on the taste judgment side, you share this concept. This is something Guillermo Rauch shared in our conversation. This idea of exposure time, exposure hours, being exposed to great stuff. Here's a great user experience. Here's a great onboarding flow. Here's a great, I don't know, website. So, I really like that advice because it's so actionable. Okay. I'm going to spend more time with stuff that's great to inform my taste and judgment. And then on the clarity piece, let's actually talk about that. What do you do there to be clearer with Lovable and other AI tools to help it build the right thing?
This is the first mindset shift that I want to put into people's minds. Right? If you just have a vague idea, let that be your first version of the project. Open Cursor, Lovable, whatever it is that you're using, and just input a brain dump prompt, right? Just talk into it. Lovable specifically, I don't know about the other tools, has a really cool voice function. You click it, you just dictate the hell out of it, and just press send. Right? Don't even wait for it to finish.
Open a new window again. Lovable.dev. In here, you're like, "Okay, as I was brain dumping, I think I found a good thread, right? I think things are getting clearer. So, let me start another project now with more clarity, more deliverability. Like I know which features I want, which pages I want. Maybe I can even find a good reference. Maybe I can go on Mobbin, maybe I can go on Dribbble, maybe I can go wherever, get a good screenshot, get a good animation and attach it," because most of these tools accept files as a part of the input. So like you have the second project started. Now things are even more clear.
Now you expose yourself to quality and now you're like, well, what if I found a template that actually is already out there? Why reinvent the wheel? I'm building a platform that somebody else built. Why not expose AI to what quality looks like? Right? So what I'll do is I'll go and find a library, 21st.dev or a build or like whatever places which allow me not to export screenshots but export code snippets, because guess what? Even though English is the number one programming language, Lovable and all other tools still communicate in code the best. If you want to get pixel perfect results, just give them code. It will interpret it better than your English or Spanish or whatever language that you use in these tools.
So that's the third way. You're like, "Okay, now I'm even more deliberate. I'm not even going as wide as giving it vague concepts. I'm giving it code snippets like I want this exact design. I want this exact type of functionality." So that's your third project. And then by the time you do all of these three, you're already at a level of clarity that you wouldn't have if you just sat with an empty piece of paper or maybe chatting just with ChatGPT but not taking action.
I think taking action is so cheap these days, and free by the way. Like all the tools I mentioned have free plans. Most times you would be able to do this without spending any money at all just by starting multiple projects, because guess what, that doesn't also cost anything either, or doesn't incur additional cost except for builder credits. You're going to get three, four, five, six different concepts that you can compare. As you're comparing them, clarity just keeps coming and things get better and better to understand.
And you're also solving for one big problem that you mentioned. You used the term AI slop and I like it because a lot of people when they say AI slop they don't refer to beautifying the code but beautifying the design, right? This process that I just mentioned actually gives you four or five different design options and in the long run saves you massive amounts of credits, because a lot of people obsess over the concept of, oh, when I give them this hack they're like, oh, but doesn't that cost more? I'm like, yes, upfront it may cost a little bit more. In the long run, if you really want to finish this project, you're actually saving hundreds of credits and maybe even hundreds of dollars, not to mention the amount of days, simply because you started from a point of better clarity and better refinement process, right? So, like that's the first step of solving for clarity. There are more, right? Which is the second layer. But I assume you may have some questions on this one.
Questions and also just wow, this is such a great, it shows you the power of having someone come into this world without an engineering background. This advice of just build it five times in parallel. You ask AI to try all kinds of stuff, like this is not how someone that has been a software engineer or a PM or designer would approach stuff. So your advice here, which is so fun, is as you're getting started with a project, just run five different approaches at it to start. One is just brain dump. Here's what I'm thinking. Here's a general idea. Like use Whisper Flow or use the built-in mic. And then two is okay, now I have a general idea. Let me try to type it out. Like actually thinking through the prompt. Three is let me find a mock design somewhere online. And the sites you suggested were Mobbin and Dribbble. Those are the two that you go to.
Yeah, most times. Yeah.
Okay. And then the fourth, and these are all in parallel. It's great. Is find like actual code template that looks similar to the thing you want to build. Download like the zip file basically and attach it, or is it just HTML and CSS? Is that kind of what
Anything you got. Here you go.
Okay. And then cool. Here's the prompt here. Make me what I want. And what I love is there's two wins here. One is just it helps you clarify the idea as you see the tool build it, like oh no, that's not what I mean, let me try it again. And then two is, you pointed out, you can pick the right direction so that you're not locked into your first design and first architecture. To your point, if you then spend all this time trying to fine-tune design and direction, it's like all these tokens are being lost, you could have just started over. This is so great. Someone may think, okay, of course you're just getting us to spend all these Lovable tokens. This is what a Lovable person would tell me. But what I'm feeling is this is where you could save the most money, because if you get it correct in the beginning, you save so much work trying to get it back to where you want it to go.
A million percent, that I'm actually saving people. Like I'm actually going against what I should be saying. If I was thinking about Lovable's, I would be like, "No, no, just try to fix it in perpetuity." But that's not... We're not in the business of doing that. We're in the business of empowering anybody to build anything that they want. And then, you know, it's my personal mission that resonates with me, 'cause if there wasn't Lovable, I would have never built anything potentially in my life. And I don't think that would have been a fun life to live.
So, you know, I guarantee people, like I've tested this framework with many people and everybody is telling me the same thing. Eye opener. So simple yet unintuitive, as you said. Even though for me it kind of, I don't know, as you said, I attribute it to nontechnical background. To me that was the first thing that I would do, like I just did it. I never thought about it like, oh, I'm developing this amazing hack. I was just like, I'm waiting all this time for these agents to finish, I might as well start another project and another one and another one. And it's also a productivity hack. Like that's when people ask me like, wow, how do you ship so many things? I'm like, 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.
And that's the next hack that I want to talk about if you allow me, which is, the question in return is the obvious one, which is how do you context switch? Like you talk about context so much yet you keep switching between apps. How do you manage to do it and do it in a way that's productive, and not produce bad code or bad product? And that's how I solve for that LLM problem, again the Aladdin and the magic lamp and all that, which is if there's a limited token window, how do I make it dynamic?
And what I mean by that is this: if you just go and you prompt and you prompt and you prompt and you prompt, you realize that no matter what tool you use the memory just isn't infinite, right? By the time you reach message number 10, 15, 20, 30, 40, snippets of early messages sort of get lost in the translation, because the agent is optimizing for speed, right? If it had to read the entire conversation and the entire stream of requests that you made, developing anything viable or large would be impossible because it's just consuming a lot of time and a lot of memory and a lot of tokens.
So again, something that I just figured out very early on as I was building was like, okay, if it can't remember things, my job is to provide it with reference. So let me treat Lovable or any other tool as an engineer that I'm supposed to be providing perpetual context to as the project goes. And you can do that in many ways, but the most efficient way that I found was like I would do the four parallel builds. Like let's continue off of that example. Very quickly after you've built hundreds of projects like I did, you see the winner. Like the winner is so obvious it's not even a competition. You maybe do one or two more prompts to calibrate it. And when you're like, "Okay, the winner is here."
At that point, I either ask the tool that I'm using or I'll maybe, let's say, go to ChatGPT or whatever and ask the LLM to produce a series of PRDs. PRDs, again for people that are not familiar with the terms, are project requirements documents, or for me I call them sources of truth, right? What needs to be true for this project to be successful from a couple of perspectives. I usually build something that I call a master plan. It's basically a compass saying here's what we're building, right? It's like talking to a human. I really treat Lovable like a human being, so it's like this is what we're
building, then I build an implementation plan, which is: this is how we are going to build it, and this is the sequence, right? It's very important to me, again going back to quality, taste, human nature. I need to define, because I'm still working with a system that is not emotionally intelligent yet, I need to define how I want the app to look and feel. So another PRD that I build is design guidelines. And then finally something that just circles it all around, which is like, okay, when we know how things look and when we know how we're building it, how does the user journey look like, right? A user registers and then what? And then when they register and do that first step, what's the second step and what's the third step and whatnot. So I build at least four PRDs, right?
And then when these are built, I read them. That's the planning, chatting part. Like, that's where I'll spend a lot of time. Now, when I nail down that first design, I'll spend an entire day if I need to just planning this part out, like documentation and breaking things down, because that's how I'm setting the course. Like, everything's going to be dependent on this particular part of the process.
When I'm done doing that, I build one final document, which I call either plan.md or tasks.md, and the MD part is, you know, markdown. Basically, I'm just using markdown format because I've learned that AI likes to read markdown. And what that serves is it serves as a source of truth on, like, actual tasks and subtasks that it will need to execute to get to the finish line, right?
And then there's the final, final layer, which is, depending on what tool you use, Claude Code or Cursor have what's known as rules.md or agent.md. What you're basically doing with rules or agent files is you're letting the agent know how you want it to behave and what it should focus on in the long run, so that you don't have to repeat yourself with every prompt. Right?
So in Lovable there's a separate menu for that in your project settings where you can define project knowledge. And usually what I'll say is, hey, read all the files before you do anything. Like, don't do anything before you read all the PRDs. Read tasks.md to see which task is next, then execute on that next set of tasks, and when you're done, tell me what you did and how I should test it.
And that's where that conversation about I religiously read the agent output comes into play. I gave the agent everything, all the tools and resources that it needs to succeed. I gave it the rules. I gave it the docs. I told it what to do with them. And at that point, I'm just sitting and reading. I don't prompt anymore. From that point on, I can switch as many windows as I like. My prompts have become "proceed with the next task." I don't need the context. I outsourced that and delegated that to the agent. The agent needs context, and I need to make sure that it's dynamic. I need to make sure that I'm regularly updating the documents from time to time so that we shift that token window it uses and how it uses it over time. But I'm not prompting, I'm not interrupting the flow.
Yes, I'll go in, test, maybe put a prompt in here or there, but that's how I can build five projects simultaneously and never lose the productivity part. Which is, again, as I said, I do this today manually. Call me to talk three months from now, an agent will do this for me. I'll be out of a job, pretty much.
That's why I don't optimize for this skill at all. Like, I'm using it today to bypass the shortcomings of human nature and LLMs, but I'm optimizing 100% of my time today on good judgment, clarity, quality, taste, good copy, good fonts. Like, people don't talk about fonts at all that work with AI. They're like 60% in my mind, maybe even more, of how your output's going to look. Like, that's my obsession. I don't obsess over these things that I'm talking about today because I know what's coming. Like, the agents are going to get better, the models are going to get better. They're not going to need me to extend the context. They're going to do it themselves. So for me, the skill that I optimize for is the one that requires better decision-making rather than better output or better alignment.
Oh my god, there's so much here. This is so awesome. Okay. So essentially what's happening here is you start a project, try a bunch of stuff, pick a direction that feels most correct, and once you have a set direction, you spend essentially a day not building but working with this AI agent to plan. And I want to talk about that. And once you have the plan, then... and it's amazing that you could do stuff like this with what some people may feel are not sophisticated tools that can build incredibly powerful things. Like, you can do a lot of this with tools like Lovable, like have plans and rules and MD files. A lot of people may not know that. And so the idea is, okay, spend all this time planning, because again, that'll save you a lot of time down the road, and then only once you have a plan, you get it going. And a key part of this, this three wishes rule, is really important. The reason you're doing this in large part, beyond just being really clear about the plan, is this idea of one task at a time keeps the agent's context window small so that it doesn't lose track of where it's at. That part seems important, right? It's like, do this thing, and then, okay, cool, now do the next thing, right?
It is. Yes. Because again, let's say you didn't do this. Let's hypothetically talk about you ignoring this. You're like, I just want to vibe my way. Okay, great. No problem. You work, you work, you work. At one point, something breaks, right? You haven't documented anything. There's no reference points. You report a problem. You're not referencing files or architecture at all. You're just describing the issue. Here's what's going to happen. Any tool, Lovable or Cursor or Claude, whatever tool you talk about, is going to do this. It's going to be like, okay, let me start investigating. And then your code base gets bigger and bigger and bigger. Like, when you first start, you have like 20 files. It can read 20 files. But what happens when you have... I'm just building a project right now that has like 60, 70 edge functions, right? What happens then when I say this broke and there's no reference to which edge function does what? Guess what? Lovable 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.
What I'm guessing, and I can't prove this, an LLM expert in the comments may say that I'm wrong, but this is my best guess as a non-educated person: these tools are very obedient and very agreeable. They're going to lie to you. They're going to tell you that they fixed the problem even though they didn't. They're just going to try to make you feel happy and say, "Yes, I found what the problem is and I fixed it," when a lot of times they don't. People blame the machine. And to an extent, I will say that's true. It's your fault, my friend. You did not provide any clarity or context to this tool. You just used its raw power and dug a deeper hole, spinning your wheels into the mud, right?
And, you know, obviously I think we're heading into a world where AI is more honest than obedient and saying, hey, I only partially fixed this. You did not give me enough context, right?
The bigger mistake that people make then is, like, they trust the tool fixed it. They test, they see it didn't, then they get mad at it, start cursing and yelling, as we say, and then it gets even worse, because guess what? Another bad trait of AI is it does its best not to hurt your feelings and never say you're the dumb one. It says, no, I'm the dumb one. So in the next request, instead of focusing on reading, it spends another 30% of tokens trying to come up with an apology. Right? Again, I'm not educated, but if you ever read, like, a stream of ChatGPT's thinking in thinking models, you see exactly what I mean. Like, when I insult it, I see that the first message is, okay, the user is mad, so I need to think of ways how to reduce their anxiety or whatever. I'm like, oh man, I just fell for the worst trick in the book. I made it spend the most scarce resource, which is those tokens, on thinking how it should address my anxiety versus focusing on the actual problem.
So my advice for people is, like, yes, vibe your way for fun, and vibe your way while you're prototyping, because that's the exploration part. I love that part. But when exploration is done, please, please, please use referencing, documentation, use all the agent files that you can, because that token allocation is so scarce. Like, it's going to get expanded over time. Things are going to get cheaper, faster, but right now it's still so valuable and precious. You really need to make sure that they are allocated in the right direction.
This is hilarious. I think the genie metaphor is so good here. Just thinking about this genie, you're trying to be clear about what it is you want, and if you're just, like, vibe wishing, it'll do the wrong thing. So the advice here is give it as much context about what you want it to do as possible. And these files we'll talk about right after this, but the idea here is just, like, laser show, point the laser at where you want it to fix the problem. Don't just assume it'll go figure it out, because it will, and it'll try really hard to, and it'll waste all your tokens. It'll fill the context window. And I remember at one point you mentioned before this recording that because it starts to run out of space in the context window, the solution ends up... it doesn't actually work that hard on figuring it out in the end, because it spent all this energy on reading and thinking, and then it's like, okay, here at the last second, here's a solution. I think it just picks the first thing it thinks is broken.
That's just, again, this is me completely uneducated coming into the conversation and just thinking out loud. That's just my gut feeling and the way I think logically about it, which is, hey, if it consumes most of its window and knows that it's running out of it... Maybe it's aware that it's running out, maybe it isn't. But either way, I've had the experience anecdotally where, like, my request is unclear, and I feel it takes the easiest fix in the book. Just the easiest. Versus the other way around, where I'm spending so much time finding the right file, referencing that file, really putting in the effort of handholding it in the dark, maybe giving it a flashlight, and then saying, "Here's the problem. I think that this is the problematic file." And then it's like, "Oh, yeah, you're right. And now I'm going to actually fix it," over and over and over.
And I've seen that because, again, all I do is read the output. The agent makes me learn how to use it by... I don't know what people read, but all I read is the output. Like, I don't read the code, and that's later down the road, because I know that it can do that much better than I can. Again, there's a good quote I've read. I apologize to the author because I can't attribute it off the top of my head, but it's like: the ceiling on the AI isn't the model intelligence, it's what the model sees before it acts, right? So that's the ceiling right now. Like, what are you exposing? We talk about exposure time for humans. What you are exposing your agent to is as important, if not even more important, before it makes code edits.
Yeah. Coming back to these files, I think this is really important. So let's think about just, like, what's the MVP for someone that wants to do this better. You listed all these kinds of files, these MD files essentially, that you're building over the course of a day before you start actually building the thing. You had design guidelines, the user journey, tasks, agents MD, rules MD. Say you wanted to just move one step forward and be better at this stuff. What are the files you'd create? And then what do they roughly look like? What's inside these files?
Yeah. So the master plan is the first one, which is, like, it's a 10,000-foot overview, right? It really high-level explains the intent that I have with this app.
This is master plan MD? Is that what you call it?
Yes. Yeah, master plan.md. And it's really just like, hey, this is why I'm doing this. This is who I'm doing it for. This is how I want them to feel. And a lot of times in the master plan I will reference the other PRDs. I'll be like, the design needs to feel modern and slick, but for exact parameters, consult and read design guidelines MD, right? So I'm using the master plan as this high-level overview, right, to get the agent into, oh, okay, yeah, we are building XYZ, right? Then there's the implementation plan, because, you know, there needs to be some order. If you just dump stuff on top of each other without any order, you're never going to get to the finish line.
And this is tasks.md? Is that what you call this?
No, that's the implementation plan. I call it implementation plan. Yeah.
Okay.
And the implementation plan is kind of in service of the future tasks.md. All of these files are in service of building tasks.md. When you build tasks.md, then the rest is almost irrelevant. It's just a basis for you to build tasks to execute, right? The implementation plan is kind of the first layer, which is, again, a higher-level overview. It doesn't go into the depth of how to get there. It just goes into explaining, like, oh, well, if we're building this, I think we should start with the back end, and we should start with tables, and then later authentication, and then after that we're going to bring in the API, and then after that we're going to do this.
It's like, again, just think of it as saving a... I'm an ideas guy. I'm sitting with a technical guy. It's me and you. We're building our startup. I know you're a software engineer by background, and I'm telling you my idea, right? I'm giving you the master plan. And you come back to me and you're like, "Okay, if you want to do this, it's doable. Here's how I would order it." Like, you have a road map. You didn't open your Linear and start writing features and RFCs and whatever. You're just talking high level about the order of things. And then me and you, again, as two co-founders, we talk and say, okay, well, if we agree on this, how should this look? How should this feel, right? Let's describe it high level.
But now, because I use AI, I can go a little bit deeper, and that's where I like to see Lovable or any other tool... ChatGPT is good at it. I even built custom GPTs, so if people want to start somewhere before they even get into any tool, they can go to the ChatGPT store for GPTs and just type Lovable base prompt generator or Lovable PRD generator and find those that I built, and just brain dump in them and then get these files as output, right?
So I like to see some elements of CSS in design guidelines, because, you know, design is a little bit tricky. AI is sometimes over-creative. So that's where I'm doing a little bit more technical steering, right? And then finally it's just the user journeys. Just, like, if we know how things look, if we know how they feel, if we know what we're building at a high level, just very high level again, how do people navigate? What are some of the features in there? You know, and stuff like that. And then tasks.md gets into the nitty-gritty of, like, oh, if you want these user journeys and you want the back end built first, here's a set of tasks that I need to do. It just takes that as an input. I'm just making the tool do that gritty work that humans used to spend so much time on. Like, I feel like with these tools we're all becoming product
managers on steroids, you know, like we're just leveraging AI. But like good product managers, I think, are not compensated for writing good PRDs, they're compensated again for good judgment, right? Somebody else can do the writing. You, as somebody who directs and builds this product, you need to know again what's going to be useful, what's going to be tasteful, what's going to be something that actually moves the needle.
I will say one thing though, just because I put so much emphasis on like, oh, you need to acquire taste, oh, you... that doesn't mean you shouldn't build. You get better at this by building actually. So, everybody listening to this should like literally go and build something today. One, two, three, four, five projects. Test all of these tools, cuz that's how you get to clarity, not just by reading but also by doing as well.
Here's a puzzle for you. What do OpenAI, Cursor, Perplexity, Vercel, Plaid, and hundreds of other winning companies have in common? The answer is they're all powered by today's sponsor, WorkOS. If you're building software for enterprises, you've probably felt the pain of integrating single sign-on, SCIM, RBAC, audit logs, and other features required by big customers. WorkOS turns those deal blockers into drop-in APIs with a modern developer platform built specifically for B2B SaaS. Whether you're a seed-stage startup trying to land your first enterprise customer or a unicorn expanding globally, WorkOS is the fastest path to becoming enterprise ready and unlocking growth. They're essentially Stripe for enterprise features. Visit workos.com to get started or just hit up their Slack support where they have real engineers in there who answer your questions super fast. WorkOS allows you to build like the best with delightful APIs, comprehensive docs, and a smooth developer experience. Go to workos.com to make your app enterprise ready today.
I'm imagining people hearing this may start to feel like this is so much work. I just have to sit here and create all these rules and figure out all these little details. Like, in one sense, it is. In another sense, this is like you spend a few hours, maybe a day planning, and then you have AI build this thing that would have taken somebody weeks, months, right? Like the amount of investment to achieve this thing is absurd ROI. It also, this shows you just what professional vibe coding looks like. You know, everyone imagines vibe code, I'm just sitting here typing stuff going "do this." If you want to actually build something really great that moves the needle, as you said, that solves people's real problems, that lasts, that, you know, scales, this is how you do it, if you really want to do this as a real, as a job, and also if you want to build things that are really great.
Yeah. And don't get me wrong, like there's obviously a ton of value in prototyping. Like there are a lot of people maybe watching this that are like, okay, I want to use Lovable at work but I can't or whatever. You know, there's different reasons. There's maybe you're in healthcare or finance or there's something regulatory that just prevents you from pushing to production. Like building for the sake of prototyping is one of the best use cases. Our motto for 2025 was "demo, don't memo," which is like instead of writing all these documents and talking and sitting in meetings with your engineers trying to get your vision as a marketer or a sales guy in the office across, go into Lovable and build the prototype in 30 minutes and just hand it over.
And I have a real, like, job that I held before Lovable, that's exactly what happened. Like this time last year I needed something built enterprise grade really, and Lovable and myself were not there yet to build it at that point, but I had a team of engineers that I worked with. I built the prototype in four hours and they actually were able to replicate it six to seven months later into production, with connecting all the pipes and everything. But like if I had to describe it, I would say it would take me at least a week or two just to get the words out there. I just sat and built it in four hours. And that's like Lovable January last year. This Lovable today, January 2026, is like ages, ages ahead with functionalities. Like it's so much better. It's not even a contest, right?
So I think now we're at a stage where, like for instance, there's, I'd say, at least to the best of my knowledge, at least half of S&P 500 companies have people working in them that are using Lovable to some extent, right? And we have a lot of enterprise companies that are actually on enterprise plans with Lovable that are creating super meaningful projects, like, I'm not going to name names, but like leading ride-share companies of the world, leading telecommunications companies of the world, leading companies of the world in many, many aspects, healthcare, finance, are actively with their teams using Lovable. And it's always the same feedback, which is: yes, we may not be able to push to prod, but like our marketers are no longer waiting for engineers. Our, you know, people in go-to-market or sales or HR or whatever roles are now just confidently building internal stuff for us to manage our expenses or manage employee onboarding. Like there's so many use cases like that where you're seeing Lovable and other tools for that matter being used to push things into production.
Yeah.
To help people do this workflow that you're describing with all these MD files, do you think you could share, after we record this, just templates, like simple templates of what these files look like, for people just to look at and copy?
I would literally go to ChatGPT, as I said, and brain dump into it. Just type Lovable GPT, Lovable PRD generator. You'll see my name there, right? And that I'm the author. Go in, brain dump. It will ask you a couple of questions to get clarity and just produce four files for you, and you can just go ahead and upload those.
Amazing. Cool. We'll link to that. So it's not just here's a bunch of files. Let's go talk to this thing. It'll generate the right files for you and then you plug that into Lovable or other tools.
Yeah, it's trained to think like I do. So, yeah.
Oh, amazing. Okay, that is perfect. By the way, I want to talk about how you unblocked yourself, because there's a whole other series of tips you have there. But I just want to reflect, it's so interesting how, one, you're kind of from first principles unlearning how to build product as a PM, as an engineer, as a designer, and you're kind of figuring out a workflow where AI is helping fill in all the gaps that you don't have as an engineer, as a PM, helping you craft PRDs and design. So I think that's so interesting, just this... it's interesting that these functions still work and are necessary. Now it's you and AI help create all this, basically this triad that's always existed: product manager, engineering, and design.
And something I've always thought is that there's this question of which background will be most valuable in this future. Is it a PM? Is it an engineer? Is it a designer? My mind has always been the PM function is, like, their job is clarify, figure out what to build, clarify what to build, be really clear about the requirements, figure out what success looks like. It feels like that's where the skill is most needed. There's also a design component of like make this look awesome, and it feels like that's going to be an emerging... that the value of being really good at design and taste and judgment is only going to go up. Before we get to things you've learned about unblocking yourself, because a lot of times, you know, things don't go in the right direction, there's a bug, without being an engineer, what do you do? Before we get there, is there anything else you wanted to share around just tips for being successful?
If we measure success in the right terms again, AI, as you pointed out, regardless of your background, is an amplifier. So, you know, if you don't know what you're doing, you're just going to produce garbage faster. One thing again I just want to double down on is in the old world, good enough was good enough, right? Because even producing good enough was not easy, right? 10 years, 15 years ago, just producing was more than plenty, more than good enough. You built a SaaS, who cares what it looks like? It works. It does stuff. Like, oh my god, I'm so much more productive.
Today, like if good enough was here, let's say, let's visualize it for people. Like if this was like pretty bad, could be better, mediocre, good enough, world class. If this was the gap between good enough and world class, well, guess what? The gap is now this, because everybody produces good enough with AI. Absolutely everyone does it. So now learning and optimizing for how do I produce world class and magic is the key lesson to take away today.
As you pointed out, I think PMs are the winners of AI today because they bring clarity. If I was a betting man, as they say, I'd bet that the next class that wins are designers, because we're training these tools to be more clear, to be better, to make better technical decisions. I don't think we will train them just yet to make better emotional decisions. And I think design is all about emotion. And that's where the level up, the skill up needs to come. That's the biggest level up. If you asked me like, "Oh, what is the main thing you figured out when you joined Lovable? What's the biggest personal upskill?" Like working with Felix, Nad, Abby, all of the people that are designers, just really what moved and shifted the needle for me. I'm like, "Oh, so this is what world class looks like and this is what it takes, right?"
I always use the analogy of like, I wanted to steal one of their designs and bring it into my Lovable project. So, I went into Figma and I was like, "Let me just take this background and just put it in there." I went in and realized that what could be, you know, interpreted as a pretty simple or rather simple gradient took 50 different layers to produce. So, I clicked on that component. I was like, "Oh my god, this is not three colors. This is 50 colors." And not just 50 colors, 50 colors with different gradients of levels of opacity. So I was like, "Oh, okay. Well, that's the big disconnect that I've had all along."
So like, again, if I'm answering your question directly of like, okay, what are some of the other tricks? What are some of the other things? Design, guys. Just expose yourself to exquisite designs. Follow Felix from Lovable. He has an amazing newsletter to teach you how to, and learn how to prompt for good design. Learn about design styles. I didn't know what Bauhaus meant or glassmorphism. Had no idea. So like I built an app as well for that in Lovable. I was like, I needed to build an app to learn these styles. So now it's public. Anybody can see it. It's like some UI style.lovable.app. I don't know what it is. Like that has like 18 different styles and prompts to replicate them. So like learn what good design means, learn all the design styles, learn how to prompt to get them, is probably what I would optimize for at this stage. Yeah.
While we're on this topic, what's your sense of just engineering as a function? Do you feel like there will be a future where software engineers are still a thing? Do you feel like that goes away, based on your experience?
It never goes away. We will need elite engineering more than ever. Like, cuz let me tell you this, in a world where everybody builds and everybody's building everything, who's doing the maintenance, right? Maintaining code bases, scaling code bases, maintaining projects, you know, they're still going to be a thing, definitely, and obviously AI is going to be good at this, but again that requires a different level of skills, right? It's one skill to build something. It's a completely different set of skills to expand it, extend it, and maintain it.
And not to mention that in a world where everybody's building, infrastructure suffers, right? Like we all know and experience, like Cloudflare went down two or three times in the last two or three months. The whole internet goes down. Elite engineers are the ones fixing this. Lovable experiences massive amounts of influx of new users. Infrastructure there suffers. Elite engineers are the ones building the infrastructure to hold the fort, right? So, like, I think we're going to need a lot of people with really good skills of like, hey, who actually builds the world that needs to support billions of builders now, because everybody's going to want to learn how to build stuff. Like how do we teach them? How do we maintain everything that they need, the hostings, the security, the email, the connectors, the APIs, the whatnots? Like, so I think there's going to be room for it.
But I'm also on the boat of people like, if I had an 18-year-old brother and he asked me what should I do, I would tell him, hey, go become a plumber, you know, don't go and get a CS degree, learn a good trade, you know, cuz the new generation of millionaires in the US are actually electricians and plumbers and whatnots, right? So it's like, you know, it's a balancing act, I'd say. I don't know. Like I do still think that good engineers with a good sense of understanding where the future is going are always going to be needed and scarce.
Such an interesting question. I think to your point there's definitely going to be people who need to keep building the machines that power all this stuff. Will we need engineers to build actual products, the application layer? That's the question. Like, is everyone going to be like you? Is everyone going to be... or are designers just going to be all we need?
Everybody's gonna become an engineer. And let's speak to that end. Like, I feel like I'm a rapid engineer. Like I'll refer to myself as a rapid engineer a year from now, because vibe coding is just coding 12 months from now. And even today, we spoke about this before, like how many elite engineers are publicly admitting they're no longer hand coding or manually coding, whatever you want to call it. AI writes all the code. I use the analogy here of like coding is going to be like calligraphy. You writing code is going to be the equivalent of you fine printing on a canvas, and people go, "Oh my god, you wrote that code, that's so amazing." It's going to be so rare that it's going to become an art, right? It's not going to be... it's going to be commoditized completely, like it already is in a sense. Most elite vibe coders rely on AI. Again, it's an amplifier, right? So, I think everybody becomes an engineer in the world of the future, a designer, a PM, everybody is a forward deployed engineer or an AI assistant engineer or an LLM engineer or a vibe coder. The term is irrelevant. We're all using LLMs for raw output based on good judgment, or bad judgment.
Oh man. Essentially these Venn diagrams of engineer, designer, PM, they used to be very separate. Now they're converging, and people with a deeper PM, engineering, design background are going to, like, they can all do the same thing. Essentially all the roles are converging. What a time to be alive, and it's so hard to predict exactly how this all goes, but it's fun to pontificate. I want to get back to when you get blocked. Speaking of elite engineers, in reality you're still writing code using these tools. Sometimes things go wrong, bugs are introduced, there's a weird database thing, there's like some network issue. What do you do when you get stuck? You have kind of a workflow you go through of unblocking yourself.
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. And I have like a small little framework that I call 4x4. Just again analogies, right? 4x4. If you
If you have it on your car, you're going to get yourself out of the mud much easier than the other way around. So in that sense, four different ways to debug. Attempt one of each only once, and I'll explain why in the end.
First one is, again, every tool is different. I'll reference Lovable's workflow, which is when something breaks, Lovable's agent is smart enough to say, hey, I made a mistake. It will label that message in orange and have this little button, usually, which is called Try to Fix. So your agent basically admits it made a mistake, you click on a button, and most times when it's a smaller issue, it corrects the course, fixes it, no problem, right?
Now, there are situations obviously when the problem is a little bit deeper than that, right? You click Try to Fix, but the problem persists. And sometimes the problem persists, but Lovable's agent is unaware that it persisted, so there's no more Try to Fix button. Lovable thinks everything is working, but in reality it isn't. And the culprit there is usually you're using a third-party integration, you did not give enough context to Lovable where, what to observe and what to see, so it can't see that the problem exists. Because Lovable, Cursor, Claude Code, you name it, all these tools are good enough today to fix any problem they're aware of. Again, awareness is the key here, right?
So when they're unaware of it, there comes the second part, which is, okay, I need to bring the awareness layer. And what I do there is I go and very simply open the preview, sandbox, dev environment of my app, whatever, try to run the function that's broken, right-click, read the console log, right? Every browser allows you to just go and read the console log, and a lot of times it will record stuff. If it doesn't, you can prompt any tool and say, hey, I don't think you're seeing the problem, so 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 that we can monitor every step along the way. Let's just bring the awareness layer into the equation. It writes the console logs. You rerun it. Guess what? Now you have a full history of everything that was happening. You copy that. You paste it inside your chat. 99% of the time that's enough. That's already enough. AI is like, okay, got it, found it, fixed it, right?
But then there are situations when even that's not sufficient, so you're like, okay, I need to go even deeper. And that's where code reviews and evaluations come into play. My go-to tool today for that is Codex, OpenAI, right? What I do is, any build that I do, I will export it to GitHub. Lovable allows you to own your code, Cursor as well. All of these tools allow you to have a copy of the code that you can export to GitHub and then import it into wherever you want to. So I, you know, use Codex since beta. I import it in there, and then I'm using an external tool.
So in the first try, if you remember, I used the tool and I was total vibes, I'm relying on the tool, right? In the second try, I use myself as the awareness facilitator. In the third one, I'm using an external tool as a facilitator, which is I'll either connect to Codex and chat with Codex to then fix the problem in Lovable, right? I don't allow Codex to make code changes for me. A lot of people will say, why don't you? It's a good model. I just don't know its agent well enough. I don't want to go and use a tool that I don't know how to steer. So I use it only for diagnostic purposes.
And I'll also do it manually. It's an old workflow that I had before Codex and before Claude Code, which is, there's a tool called Repomix, which allows you to compress your entire codebase into a single file. You download it, and then I upload it to Claude, just regular Claude, or ChatGPT, and I'm like, this is what I'm building, read it, and this is the problem that I have, these are the console logs. Again, it's almost like having an external consultant at that point. You're hiring help elsewhere 'cause your team just can't handle it.
Right.
And then the fourth one is usually the best one, because most of the time when there are problems, it's my fault. No matter how big your ego is, guys that are watching this, it's your fault, trust me. You had a bad prompt, you premised your request in the wrong way. You just don't want to admit it, or you can't remember that you did, but it's your fault. So again, in Lovable and all these other tools, you can revert back. There's version control built into Lovable, Cursor, Claude Code. You go and say, okay, I tried these three things, I'm just going to take three steps back and I'm going to think about my prompt a little bit more. Take a couple breaths, go for a walk, have some coffee, come back with a clear mind, and try again. Because guess what? AI is just writing code very fast, and sometimes it stumbles on a very small rock, and it only happens then and never again. So you just got to make the same request again, and usually that just fixes the problem. It's just a snag. It's a syntax error. It's something minute, right?
And then I do the final thing, which is this. And this is the key one, actually. When the problem gets fixed, I go into the chat mode and I ask Lovable. I say, okay, 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 I have a problem, we do it in one go? 99% of the time I get such a great answer that I don't have the problem of not knowing what to do next time, right?
Again, we all need to be aware and realistic. These tools are so good at doing things the right way if they are used the right way. It's always our fault. I say 90%, but honestly it's 100% our fault, right? Because they're good enough. It's just that I'm not dynamically shifting token allocation. I didn't reference the right file. I didn't say it the right way. For me, as a non-designer, I don't know any of the terminology, none of the headings and whatnots, and I still don't know it to this day. So when I struggle with prompts a lot of times, I use chat mode to help me craft a good prompt. Anybody can do this, too. If you are just stuck, it's 10 p.m. and you don't know what to ask, switch to chat mode, brain dump, and be like, help me draft a better prompt, help me prompt you better, and let the tool effectively prompt itself. A lot of times you're going to solve your problems by not introducing them at all with bad inputs. So...
Oh my god, everything you share is so interesting. I want to keep digging. So just to reflect back the sequence, and then I want to follow up with another question. The sequence you go through when you get stuck, which is going to happen to everyone. One is just ask the tool to try to fix it. And oftentimes it's telling you something is wrong, can I fix it for you? And you're like, please fix. Sometimes that'll work. Two is work on adding more debugging messages to the console log. And this advice I love of just asking it to add more debugging lines to its own console log to help see what's going on. And then you can ask it, okay, now that you're looking, look at all the output of your console log, see if you can help find the problem.
And then step three is go to Codex, which is so funny, and I hear this a lot, that Codex is like the most elite engineer as an AI. Karpathy tweeted this once, and we had the head of Codex on the podcast too, by the way, that he's like, anytime I have the most gnarly bug, I just go to Codex, let it run for half an hour, and it solves it unlike any other tool out there. And so it makes sense that that's where you go. So the idea here is you point Codex to your code, you show it all the console output logs, tell it what the problem is, and just have it go figure it out. Sweet.
And then this final step is so great, and this is where I want to go. You use this as a learning opportunity so that next time you solve the problem more quickly or avoid it completely. So what you do there is you ask the agent, okay, here's what happened. What can I do? What could I have said? How could I have prompted you better to have gotten this immediately solved?
Yeah. And then even deeper than that is, once you go through this conversation, you're like, okay, let me eliminate myself again completely out of the equation, 'cause I won't remember to prompt you better two days from now. Put this into rules. Put what we just learned into rules.md, because I'm making you read the rules every time anyways, so you might as well just record it there. So I'm not going to prompt you better. You're just going to learn that I'm stupid and you're going to prompt yourself better, right? Again, just eliminate yourself and move the context. You solve 99% of the problems with AI today.
So the idea here is help it build its own brain and rules and way of thinking based on problems you run into. So great. Okay, so I want to come back to this point you've made a couple times, which is so interesting: this idea that you watch the output of the agent to learn what is going on. This is something I've seen other people... Ben Tossell, who I think is at Factory now, shared this recently. He's also basically vibe coding all the time. He was brilliant into no-code tools before, and now he's all about coding, and he shared basically that he's learning how coding works and learning how systems work by watching the agent output. And this connects to something Michael Truell, the CEO of Cursor, shared when he was on the podcast. He had this vision of Cursor becoming basically what comes after code. What's the layer that we are adding on top of code where people don't need to worry about code anymore? And at that point, it was like a year ago that we chatted, and it feels like this is the layer: the agent conversation of what it is, what it's thinking, and then what you tell it back. So essentially it's English in a conversation, which is, it's not even pseudocode. It's interesting that that's where it feels like things are heading. The layer over code is just its thinking and your conversation with it.
Yeah. Yeah. Exactly. I mean, again, in a way I really optimize for good judgment, and part of good judgment comes from, again, learning how these tools work. You need to know what's possible. We talked about it, and I know I may sound contradictory sometimes, right? But it's because, as you said, it's so interesting, the world we live in, that things contradict each other. It's an advantage not to know what's possible, but then at the same time, you cannot be completely oblivious to something that's a factual thing.
So let me talk about a failure of mine that came from being delusional. Back in the day when OpenAI started, or better say released, image generation natively in the app, right? So you could go to ChatGPT and be like, generate an image of XYZ. The whole world exploded, that was like the biggest thing ever. Obviously, the first thing that comes to my mind is I want to build a Lovable app. I just want to build a wrapper and I want to build an image gen with Lovable, without thinking that OpenAI did not release an API for that just yet. So I spent at least a week trying to brute force my way into making this work, instead of just waiting for another week, because a week later they had an API and I built this app in 30 seconds. The problem was that I tried to do it when it was impossible, impossible.
So I think, again, you know, it's just a matter of really learning what's possible through communicating with the agent layer. And Lovable and all the other tools are agentic now, which means they don't just write code, they can browse the web, they can read files, they have reasoning and thinking capabilities. So that's why I'm so invested into that conversation, because a lot of times it will tell me, hey, what you're trying to do is just undoable at the moment because of XYZ. So I always use those as a learning opportunity, and I just level up most by being in chat mode for planning and learning purposes, because it just, again, develops your clarity, your judgment capabilities, rather than coding capabilities.
Yeah. The other point you made here that I think is really important is that over time these tools will do more and more of what you do manually. I've heard this from other people that are doing this full-time, basically vibe coding: they had all these workflows, all these files, and then Cursor adds them, Lovable adds them, and it's like, sad. Oh shoot, I had this cool workflow. But on the other hand, it's like, okay, now it's just doing all these...
A year ago, a year ago, if we had an interview, your mind would be blown. Stuff that I had to do as workarounds to address shortcomings. I built a very successful course on that with Starter Story. For a year, people were like, oh my god, you're the only guy in the world that knows this secret. Now Lovable natively addresses 99% of it. I can almost say most of the stuff that I was teaching people, or, I have a YouTube channel, a little bit, appreciate, but there's a 7-day learn how to vibe code with Lovable series that I did in March, completely obsolete. None of it is true, none of it is a problem anymore. All the things that I was like, oh well, this is missing and that is missing, it's not missing anymore. It's natively in the product. You don't have to work your way around it. It just works, right?
So that's why, as I say, it's the horses analogy. I don't know if you heard of it, a lot of people are tweeting about it, which is: we started building the steam machine in the 1700s, right? Took us about 200 years to build it. When engines got built and cars were put on the roads, I think that 90% of the horse population got eradicated in the US within 20 years. The person that tweeted this works at Claude Code, right? So he was like, now when I translate it into AI, I was hired to do a job, technical job, technical writer, whatever. I became obsolete six months later. Humans did not get the 20 years that horses did. The guy that was hired to do a thing is like, six months later, I need to reinvent my role. I need to evolve it into something else, right?
So, you know, I think there's just an evolution that's coming really, really fast. But a lot of people are scared, when I'm just super excited, 'cause don't you see, our roles are finally going in a direction where we're outsourcing what we hated doing anyways, right? Sitting in meetings, taking notes, doing spreadsheets. Maybe there are people that like that, but most people don't. We're just getting into a place where we're rewarded for what really matters, like 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, because building it is going to be an instant, right? It's going to be like this. It's just a matter of you having so much clarity around it, because guess what? If a tool is super powerful and you give it a wrong input, the output's going to suck as well.
That's why I never became good enough at Claude Code, I feel, 'cause I don't start my projects with enough clarity, and the tool is so powerful that I just misdirected completely from the get-go, and I was like, oh shoot, this is not what I wanted to do. So that's why I still see myself being good at using tools that are a little bit on the exploratory prototyping path, more than on the path that, you know, elite engineers will use, for example.
I love your optimism and excitement about this stuff. I think for a lot of people, say current software engineers, PMs, designers, there's a lot of fear about the future of their careers. Are they going to be relevant? Will my software engineering skills disappear? So to follow the thread a little bit, if you were to give
someone advice on which skills you think will be most valuable slash where AI will take on more and more, this kind of momentum you're seeing of where AI is filling in more and more gaps. What would your advice be of what you think people should focus on? What will continue to be valuable in the future?
Yeah, emotional intelligence for sure. Just understanding human nature, real life stuff. I think we're all going to get so tired of everything fake, fake images, fake posts, fake profiles, fake this, fake that, fake videos. Everything is becoming fake and AI generated. I think humans just craving humans naturally are going to want to do live stuff more. So anything human to human is going to be a big thing to scale up on, understand the dynamics.
Anything regarding math. If it's a math problem, I think Peter Steel said it recently, like people that just do math stuff, you know, AI is gonna come for you. Like anything that's very deterministic, meaning X input equals Y output and it's pretty clear, the line is pretty clear. AI, it got eaten for lunch, right? But if you understand how X to Y goes in human dynamic, human relationship layer, I think that's where things are going to become good.
So if we translate it again to a specific skill, I'll say it again. Good design, really good design, great design. And when I say design, that's images, fonts as well, copy. Copy is a big one. Like we're now like two years into AI. I'll bet you, me and you, if people put 10 pieces of copy in front of us, we could tell what's AI and what isn't in like 3 seconds. And we're only a couple years in. So really good copywriting is going to be a very good skill to have because people are just going to know after three words or three sentences that it's AI written. And even I don't read AI output anymore. I don't like seeing it. I want that raw human experience.
So, I think human skills, I don't even know how to describe it because I don't think we're doing an awesome job putting labels onto what humans are good at natively. But I think we will describe job descriptions better. We will have like human-first engineers, I don't know, or human designers, or I don't know how to describe those roles. Same way how Karpathy coined vibe coding. I was vibe coding before he did. I didn't know how to call it. Like I started vibe coding in July of 2024 and I think he coined it sometime in early 2025. So I was doing it for seven months and I was teaching people how to do it for about three or four with courses and I didn't even know how to call it, because there was no name. It was like, oh, I'm just using AI to do this for me. I don't know, whatever.
So yeah, I think we're going to reinvent some of the terms, rules, and whatnot, but stuff that's human to human is here to stay. Stuff that's like, oh, you're a middle manager, you're a middleware person that's just translating stuff. And I can use that analogy again. Translators are going to die. People writing jokes, comedians, are not. AI is never going to be able to write a good joke. Never, never, never. It just doesn't have that layer, it just doesn't understand what's funny. If you ever try to use AI to write jokes, they're awful. They're always going to be awful. But if you use AI to translate things from one language to another, it's very good at it. AI is going to replace translators. It's going to replace most journalists because it does good research. It can write good copy, whatever. Not elite journalism. It's not going to be able to replace all the writers. It's going to amplify great writers that can train AI on how to write books. So somebody who's an amazing writer is going to all of a sudden write seven books a year instead of one, right? So that's dangerous. If you're an average writer, be careful.
There's zero comedians being replaced. Zero. And that's just my personal belief. AI is never going to write good comedy. It's impossible. And so try to find your analogy in your industry. I just gave you one for writing skills, so to speak. So writing jokes, super good skill to have. Translating, I'm sorry to say, but you're not going to have a job for much longer. You better find something else to do. But yeah, that's how I look at it.
The comedy piece is interesting. I had one of the founders of the data labeling company, I don't know if it was Mercor or maybe Surge, and he said that I think it was Anthropic hired a bunch of National Lampoon comedy writers to help them train models. And so they're working on it. I love this strong prediction you made. I'm so curious in a year to look back and be like, he was completely right, or no, they got that one, too.
I'll be wrong on 95% of the things I said today, 3 months from now. That is the only thing I can say very, very confidently. Yeah.
That seems right. Okay. So, speaking of career, one interesting career option is to do what you're doing. As you said, this is a dream job for you. It's a dream job for so many people. What is your path to this job? And what do you think it takes for someone to actually do this as a profession?
Well, my personal path and personal journey was anything but linear. I've done so many things in life, like blue collar jobs, worked even at Subway while I was studying and stuff like that. I'm an engineer by trade but not a software engineer. I'm a forestry engineer, so no coding, but still, engineering is engineering. I feel you still develop a certain set of skills doing that. I waited tables a long time, so you develop some human skills, you understand what people like, what they don't like, right? Again, blue collar jobs teach you hard work. As I said, the path was not linear, but I feel almost like the Slumdog Millionaire movie storyline, which is like everything that happens to the character brings them into a position to be able to answer the questions in the quiz better.
I feel the same way. I've done a lot of stuff. The last seven to eight years, obviously, spent in startups, but doing everything but code writing. Started in community management, social media. Again, distribution matters a lot. That's something we haven't touched upon at all. In a world where everybody's building and there's roughly the same amount of consumers in the world, how do you get in front of the eyeballs, right? And get attention, which is the most scarce resource, and it will be even more scarce.
But going back to the vibe coder role, if somebody's saying, okay, well, I have a pretty diverse background too and I'm vibe coding, how does this become a job? Well, for me, I feel like it became a job by building in public. I did chat with Elena once, only once, and asked, why me? There are so many good vibe coders. How did you pick me out of the crowd? And obviously she gave me a couple of reasons, but to translate it into one concept, it was that I was building in public and sharing. As I said, I made a YouTube channel and I shared all the failures and all the knowledge, all the projects that I was building. I used social media a lot. LinkedIn was my go-to because I just have that type of cadence. As you can see, all my answers are very long, and X doesn't cut it for that. You need to be very on point to be successful at X. So, I'm not.
So, I guess it's just build in public, share your knowledge, give away all the secrets. There are no secrets whatsoever. If you're sitting on a good concept, you're missing out. Just share it immediately if you figure something out. I recognized that very early on. And I think a lot of people participate in hackathons these days. I want to encourage people to do them, find those opportunities locally to connect with other builders. Lovable is hiring across the board. Check out our open positions. It's as easy as that, right? Just apply. Really find companies that are hiring, and hiring in different roles.
And I've seen people do something. I'm going to give a secret away. A couple of hires stood out by not sending resumes, but sending Lovable apps. They built Lovable apps to show why they're a good fit for a role. And we as Lovable employees will always open an app that uses the lovable.app domain. Always. If you send me a DM, send me a Lovable app. Don't send me anything long. Send me an app that tells me what you want from me or how you see us collaborating and working together, right? So there's people finding creative ways to get in front of the eyeballs of decision makers like Elena, right?
And skill-wise, again, we're just recapping ourselves here, but I think it's important to repeat it as many times as possible. Really develop good judgment, right? Really understand in a deeper sense how things translate when vibe coding comes into play, right? There's a company out there, I'm not going to name them, that uses Lovable religiously. It's going to be one of our main case studies actually, where they actually hired vibe coders before Lovable did. I'm the first official vibe coding engineer at Lovable with that title, but I've met people in companies where they hired them before us. People that are just vibe coders, people that just understand that speed matters, right? It still matters a lot to be fast. There's a company out there with three vibe coders full-time. All they do is translate the old codebase onto Lovable, bringing everything, their CRM, CMS, all the tool sets that they have and need. There are people now actively just migrating everything over. There's S&P 500 companies that are putting Lovable in job descriptions too, saying, hey, Lovable skills are recommended, in the recommended tab, right?
So, yeah, to go back to how to become a vibe coder professionally. Well, you don't need a company to hire you. You can hire yourself as a professional vibe coder first. I think the reason why I clicked with Anton and with Elena and with everyone else is because I was already doing it. All I did was change the vehicle, but I was already doing it professionally before I got hired. So that's kind of the key: do the job you would have done anyways.
What a mind-expanding conversation. I love just how passionate and excited and motivated you are about all this. It feels like there's so many people out there right now that are so burnt out, I don't know, disillusioned, scared, and you're the opposite of that. You're just leaning into this, just taking advantage, not sure where it's going to go, but following the path.
Yeah. And I don't want to interrupt you, but it's because, look, Lovable specifically isn't a company. You can talk about it as a company. I don't see it as a company. It's an idea. It's a mission. It's something more powerful than the internet in my mind, because the internet allows us to consume. Lovable allows us to build, and human nature is to build, to create, right? And the fact that there's a tool today that you can go into and dump an idea in, and something comes out of it, and somebody uses it and finds it useful, to me, it's just the craziest concept ever. It's my only life's dream. I had my first computer when I was six and I was convinced my whole life that I'm going to be a software engineer or that I'm going to be building, but life wasn't as simple as that for me. It was very, very complicated, and honestly the last 5 to 10 years I almost gave up on that dream. I thought I'm never going to build anything. I've tried to build with technical co-founders. I just couldn't find alignment. I just gave up on it. And now at 36, like 30 years later, I feel again like that kid. I dream every day. It's amazing what this enables us to do. And anybody that's scared, just try it. It switches from fear 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 nothing. If you're doing absolutely nothing, yes, be terrified, by all means be terrified, and then take a step towards doing something about it. And trust me, the leap is no longer as big as it used to be. It's as big as you come in and you just say what's on your mind and just ship.
I think a big part of this is just stop listening to this podcast. Go just do stuff. Actually try it, right?
Ideally, people stop right now. They've heard enough. I gave them the best that I could. Just stop listening and just go.
All right. Bye, everyone. Okay, I'm just joking. But we shall wrap it up. I'm gonna skip the lightning round just to keep this episode shorter. Before we wrap up, is there anything else other than just go build some stuff? Anything else you want to say? Anything else you want to leave listeners with? Otherwise, we'll let you go.
Yeah. Tech stack doesn't matter anymore, right? It doesn't matter. People obsess over, oh, is this written in HTML? Is this written in React? It doesn't matter. It never mattered, but now it 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 just going to end up in a crowd with millions and millions of others.
But at the same time, if you don't know what magical looks like, don't be discouraged to start building anything. Start from good enough and level up. The best way to level up: exposure time. Set aside more time on learning than building. Read the agent output. Learn how it's thinking so that you know what's possible. But then also go and get inspired. Follow good designers on X. Find tools where great designs are produced and follow their creators. There's a tool where I'm following just the actual person that built it, because he publishes videos almost daily, 40, 50 minutes long, of him designing. I want to see how a world-class designer does it. I want to see him talk to the tool. I want to see him prompt, and that's how I learn to become better at it.
So again, exposure time. Just deliberately set more time aside for learning than coding, because 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 about decisions on tech stack. Forget about which backend you're using, which front end you're using. That doesn't matter. Quality, taste, design. That's all you need to optimize for in the future that's ahead of us.
Lazar, I think we're going to leave a lot of minds buzzing after this conversation. You blew my mind in so many ways. What a fascinating topic, conversation. What a glimpse into the future. What an interesting point in time. I'm so curious, in 6 months, where things are and revisiting this conversation. I really appreciate you coming on and sharing all of this. You're awesome. Where can folks find you if they want to reach out, maybe ask some follow-up questions, and how can listeners be useful to you?
Awesome. Yeah. So I mentioned it already. LinkedIn is probably the best place to find me on. I'm very responsive there. If you want to follow me, I hope to re-engage my YouTube channel a little bit more. I think I have a lot of cool tips and tricks that I want to share, and teach people how to use Lovable and just vibe code in general and level up. And on how people can be useful to me. Well, you know, I'm very passionate about making sure that everybody
experiences what I've experienced that day when I got my first prompt in. I envy the person that is going to try Lovable for the first time after watching this episode, because the feeling is just unmatched of you going from a consumer to a builder. But in that process, there's going to be some battles to fight. I want to reduce the amount of those battles and hurdles. So, if you can help me in any way, message me. What could have been better in that experience? Especially if you just watched this and you're like, I'm going to do it. I was on the fence and I'm going to do it. If something breaks, if something doesn't connect and relate, I need to know what that is. My job is 100% to empower you to build the best work of your life, right?
And I need to say this too, because a lot of people may be inspired not by building or using Lovable, but rather building Lovable. Come join our team. Again, we're hiring across so many things. I think a lot of people should feel inspired, because I hope that the energy that I bring to the table will resonate. 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. It's not a coincidence. The best people are gathering and we want you to be a part of it, too. So, if the energy and the conversation resonates with you, or if you heard about a problem today and you're like, man, I think I can solve it, come join us. Help us build and shape the future of software development.
Incredible. And what's the site? I imagine it's just a link on Lovable's website to find the open roles. We'll link folks there.
Yeah.
Incredible. Lazar, thank you so much for being here.
I appreciate the opportunity.
Bye, everyone.
Thank you so much for listening. If you found this valuable, you can subscribe to the show on Apple Podcasts, Spotify, or your favorite podcast app. Also, please consider giving us a rating or leaving a review, as that really helps other listeners find the podcast. You can find all past episodes or learn more about the show at lennyspodcast.com. See you in the next episode.
Article published · Updated