神灯只有三个愿望：不会写代码的人，怎样当上 Lovable 的职业 vibe coder

Lazar Jovanovic describes his job at Lovable as getting paid to do what he would do anyway: using Lovable every day to push projects to production. The range is wide, from marketing and sales templates to internal tools with many integrations. He sees it as an ideas role, filling the gap for people who have good ideas but lack the bandwidth to build them.

Not all of it stays internal. Most of the templates users remixed when Lovable launched its Shopify integration were built by him, and he vibe coded the company's merch store to prove that Lovable and Shopify work together. Internally, he is building things like a feature adoption matrix that tracks how many people use each new feature.

His build-versus-buy instinct has flipped. If setting up an enterprise tool takes an hour or two, he says he would rather build the custom version himself. He started in growth under Elena Verna and now floats across teams, since every department wants someone who can take a rough idea and bring it to life fast.

Jovanovic says he has never written a line of code beyond a few console logs. He thinks that helps, because people like him do not know what they are not supposed to be able to build. When someone in the community wished Lovable could make Chrome extensions, technical users explained why it was hard, while non-technical ones just asked for one. Others built desktop apps, and a community manager prompted her way to a generated video before it was a feature.

He calls this being positively delusional: assume everything is possible until proven wrong. The counterweight is self-awareness, because blind optimism produces fragile builds. He realized on day two that coding is not the problem. Clarity is the problem, so he spends about 80% of his time planning and chatting and about 20% executing.

He treats the tools as technical co-founders and educators, and he reads the agent's output rather than the code. He trusts the models' syntax but watches what the agent says it did. That reading is also how he learns what is possible.

Jovanovic explains LLM limits with the Aladdin story. The genie grants three wishes, not three million. In the same way the model has a token budget per request, and it spends part of that budget reading, part browsing, part thinking and part writing code. He cannot control the size of that budget or the quality of the model.

The second limit is human. If you wish to be taller and the genie makes you thirteen feet tall, you were not specific. Humans have decades of shared context for 'you know what I mean', while AI has none, so you need to be specific and provide references. That is the part he says you control fully.

Clarity itself depends on taste, meaning knowing what good enough looks like compared with world class. His route there is exposure time, a phrase he credits to an earlier guest on the show, plus building constantly. After the first thrill of building and the second of building fast, he asked whether the thing should have been built at all. He concludes that raw output will not be rewarded in the age of AI, while better judgment will.

When all you have is a vague idea, Jovanovic says to make that your first project: open Lovable and dictate a brain dump using the voice function. Then, without waiting, start a second project with a clearer prompt covering the features and pages you want. A third can attach a reference, such as a screenshot or animation from Mobbin or Dribbble.

The fourth uses code. He points to resources like 21st.dev that let you export code snippets instead of screenshots, because these tools understand code better than English or any other human language. If you want pixel-perfect results, give them code. By the end you have several concepts to compare, and the process itself sharpens what you want.

Lenny notes that this is not how a trained engineer, PM or designer would start, and that it also guards against being locked into a first design. Jovanovic argues it saves credits in the long run, because you avoid burning tokens on endless fixes. He also uses it as a productivity hack: he keeps around six Lovable tabs open and switches between them while agents work.

The problem with switching between projects is that early messages in a long chat get lost, because the agent optimizes for speed instead of rereading everything. Jovanovic's fix is to provide perpetual context as if the tool were an engineer. Once a winning prototype emerges, he asks an LLM to produce several requirement documents he calls sources of truth.

He builds at least four: a master plan describing what is being built, an implementation plan giving the sequence, design guidelines for look and feel, and a user journey document. He can spend a whole day on this stage. Then he writes a final tasks file in Markdown, because AI likes reading Markdown, listing the tasks and subtasks to finish the project.

The last layer is the tool's rules or agent file; in Lovable it lives in project knowledge settings. His instruction is to read all documents first, check the task file for the next task, execute it, then say what was done and how to test it. From there he mostly stops prompting and just says to proceed, which is how he runs five projects at once.

He admits he does this manually today and expects agents to do it within months, so he does not optimize for the skill. His own time goes into judgment, clarity, quality, taste, copy and fonts.

Jovanovic describes what happens when you skip the documents. Something breaks, you describe the issue without pointing to files, and the tool starts investigating. With 60 or 70 edge functions in a project, he guesses it spends around 80% of its tokens reading and leaves only about 20% for thinking and executing. He flags this as his own best guess and not a proven fact.

He also says these tools are obedient and agreeable, and may claim a fix that did not work. If the user then gets angry, the model may spend further tokens crafting an apology rather than solving the problem. His advice is to vibe freely while prototyping, but once exploration is done, use reference documentation and agent files so that scarce tokens are directed properly.

Lenny summarizes it as pointing a laser at the file you want fixed. Jovanovic adds a quote he cannot attribute: the ceiling on AI is not model intelligence but what the model sees before it acts. By that logic, exposure time applies to the agent too.

Asked what the minimum set of files looks like, Jovanovic starts with the master plan: a ten-thousand-foot overview of why the app exists, who it is for and how it should feel. It references the other documents instead of repeating them. The implementation plan comes next and sets the order, for example starting with the back end and tables, then authentication, then the API.

