Lenny's Podcast: Product | Career | Growth
00:24:12 · Lenny Rachitsky, Zevi Arnovitz
[00:24:12] S0: Okay. [00:24:18] S1: So it's both for the CTO to deeply understand the problem that we're trying to solve and also understand the current state of the code base, what files need to be affected, and how is the best way to implement this technically. And usually what happens is right now, Claude is just basically reading a bunch of files, understanding the basic structure of the code, and then it's going to come back with a bunch of clarifying questions that will decide how we end up implementing this. [00:24:44] S0: So it feels like it's talking to your engineering manager. [00:24:48] S1: Exactly, exactly. 100% this is how I think about it. [00:24:51] S0: And you said that you're a CTO, so you used to use ChatGPT prompt to have a CTO in there. Now the CTO's living inside here in Cursor? [00:25:00] S1: Yeah, because of the way the tools have developed and they've become so good at both exploration and code execution. So now it's just a habit that I call it a CTO, but it's basically all in one. The same agent will both do the exploration and write the plan and end up executing the code. [00:25:19] S0: Got it. So it's basically it's Claude Code. Is there a prompt you gave it to act like that? To act like the right kind of CTO?
00:25:19 · Lenny Rachitsky, Zevi Arnovitz
[00:25:19] S0: Got it. So it's basically it's Claude Code. Is there a prompt you gave it to act like that? To act like the right kind of CTO? [00:25:26] S1: Yeah, so within the Claude.md, which is basically the system prompt that's loaded within Claude's context in every conversation, I have some basic stuff like this is our workflow, this is how we work. Within exploration phase, I want you to challenge my thinking, all kinds of stuff like that that can be loaded within the Claude.md file. [00:25:47] S0: Cool. One last question before we move on here, just because I'm thinking about it as this happens, the Linear issue that you generated, how often is it actually great and ready? How often do you have to edit it? What's the quality of the Linear ticket that it generates? Because a lot of people are probably wondering just like all these terrible linear issues are being created by AI. Are they actually any good? [00:26:08] S1: It's completely different because I'm a company of one. So a lot of the context is within here and there's no need for me to talk to other teams and understand. It's basically very accessible, and also I can easily see when Claude understood something wrong. I don't want to say that I would create Linear issues at work like this, but definitely if you're building your own side project, they're pretty quality. And also, it just kicks off when I want to start working on it. I wouldn't say it's ready to be built. It's ready to start being explored.
00:26:08 · Zevi Arnovitz, Lenny Rachitsky
[00:26:08] S1: It's completely different because I'm a company of one. So a lot of the context is within here and there's no need for me to talk to other teams and understand. It's basically very accessible, and also I can easily see when Claude understood something wrong. I don't want to say that I would create Linear issues at work like this, but definitely if you're building your own side project, they're pretty quality. And also, it just kicks off when I want to start working on it. I wouldn't say it's ready to be built. It's ready to start being explored. [00:26:44] S0: Got it. So it's just the beginning of an idea. Actually, let's come back after we go through this flow of how you would approach this if you were at say Meta or another, maybe a smaller company, how this workflow might work at a larger company that isn't just your own startup. [00:26:56] S1: Yeah. Interesting. [00:26:57] S0: Let's come back to that.
00:26:57 · Lenny Rachitsky, Zevi Arnovitz
[00:26:57] S0: Let's come back to that. [00:26:59] S1: Cool. All right. So this is Claude coming back. I have a comprehensive understanding of the code base. I thoroughly analyzed StudyMate live codebase and understand the current system, feature quest and key areas that it's identified. Usually I'd spend a lot of time going over this because this is super, super important, but just for the sake of development right now, we're going to brush through this. Now Claude basically comes back after it's gone through the code base and understood the way it currently works. It's basically telling me what the current understanding is. So it's talking about how the app is set up at the moment, how the data is structured, what it understood from the feature quest, and what it has identified as key areas, and then it asks me some questions. So it's asking about the scope, it's asking about the data model, the UX/UI of the feature, how it should be validated, how it should be graded, what changes need to be happened to the AI system prompt and all kinds of questions about the app. I've prepared answers to all these questions beforehand because I don't think we all want to sit through this. So I'm just going to paste that in and we'll see what Claude says. [00:28:08] S0: Awesome. I love it. And I love just scanning those questions I was asking. It's like such smart, sophisticated, important questions instead of just, "Cool, here I go, I'm going to build it."
00:28:18 · Zevi Arnovitz
[00:28:18] S1: Yeah, and I think this is the big difference between just vibe coding and going along with the vibes and really building serious apps. I spend a lot, a lot of time going back and forth and understanding. Also, a very cool /command that I haven't showed yet is learning opportunity, which basically when something is really difficult for me to understand, I'll do /learning opportunity and then talk about what I want to learn. And this basically primes Claude and says, "I am a technical PM in the making. I have mid-level engineering knowledge. I understand architecture and basically I want you to explain what we're currently working on using the 80/20 rule." So this is a great way to learn. I would definitely take this and every time you kind of see something that you don't fully understand, I would definitely use this to learn. Great. So Claude basically comes back and says how it understands the current data model and how it's going to implement. Yeah, so it's ready to create the plan. So basically what I'm going to do now is I'm going to go and do /create plan and while Claude is doing this, I'm going to show really quick what this looks like. So basically, these plans are from a template that I found on Twitter. I forgot who it was, but it was just a template that really resonated with me. And it's basically saying, based on our exchange, create a markdown file that will be the plan, include clear, minimal, concise steps, track the status. So this basically has like status trackers on each task that Claude updates as it's going through and it will have a TLDR, some critical decisions that we've made and the plan itself. So Claude has finished writing the plan, so we'll be able to look and see exactly what the plan is. So it has a TLDR, it has the critical decisions we've made and the tasks broken down. And this is a perfect plan and it's also a really good way to write this because a lot of times, I'll use different models to execute certain stuff. So Cursor has an amazing model called Composer, which is superfast. So a lot of things that are not that complex, I'll use Composer. Gemini 3 that just came out is unbelievable at UI. So a lot of times, I'll split the plan into backend and front end, and then I'll have Gemini just read the plan and do the front end. So having this as a markdown file is really good.
00:30:44 · Zevi Arnovitz, Lenny Rachitsky
And also going forward, it's really good to have within the app so that later on, if an agent is writing code in a certain area, I can see what's already been done there. So what we're going to do now is we're going to execute the plan. So now I think we're going to do this with Cursor just because Composer is so freaking fast. So what we can do is basically just say execute and then we can tag the file. And Composer is ridiculously fast. So that's it. It's off. It basically understands what the plan is and it's going to go ahead and start writing the code. [00:31:20] S0: Let me ask you a question while this is happening. [00:31:22] S1: Awesome. [00:31:23] S0: I have many questions, so this is a good time to ask a few of them. You said that Lovable and Bolt and other apps in that space are just not enough to build really serious apps and you have to move to Cursor to do that. Tell us more about that. Just what's the limitation you ran into with those products and why you switched to Cursor?