Lenny's Podcast: Product | Career | Growth
00:26:31 · Lenny Rachitsky, Lazar Jovanovic
[00:26:31] S1: 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. 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 general idea." Use Wispr 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," 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? [00:27:20] S0: Yeah, most times. Yeah. [00:27:21] S1: Cool. Okay. And then the fourth, and these are all in parallel, this is great, is find actual code template that looks similar to the thing you want to build, download the zip file basically and attach it, or is it just HTML and CSS? Is that kind of what- [00:27:22] S0: Anything. [00:27:22] S1: Anything you got. Cool- [00:27:22] S0: Yeah.
00:27:22 · Lazar Jovanovic, Lenny Rachitsky
[00:27:22] S0: Yeah. [00:27:39] S1: There 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. "Oh no, that's not what I mean. Let me try it again." And then two as 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.
00:28:27 · Lazar Jovanovic
[00:28:27] S0: A million percent that I'm actually saving people. I'm actually going against what I should be saying. If I was thinking about Lovable, is I would be like, "No, no, just try to fix it in perpetuity," but that's not ... We're not in business of doing that. We're in business of empowering anybody to build anything that they want. And then it's my personal mission that resonates with me because if there wasn't Lovable, I would've never built anything, potentially in my life and I don't think that, that would've been a fun life to live. So I guarantee people, I've tested this framework with many people and everybody's telling me the same thing, "Eye-opener." So simple, yet unintuitive, as you said. Even though for me it's kind of ... I don't know. As you said, I attribute it to non-technical background. To me, that was the first thing that I would do. 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. When people ask me, "Wow, how do you ship so many things?" I'm like, "I never build just one project at a time. I build 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 do context switching? You talk about context so much, yet you're 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 do I mean by that is this. If you just go and you prompt and you prompt and you prompt and you prompt, you'll 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 agent is optimizing for speed.
00:30:48 · Lazar Jovanovic
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 like 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, "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 as the project goes." And you can do that in many ways, but the most efficient way that I found was, I would do the four parallel builds. Let's continue off of that example. Very quickly, after you've built hundreds of projects like I did, you see the winner. The winner is so obvious, it's not even a competition. You maybe do one or more two 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. What PRDs are for, again, people that are not familiar with the terms, they are project requirements documents, or for me, I call them sources of truth. 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." 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." 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, "Okay, when we know how things look and when we know how we're building it, how does the user journey look like? I use the 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.
00:33:23 · Lazar Jovanovic
That's where I'll spend a lot of time now on. 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. 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 .md part is Markdown. Basically, I'm just using Markdown format because I've learned that AI likes to read Markdown. And what that serves as a source of truth on actual tasks and subtasks that it will need to execute to get to the finish line. 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 agents.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, "Hey, read all the files before you do anything. Don't do anything before you read all the PRDs. Read tasks.md to see which task is next, 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 outsource that and delegate 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.
00:35:46 · Lazar Jovanovic
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 job, pretty much. That's why I don't optimize for this skill at all. 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. People don't talk about fonts at all that work with AI. They're 60% in my mind, maybe even more in how your output's going to look like. That's my obsession. I don't obsess over these things that I'm talking today because I know what's coming. 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.