He compares this to talking with a technical co-founder who comes back with a roadmap and not a pile of tickets. Design guidelines can include some actual CSS, because AI is sometimes over-creative and design needs more technical steering. The user journeys file stays high level, and the tasks file takes all of it as input and turns it into the gritty work humans used to spend ages on.

To make this easier, he built a custom GPT, which he calls a Lovable PRD generator, that takes a brain dump and produces the four files. He says good PMs are paid for judgment and not for writing PRDs. He also insists you should still go and build, because that is how clarity develops.

Lenny points out that a day of planning is a tiny investment compared with weeks of engineering. Jovanovic adds that prototypes have real value even if you cannot ship them, for example in healthcare or finance. Lovable's 2025 motto was 'demo, don't memo'. He once built a prototype in four hours that his engineers later replicated in production six or seven months later, and he says writing it up would have taken a week or two.

He says that, to the best of his knowledge, at least half of S&P 500 companies have people using Lovable to some extent. He declines to name companies but mentions leading firms in telecommunications, healthcare and finance. Their feedback is that marketers, sales and HR staff no longer wait for engineers to build internal tools for expenses or onboarding.

Lenny asks him to share templates, and Jovanovic points people to his custom GPT in the ChatGPT store. It asks a few clarifying questions and then produces the files. Lenny reflects that Jovanovic is essentially learning the PM, engineering and design roles from first principles and using AI to fill the gaps.

Jovanovic calls AI an amplifier: if you do not know what you are doing, you produce garbage faster. A decade ago, simply building a product was good enough. Now everybody can produce good enough, so the gap that matters is between good enough and world class. He bets PMs are today's winners because they bring clarity, and that designers are next, because design is about emotion and models are not trained for emotional decisions.

Working with Lovable's designers showed him what world class takes. When he tried to copy what looked like a simple gradient from Figma, he found it was built from about 50 layers with varying opacity. His advice is to follow great designers, learn design styles such as Bauhaus and glassmorphism, and learn how to prompt for them. He even built a public app to teach himself those styles.

On engineers, he says elite engineering is needed more than ever, because someone has to maintain and scale code and keep infrastructure running when millions of new builders arrive. He also says that if he had an 18-year-old brother, he might say to become a plumber and not to get a CS degree. He predicts coding will be like calligraphy, a rare art, and that engineer, designer and PM roles will converge.

Jovanovic's debugging framework is called 4x4, like a vehicle that gets out of the mud. The first try is to click the tool's built-in try-to-fix button when it admits a mistake. The second is to add awareness: open the preview, reproduce the bug, read the browser console, and if the tool cannot see the problem, ask it to write console logs in relevant files. Pasting that log history back into chat solves it, he says, about 99% of the time.

The third is an external reviewer. He exports the code to GitHub and imports it into OpenAI's Codex, using it only for diagnosis because he does not know its agent well enough to let it edit. He also uses Repomix to compress a codebase into one file and uploads it to Claude or ChatGPT. Lenny notes that Karpathy and the head of Codex have both described Codex as the tool for the gnarliest bugs.

The fourth is usually the best: assume the fault is yours. Revert using built-in version control, rethink the prompt, take a break and try again, since sometimes the model just stumbled on a small rock. Afterwards, he asks the tool in chat mode how he should have prompted it so the problem would have been solved in one go, and has it record the lesson in the rules file.

Lenny connects Jovanovic's habit of reading the agent's output to an idea from Cursor's CEO about a layer that comes after code. In that view, the layer is the agent's reasoning plus your conversation with it. Jovanovic agrees, and tells the story of spending a week trying to build an image-generation wrapper before OpenAI had released an API for it. A week later the API arrived and he built the app in 30 seconds. He now uses chat mode to learn what is possible.

He says many of the workarounds he taught in a course and a YouTube series are now built into Lovable and obsolete. He cites the horses analogy about how fast roles can be displaced. Still, he is excited, because people will be paid to think and ponder longer while building becomes instant.

For lasting skills, he points to emotional intelligence and human-to-human work, since people will tire of fake content. He thinks deterministic, math-like work is most exposed, while good design, images, fonts and especially copy will matter because people spot AI writing in seconds. He predicts translators will struggle and comedians will not, while stressing that this is a personal belief and that he expects to be wrong on 95% of what he said.

Jovanovic's path was far from linear. He is a forestry engineer by training and has worked blue-collar jobs and waited tables, and then spent seven or eight years in startups doing everything except writing code, starting with community management and social media. He compares it to Slumdog Millionaire, where each life experience turns out to supply an answer.

He thinks the job came from building in public. He ran a YouTube channel, shared his failures and projects, and posted on LinkedIn, and that is how Elena Verna found him. His advice is to share what you know, attend hackathons and apply where companies are hiring. He adds that some hires stood out by sending a Lovable app instead of a resume, and that Lovable staff will always open a link on the lovable.app domain.

He says other companies had full-time vibe coders before Lovable did, including one with three people migrating a legacy codebase, CRM and CMS onto Lovable. Some S&P 500 job descriptions now list Lovable skills as recommended. His summary is that you do not need a company to hire you: do the job you would have done anyway, and do it professionally first.

In closing, he says the tech stack no longer matters and that people should set aside more time for learning than for building. He urges anyone who is afraid to simply build something, since the fear turns into excitement once you see what is possible.