Lazar Jovanovic: evaluation

Transcript context

…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. 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. 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 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. 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, Cloud 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.…

Stored transcript either side of the excerpt. The highlighted words are the published quote; the surrounding text is unedited source, never generated.