Building a magical AI code editor used by over 1 million developers in four months: The untold story of Windsurf | Varun Mohan (co-founder and CEO)

22:07Like their goal is not just to maybe graduate from college and then get a job at a big tech company where they're told exactly what to do or where to put the pixel on, you know, for this one website. And I think that's maybe a skill set that is undervalued just right now, probably in the last, you know, maybe 10, 10 years or so. And I think that's going to be really, really important. You know, a skill for us, for a startup, obviously, these are skills that we just look for. We look for people that are really high agency, because we just recognize that by default, if we don't innovate and do crazy things, we're going to die.

22:38The company is just going to die. So we just look for this, right? But I would say like for most software engineering jobs, that's probably not the case, right? Just think about, you know, big company X and what they're hiring for on the average software engineering interview. It probably doesn't look like that. I love how you phrased that. If we don't do crazy things and innovate, we're going to die. Yeah, that would be a great title for this podcast episode. And I think I know it's 100 % true. There's just a lot of crazy things happening and a lot of innovation happening. And if you can't keep up, you'll die.

23:07So let's talk about hiring. You have a really interesting approach to hiring. There's a few questions I have here. One is just how do you, I know you try to stay really lean. That's a common theme across all the AI startups these days. How do you know when it's time to hire someone? I love the idea of being a lean company, but I don't idolize it in the way that, hey, like it is a dream to be a 10 % or 20 % company that's making, you know, 50, 100, 200 million in revenue. That's like not, I think what we idolize inside the company. I think what we idolize is be the smallest company we can be to satisfy our ambitions.

23:44That's what the goal is. And maybe, Lenny, the way I would sort of put that out there is, if I told you, hey, I'm going to build an autonomous vehicle, and I said, our team is 10 people, you should rightfully say, hey, Varun, you're not serious. And you'd be right. I'm not serious at that point. So I think the answer is, what is the minimum number of people to go out and build the crazy ambition project that you have. And I think the project we are trying to go out and do, which is completely transformed the way software gets built. We've mentioned this inside the company. Our goal is to reduce the time it takes to build apps and technology by 99%.

24:15Right. It is a tremendously sort of ambitious goal. And it's not possible for us to be a 10, 20, 30, 40 person engineering team in the longterm and actually satisfy that goal. We think there's a very, very high ceiling. So that's maybe the first key piece there. It's like, Actually, you know, if we can crack actually being a fairly sizable company, but still operate as if we're a startup, that's the dream, right? That's the dream. In terms of hiring philosophy, the way we sort of think about things is we only hire for a role if we're actually underwater for that function. So let's say we're going out and building inference technology.

24:51Unless we're underwater there, we will not go out and hire someone to go out and work for that, right? And the reason for that is I actually think this is a feature, right? When you hire for a role and you already have enough people there, you get a lot of weird politics that ultimately ends up happening. And it's not because people are bad people. I think most people are really well-intentioned. But what happens when you have people that join a company and in reality, you didn't really need them? They will go out and manufacture some other thing that they should go work on, right? They will go out and figure out something else to work on.

25:24and realistically, it's not that important, but they will go out and try to convince the rest of the organization that it is important. Right. And I just think as a startup, we don't have the bandwidth to go out and deal with that. Right. For me, I would like to see everyone just almost like be like raising their hands up, being like, I'm dying. Like we need we need one more person. And that's when we go out and hire someone. And one of the analogies I like to give is I want the company to almost be like this dehydrated entity. Right. And every hire is It's like a little bit of water, right? And we only go back and hire someone when we're back to being dehydrated.

25:57I love this metaphor so much. And it sounds painful. It sounds painful that you need to be underwater and raising your hand. I'm about to die and dehydrated. But I also know that it's a really exciting way to work. Like it sounds hard, but if you're in it, it's just like, I guess talk about just that side of it. Because I think it could sound like this is terrible. I don't want to work this way. You know what I actually think, Renny? It's really good for a handful of reasons, which is that a lot of the people, we respect and trust the people that work at the company. So this forces ruthless prioritization.

26:30You know, you have a team that's going out and doing something. They will never ask to work on something that's not important. In fact, if there are two things that they're working on, they're just going to just tell me, hey, there are two things on my plate. I just don't have the ability to do two. I can only do one, and they will pick the one that's most important. And this actually goes back to one thing that I think is true about startups and just companies in general, you don't win by doing 10 things kind of well. You win by doing one thing really well, and maybe you fail nine things. This is the thing that I've told the company.

26:58This is very different than school, right? In school, you optimize for your total GPA. But for companies, I just need to get an A plus on the one class that matters. And then I can get an F in all the other classes. And an F in all the other classes doesn't mean just doing illegal things. That basically means you just deprioritize things that don't matter. That actually forces this organizational prioritization that is just really, really good. And Douglas and I, Douglas being my co-founder, we can tell the company, these are the two things that are the most important. But if we go out and tell these are the two things that are the most important to the company, and then we put the company has 20 % more people than necessary, what's going to ultimately happen?

27:38It's almost a forcing function for ruthless prioritization to have fewer people or people that are just underwater internally at the company. Everyone listening that works at a big company knows exactly what you mean when you describe when there's just too many people, they will all find work to do and they will all be pitching ideas. You know, they all want to show impact. They want to do well in their performance reviews. That's just the nature of too many people at a company. And so I think this all really resonates. To even get even deeper on just what it looks like when someone's underwater to tell you it's time to hire.

28:09Is it just someone coming to you? Varun, I need someone on this team. This is just not possible. What does that look like even more practically? Yeah, I think it's basically along those lines. It's that, hey, there's some pressure to get something done in a short period of time. By the way, one of the things that we do believe, though, for software, if you want to do great things, it's not possible to just say, hey, I want to get it done in one month. If it is like, because you have to think about it from this perspective, if a software project could get built in two to three weeks, what does that really mean about like the true complexity and differentiation of what you built?

28:39Like, it's probably not very high, unless you believe you are way smarter than everyone else. But I think that's hubris, right? I think we actually have a very exceptional engineering team, but also at the same time, I don't think our engineering team is so exceptional that we can do things in three weeks that the rest of the world can't do in like six to nine months. That's kind of stupid to believe that. So I think basically it comes down to that person coming out and being like, hey, look, like I don't have enough time to do X. Us having a conversation to be like, okay, what can you do then?

29:07And if the answer is I can only do less than that, then maybe we make a decision actually, oh, wow, that's great. Maybe we actually should deprioritize why. Because this is actually also another thing that's very hard, even for people like me and my co-founder. It's that we also want to do a lot of things, right? There's an urge to do a lot of things. But if we are forced to make a decision constantly on like, we cannot do X, it's very clarifying. It's very clarifying. Because our engineering interview process is also like extremely low acceptance rate. So it's not very easy for us to very quickly spin up people and have them join the company really, really quickly either.

29:43So I think it's clarifying for everyone. It's clarifying for the person that wants more people. We can just tell them, hey, like, look, we don't believe you should be doing this other thing. And it's also clarifying for us because we can also get on the same page with them, right? And sometimes we just kind of agree, hey, like our teams are very flexible that, hey, actually we do need to get something done. And one of the things that we've kind of tried to make sure is true on our engineering team is people's value to the company does not have anything to do with the size of their team. There are projects inside the company.

30:13There are directly responsible individuals for these projects inside the company. And if we feel like one project is very important, then people can move from one project to the next, right? There's no notion of someone owning people at the company. That is a very bad and gnarly idea, right? In fact, the person that is the most valuable at the company is the person that can do the most crazy sort of project out there with as few people as possible. And that's what you should be rewarding internally. How many people do you have at Codium at this point? So we have close to 160 people and the engineering team is over 50 people.

30:42Awesome. Oh, what's the other bigger functions? So we have go to market. We have, yeah. Oh, right. Okay. I want to talk about that. The sales learning that you guys had. Okay. But let's close out this hiring conversation. So we talked about what you look for to tell you it's time to hire. What do you look for in the people that you interview and hire? One of the key pieces that we look for, we have a very high technical bar. So assuming that they actually meet the technical bar, I think we sort of look for people that are really, really passionate about the mission of what we're actually trying to solve and people that are willing to work very hard.

31:14I think one of the things that we don't try to do is convince people, hey, look, we are, you know, we're a very chill company and it's great to work here. I think, no, this is a very exciting space. It's very competitive. You should expect us to lose if the people at the company are not, you know, kind of they're not working very hard. And I think one of the biggest dog whistles I sort of hear is when I ask people, like, how hard are you willing to work? Like some people actually ultimately say, hey, I work very smart. And I basically ask them a question. If we have many smart people at our company that also work hard, what's the differentiator going to be?

31:46Are you just going to pull them down? Right. Because I think one of the things that's true about companies is it's like this massive group project. And I think the thing about a person that is not pulling their weight, that's bad, it's not the productivity, right? At some point when the company becomes many hundreds of engineers, I'm not going to be thinking about the one engineer that's not pulling their weight. it's the team of people they work with that are almost basically saying, is this the bar internally at the company? Is this the expectation? And I guess, Lenny, if I told you, you have a team of five people and, you know, the four other people you're working with just don't care, how much are you going to feel like you should care?

32:21Not too much. Exactly. So for us, for us, I think that's what we more care about, right? We have a culture where we're it's like, it's very collaborative. It's, it's not an individual sport, but people feel like they can rely on other people to get complex sort of tasks done. So the question you asked there just basically is how hard are you willing to work? How hard do you want to work? And I know some people there, there's, you know, this whole group of folks that are just like work-life balance. I don't want to, how dare you ask me to work crazy hours. And I, I, I'd love just the filter up front of, if you work here, you will work really hard.

32:54You work, work, work a lot of hours. It's a crazy, it's a crazy space to be in and we will win by working smart and also really hard. Yeah. You said at some point earlier that your engineering pass rate, as you said, was like 0.6 % of candidates, something like that? Yeah, it's probably post or take home, it's probably that, actually. So the take home itself filters probably another 10, 15x on top of that. Here's a question that I've been hearing more and more is just how do you do interviews these days with tools like Windsurf out there that solve all your problems? we're okay with people using the tools because i think one of the worst things is like if someone comes here and doesn't like using these tools like we believe they're massive productivity improvements we do bring people like into the company like on site so we can actually like see how they think through problems on a on a whiteboard and all these other pieces so so we do want to see how they think on their feet and hopefully they're not just like taking what we're saying putting it in a voice translator and sticking it in the chat so bt and getting the answer up.

33:51So there is a way to do this. My viewpoint on this is, is the tools are really, really important. But I do think we still look for some problem solving ability, right? Like, if the only way you can solve a hard problem is like put it into chat to be T. I think I think that's like a concern to us. Today's episode is brought to you by Coda. I personally use Coda every single day to manage my podcast and also to manage my community. It's where I put the questions that I plan to ask every guest that's coming on the podcast. It's where I put my community resources, it's how I manage my workflows. Here's how Coda can help you.

34:24Imagine starting a project at work and your vision is clear, you know exactly who's doing what and where to find the data that you need to do your part. In fact, you don't have to waste time searching for anything because everything your team needs from project trackers and OKRs to documents and spreadsheets lives in one tab, all in Coda. With Coda's collaborative all-in-one workspace, you get the flexibility of docs, the structure of spreadsheets, the power of applications and the intelligence of AI, all in one easy to organize tab. Like I mentioned earlier, I use Coda every single day, and more than 50 ,000 teams trust Coda to keep them more aligned and focused.

35:01If you're a startup team looking to increase alignment and agility, Coda can help you move from planning to execution in record time. To try it for yourself, go to coda.io slash Lenny today and get six months free of the team plan for startups. That's coda.io slash Lenny to get started for free and get six months of the team plan. Coda.io slash Lenny. Okay, let's talk about this go-to-market sales experience that you guys had. So you started without, obviously, like most people, started building without sales team. And then you realized, from what I hear, that that was a huge miss and a big opportunity to talk about there.

35:36Because that's really unique, I think, that you guys have a large sales team and go-to-market team. Yeah, we actually made this decision pretty early in the company's history, I would say. Like, we hired our VP of sales over a year ago. actually. And the go-to-market team is now over 80 people inside the company. So it's a pretty sizable function inside the company. Yeah, maybe a little bit of a backstory here. So when we started the company, actually, we had a handful of angels that actually were operators, go-to-market operators. So an example of one was Carlos Del Torre, who used to be the CRO of MongoDB.

36:07And I think for us, we never viewed enterprise sales and sales as a very negative thing. I think this is an interesting thing that technical founders sometimes don't really like. They think sales is like a very negative sort of part of the process. Everything should be product-led growth. And I think it's not that black and white. Like I think enterprise sales is really valuable. But maybe when we were a GPU virtualization company and we were an infrastructure company, the reason why we never hired a salesperson is I didn't know how to scale the function. I was the one who was selling the product.

36:37So ultimately speaking, if it was hard for me to sell the product incrementally, I didn't know how we could make that into a process that we you then go and scale, right? If I couldn't, if I can do one, like, I didn't know how we could take the revenue of the business from a couple million to hundreds of millions, and let alone even tents. So if I didn't know how to do that, how could I go out and hire someone and make them scale it out? On the other hand, for Kodium, very quickly, a lot of large enterprises sort of reached out to us. And from that alone, in the middle of sort of 2023, we started, I guess, me and a handful of other folks at the company started selling the product.

37:11And we were doing tens of pilots concurrently with large enterprises. And we were very quickly able to understand that there was a large enterprise motion that needed to be built in the space. So by the end of 2023, we actually hired our VP of sales and very quickly after that scaled a sales team. And yeah, I mean, look, if you want to sell to the Fortune 500, it is very hard to do that purely by swiping a credit card. Let's talk about Cursor. I don't want to spend too much time on competitors, but that's what everyone's always thinking about when they think of you guys. You guys are kind of the leading players, I think, in the space.

37:44Also, there's Copilot, but that's different. So what's the simplest way to understand how you guys are different from Cursor and also just how you think you win in the space long term? So I think maybe a pan full of things that I could share. So on the product side, I think we've invested a lot in making sure code base understanding for very large code bases is really high quality. And that's just because of where we started, right? We work with some of the world's largest companies like Dell, JP Market Chase, companies like Dell have singular code bases that are over 100 million lines of code, right?

38:12So being able to understand that really, really quickly to make large scale changes is something that we've spent a lot of time doing. And that requires us like actually building our own models that can consume large chunks of their code base in parallel across thousands of GPUs and almost rank them to be able to find out what the most important sort of snippets of code are for any question that are asked about the code base, right? So we've gone out and built large distributed systems based on our infrastructure for background to go out and do that. That's maybe one. Let me actually follow that thread because I think people may underestimate just how big of a deal that is.

38:44So when we talk about, we had the founders of Bolt and Lovable on the podcast. So those products, they build something from scratch. They write the code for you. So that versus just loading, say, Windsurf on your million line code base, say at Airbnb or Uber, like it understanding what the hell you have and how it works and where to go change things without breaking it is insanely hard. And so what I'm hearing is that's kind of a big differentiator. You guys started there actually and then Windsurf is now building on that advantage. That's right. Yeah, so that's like a big thing that we spent a lot of time on, which is just understanding sort of what the code base is doing.

39:22And actually like one of the other things is what are all the user interactions with respect to the code base? And happy to show that also in a bit here. The second key piece probably is we're not only tied to the to Windsurf, actually, this is probably like a weird statement given even we are talking about Windsurf, which is that actually we're pretty focused on supporting IDs like Jeprains, right? Right. You know, JetBrains or IntelliJ has over 70 to 80 percent of all Java developers code in JetBrains based IDs. Right. The reason why we don't feel as big a need to almost build a competing product to JetBrains is JetBrains is actually a very sort of extensible product in a way that VS Code is not.

40:03VS Code is not very extensible. So I think for us, our goal here is not only just to satisfy a subset of users that can actually switch onto our ID, but we want to give this agentic sort of experience to every sort of developer out there. And if that's if that means there are Java developers that write in JetBrains, that's fine. We work with a lot of large enterprises that have 10 ,000 plus developers, where over 50 % of the developers are on JetBrains. It's a very large, large product. And by the way, that company itself is a privately held company that makes many hundreds of millions of dollars a year.

40:31So it's a very, very large company. So for us, that's another key piece. We actually want to meet developers where they are. And if they use a different platform, we'll work on that too. The third key piece, and this probably sounds Another key piece for enterprises is we work in a lot of very secure environments. We have FedRAM compliance, which means we can sell to very large government entities. We have a hybrid mode of actually using the product, which means that all the code that is indexed actually lives on the tenant of the user. Code is one of the most important pieces of IP for the company.

41:05So I think just if you were to look at it from like a big company perspective, there are many reasons why like over the years of just like building an enterprise product, we've handled a lot of complexities that large companies want to see. But that's part of it is because of the history of how we got here in the first place. Okay, Varun, enough teasing. Let's do a live demo of Winsurf so folks can see what it's like. And then I'm just gonna ask you a bunch of questions as we're going through it. So I'll let you pull up a little shared screen where you have windsurf pulled up great so some context this is a very basic react project there's nothing in it right now so if you were to open any sort of files it's the default react app project and i have this basic image here uh you can pass windsurf images of what you'd like the project to kind of look like of of what i would like an airbnb for dogs website to kind of look like beautiful beautiful mock-up by the way i love that this is like all you need this is all you need this is all you need So basically what we're going to do is we're going to say, hey, one of the cool parts about Windsor is it can actually work in an existing project already.

42:10Right. So I can basically say, hey, change this React app to show an Airbnb for dogs website based on this image and preview it. So now it'll just go out and start executing code, reading through the repository. obviously doesn't know what the current code base actually looks like. And it'll go out and analyze the code base to actually find out the set of changes necessary. So we'll go out and wait and see what it's going to do. But while we're doing that, let's continue the conversation. Awesome. Okay. So first of all, you kind of start, so you open up Windsurf, you had a boilerplate React project ready to go.

42:53And Windsurf had never really seen this code before. You ask it to do stuff on your code base, which is just like change this to Airbnb for dogs using this design. That's right. That's exactly right. Yeah. Okay, cool. So we'll let it run and we'll talk. So let me ask you this question that I've been asking everyone that comes on that is building a product that helps engineers build products and product managers build products and designers. Say you could sit next to every single new user that opens up Windsurf and whisper a couple tips in their ear to help them be successful with the product. What would be a couple tips you'd share?

43:25Tip number one is just be a little bit patient and both patient and explicit, right? When you ask the application to go out and make some changes, it could actually go out and make many irrelevant changes, right? And one of the things that I think prevents this the most is just be really, really explicit or as explicit as possible. And one of the things I sort of ask people to do is in the beginning, start by making smaller changes, right? If there's a very large directory, don't go out and make it refactor the entire directory, right? Because then if it's wrong, it's going to like basically destroy 20 files.

44:00And I think from there, one of the key pieces I think that comes from the users that use the product is they sort of learn what the hills and valleys of the product are. And the analogy I like to give are kind of similar to autocomplete, right? When you use a product like autocomplete, you would think a product that is suggesting things, but only getting accepted 30 % of the time would be really, really annoying. But the reason why it's not very annoying is actually because you've actually learned that, hey, 70 % of the time, I don't need to accept this. And the times that I do, I know how to get value from it, right?

44:32And you also know beforehand, if a sort of command that you write is very complex, you just expect, hey, like the autocomplete is not going to work for it. So I think it's almost like understand what the hills and valleys of the product are. The crazy thing is every three months that kind of gets changed and reevaluated. It almost becomes the case that it becomes materially better than it was in the past. So I think maybe patience and being explicit are maybe the two important key pieces that I would tell users. And I think something that was kind of between the lines there is like get a gut feeling of what the model is capable of, like how specific to be versus how abstract it can be.

45:09and there's kind of this gut feeling you start to build over time. That's right. Yeah. And with that, it feels like we have an actual preview. And guess what? We have a nice dog app. And one of the cool parts is that we've also done beyond just modifying code is actually being able to point to different pieces. And I guess I could just kind of say, I could point to different elements and say, hey, make the background. This is not great design, but I could basically say, if I took this element, make this background red, right? And just take a particular element and just change it and make it red.

45:50And it should go out and be able to go out and do this. The preview aspect of the product of being able to showcase the app while it's getting built helps in that now actually you can live entirely in app world, right? You don't even maybe even need to look at the code. Granted, this looks hideous. But in some ways, if I wanted to, I could go out and do that, right? This is what happens when there's no more designers. Yeah, when there's no more designers. Maybe the answer is, like, when you ask me, what should people be doing? They should study great taste, having great taste, because I think taste is also very, very hard, right?

46:22But maybe the other key piece, Lenny, that I wanted to showcase here is, like, obviously you could keep going here. Like, I could take different components and kind of change them. You know, like, we have, like, a lot of plans here that are beyond just, like, point and click changing components. But one of the cool pieces is the AI, there's like an AI review flow as well, right? Which is kind of like what I was saying, the goal of AI is now changed a lot in that it is now modifying large chunks of code for you. And the job of a developer now is to actually review a lot of the code that the AI is generated.

46:52And granted, right now during this podcast, I'm not going to review all the code that's getting generated. But let's say I want to go out and modify some of this code, right? And this is where if you're an actual developer that actually wants to go modify, maybe I don't like my variable name being called title, I want it to be called title string, right, instead, like this. And if I wanted to go out and make that change, and make the change to go out and say title string, right, and that's what I'm going to do, I'm just going to tell the AI to continue. And the cool part about this is Windsurf not only kind of knows about what the agent has done, it also knows everything that the user has done.

47:25Like our goal here is to have this almost flow like state where everything the user has done, the AI also knows. And it's able to predict the intent. And as you can see, it said, I noticed that the interface property title was changed to title string. And then it now has gone out and modified all the locations within the app from title to title string. And now it no longer says that. So this is where like, even if I'm writing software, and I want to go and make point changes, the AI can go out and quickly make these changes for on the user's behalf. Imagine doing a refactor or migration, and you just change one part of the code, you can just tell the AI to continue the rest, right?

48:01And because it deeply understands the code base, it should go out and find all the corresponding places to go out and make the change. And obviously, now when I reload my app, there's no bug in the app, right? It still loads properly. I can obviously tell it to do even cooler things like make the app retro, right? I don't know what that means, but I guess I can do that. And it should go out and make the change correspondingly for me. But yeah, that's maybe the high level sort of parts there where the AI is not only kind of able to operate entirely in app space, but also on the code, on the code space of the user is going out and modifying code and to bridge the gap between the two.

48:37So it should add leverage, not only non-developers that are just purely building apps, but also developers that are just hands on keyboard too. Amazing. By the way, it's, if you're not on YouTube, you can't see that you can just select any element of the page and then reference that in your ask of here's what I want changed. I didn't know that was a feature and that is extremely cool. so interestingly so having just looked at lovable and bolt and replin and apps like that it's basically doing all the things those apps do oh wow there's the retro version that's good i like that it built on your red and made it really nice actually the red looks way better yeah with the little green button this is great okay so so i don't think people realize this about apps like windsurf but it could actually do a lot of agentic work for you where you just tell it here I want you to do this versus it's auto completing code for you.

49:25The big difference is you need to start it with some code base. So you have this kind of boilerplate react project. Is there a reason you guys aren't taking that step and just doing that automatically for you? Is it because you're targeting engineers and they don't need that? Or is there other reasons? Lenny, the interesting thing is like the base app that you saw for this was also generated by Windsurf. The reason why we sort of didn't generate it is installing all the dependencies takes like three or four minutes. And for the demo, I didn't want to wait. But totally, actually, most of the users within of the product, probably zero to one build these apps.

49:57And if I can say one interesting thing is when we launched Windsurf, actually, we tasked everyone in our company to go out and build an app with Windsurf. That included our go-to-market team and our sales team. And there was a crazy stat that I think people would find surprising, but we saved over half a million dollars of SaaS products we were going to buy because our go-to-market team has now built apps instead of buying them. Like our head of partnerships, instead of buying a partner portal product has actually built his own partner portal. Right. And that was that, you know, he had never built software in the past.

50:30So, and we've actually come up with ways inside the company to deploy these apps easily in a secure way. And we're actually now like building very, very custom software for our company to operate more efficiently, which is, I would not have expected this probably six months ago. That is incredibly interesting. You don't need to name company names, but I guess what's a space you're least bullish on that you think is going to have the most problem here with people building their own version of these sorts of products? I think maybe my viewpoint are these very, very verticalized niche products, I think are going to get, they're going to get competed down a ton.

51:08And I think sales products are an example of one of these things, right? And maybe this is a, I don't want to be like very negative, but it's very hard inside a company like ours to task our best engineers to build a best in class sales product. There's not enough interest to do that or to build a best in class legal software product or finance software product. It's very, very hard for us to, right? And actually that's a very big moat for these companies that they were, that built these products, that they were able to come out, have an opinionated stance on how to do this, hire good enough engineers to go out and build the software.

51:41And our company is unwilling to do that. So previously, we would go out and buy the technology, right? Because there would be no alternative. But now one of the crazy things is that the domain specialists now have access to build the tools that they ultimately wanted, right? Which is actually crazy, right? If you think about why were these software companies able to exist, these vertical software companies? The reason is because they had many features. The kitchen sink of features worked for a lot of companies, but each individual company only wanted 10 % of the features. But the problem is each individual company was not capable of maintaining a piece of software or building the custom piece of software for 10 % of the features.

52:18But that has now changed entirely. Now they can. And there's always, yeah, there's always been the story of like, why would I spend any time building my own software if I just but now it's like five minutes of time like it's five minutes and maybe even more custom to your to your system right like how many times have you bought a piece of bought a software and you you're almost like why is there no integration to x and i actually use x how annoying is that that actually makes the software less useful to you so i think what's cool is when you go back if someone zooms back to the beginning of when you started the demo it's basically a pm talking to an engineer hey, build me an Airbnb for dogs.

52:55Here's a stupid mock that I made like with some boxes. Like that's almost like a bad PM talking to an engineer and it just actually works. That's what's insane about this. And so that's why this example you're sharing of go-to-market folks building their own things. It's like they don't need to know anything about product building. It's just describe it in some ridiculous way and draw a couple boxes of what you want it to look like and it makes something for you. It shows that agency is what matters. If you have a product manager that has an idea, there's no reason for why that idea cannot be like more well fleshed out, right?

53:28Like how many times do you have a product manager that just continualize ideas, but it just feels like they are extremely unsure on how to execute on it. They just want to say things for the sake of saying things. But for the people that have ideas and a lot of, I guess, agency, they can go out and like prove out what they want without any sort of external resources. I think even more acutely for product folks listening to this, it's the salesperson coming to you being like, hey, I want this thing. It's going to help me with my sales team. And you're like, I don't have a million things to build.

53:58I don't have time for this. And so that problem goes away, which I think will make a lot of product leaders really happy. The model that this is sitting on, is it Sonnet? Yeah. So just to break down how it ultimately works, we have a model that does planning. And I would say right now, Sonnet is a really, really good planning model. I think OpenAI's GPT-40 is also good. But the crazy thing is what we try to do is we try to make the Anthropic-based model or Sonnet model try to do as much of the high-level planning as possible. And then what we try to do internally is run all the models necessary to do high quality retrieval for the agent.

54:34As you can see, the agent needed to understand what the rest of the code base ultimately did. We actually make sure we run models to actually chunk up the entire code base and understand the code base. So that obviously it would not be a good idea if we had a 100 million land code base to send that entire code base to Anthropic. First of all, you couldn't do that. That's over 1.5 billion tokens of code, right? So obviously that would be three orders of my, three or four orders of my two larger than the largest context links right now. But you also wouldn't want to do that from like a cost and latency standpoint, too.

55:02So that's like one. And the second piece that you saw was the model is able to very quickly make edits to the to the software as well. We have custom models that we built that are post trained on top of popular open source models that can make these edits really, really quickly to the code base. And the reason why you would want to do that is it's a faster and be also that model can actually have more of the code base in context, too. So it can be better at applying changes than even Anthropics model too. So I think the way we like to think about it is our only goal is how do we build the best product possible, right?

55:33How do we build the best product possible? And how do we make the ceiling as high as possible? And we will go out and build models and train models wherever necessary. But if we're not going to be good at a task and we think the open source is better or Anthropics is better, we'll go and just use the open source or Anthropics. And so the models you guys are building, those are built on open source models that people have released. Interestingly, the one that does retrieval is actually completely pre-trained in-house that actually does that. But yeah, for a lot of different pieces, it's based on open source.

56:01Interestingly, for the one that does the edits and autocomplete, that is also in-house. As you're typing, we actually do some autocomplete related stuff. I'm happy to show that, but I think a lot of users are familiar with that capability. So I think the way we like to look at it is like, what could we be best at? And we will go out and train. But if we're not going to be best at it, we should not just for the sake of ego, go out and train something. This may be getting too technical, but just is there anything interesting around what you train on? Yeah. So one of the one of the interesting things that we have from our users, and this is like where we try to think, like, why would we be any better?

56:34It's that actually every hour we get probably tens of millions of pieces of feedback from our users. We get a lot of feedback on what they like and what they don't like. For something like autocomplete, we get a lot of preference data, a lot of preference data. And the preference data is weird. It doesn't look like data that you find on the Internet. It's like data as the user is typing, right? Imagine you're typing some code in a code base. The code's going to be incomplete as you're typing it, right? It's not going to be in a full-fledged form. It's not like it is on GitHub. But we have a lot of data that looks like this.

57:05So we are uniquely well-positioned to actually build a good model that can complete code, even when it's in an incomplete state. When the models that are out there, the frontier models have consumed very little code that looks like this. So for that case, we're like, hey, we can go out and do a much better job potentially. Right. And we'll go out and train models on all the preferences that we have. The same is kind of true on retrieval. Right. There's a way to find out, are we retrieving the right data? Right. Did the user accept the code change after that? Was the retrieval actually a good retrieval, a signal that we can get?

57:35So basically the way we like to look at it is if something is just purely like code planning, there's not a great reason why we would be the best at that. Right. I think that would that would not be. I can't come up with a coherent argument for that. But for something that looks more along the lines of, hey, here's an intermediate code base that is very gnarly. And here are some changes that need to get made. And we know the evolution of the code, or we've seen the evolution of code across millions of users. We feel like we can do a great job of that. I think what's interesting about this is this is another differentiator slash moat for companies that end up winning in the space is you just have more and more of that data than other companies, if you're ahead.

58:13Yeah, this is sort of why maybe at a high level, like we like the zero to one upbuilding product space. I think it's really it's a good product space. But ultimately, I think it needs to boil down to you understanding the code, because otherwise, you're living at too high a plane, where it's not clear why you would be able to be the best at that compared to everyone else. It's not really clear. as a company you mean as a company it feels like it might get like competitive in a way that it's not clear like where you would continue to differentiate over and over with time i see because if they're just sitting on top of sonnet and just doing what every other sonnet rapper is doing there's not a lot of differentiation or it depends on how you do it but maybe if i was to say this if you're if the inputs you're consuming are just web elements like extremely high level web elements, then then the interface might be like high level enough that it's hard to maybe get better than maybe what the frontier models are doing just across the board.

59:10You are just better off just plugging in on it for everything. Got it. Awesome. One thing I wanted to come back to that I wrote down that I think is really important for people to understand. You talked about how with Windsurf, it's not necessarily there's like a boilerplate code base that you want to start with because it's actually because it's not an abstracted zero to one app builder. It's an actual IDE you're coding in. And you talked about how it has to install dependencies, which is kind of this painful thing. And the reason it has to do that is because it's running locally on your machine versus in the cloud, like, say, Lovable and Replit and all these guys.

59:44Although I think Bolt runs in your browser in this really cool way. So that's an important distinction. This is like you're running this locally on your machine and has all the libraries you need to actually run it. No, I think that's important. I think we believe a lot of people sort of build software in what are called like code spaces and things in a remote machine. I just think it's that a lot of developers like building locally for what you said. Like if you're doing things that are more than just full stack applications, you might have dependencies on your machine that are just like system dependencies that are just gnarly to install.

1:00:14Let's imagine you're building a GPU based application and the NVIDIA drivers are necessary. You just want to give people the flexibility to build where they can build. And I think, you know, the IDE and building locally has been a thing that people have done for, you know, decades. So probably it's not going to go away in the next couple of years. I love that your sales folks now are running like local host servers. Well, with the browser previews, it's easier, right? You kind of just like open it up on the side. Yeah. Yeah. Oh, my God. Okay. A few more questions just about how you think and operate at Codium.

1:00:43So you guys are kind of at the forefront of how product teams are going to operate. Like you are seeing the future every day. And so I'm curious if there's ways you guys have structured your teams, engineers, product design that might be different from how other companies are doing it or have tried stuff that has worked really well or tried stuff that hasn't been a huge disaster? You know, one interesting decision that we kind of have for core engineering is that we don't have pure product managers for the core engineering side of the company. And by the way, that's purely because we build for developers and our product is built by developers.

1:01:18So I think the intuition from our own developers is hopefully valuable. If not, we might be hiring the wrong type of people. So I think like our developers are in some sense flexing to be like more product, conventional product managers. Now, on the other hand, if we were building something that looked more like Uber or the persona was very different and we didn't ourselves understand it, I think we would not be, the organization wouldn't look the way it looks. For the enterprise side of the company, because we do work with a lot of large enterprises where the requirements are not something that like our engineers would automatically understand, right?

1:01:50I don't think our engineers wake up and they're like, we need FedRAMP, right? This is probably something that a lot of customers come to us and tell us. We have people that kind of like flex in this product strategy role that understand kind of what the customer wants and understands the technical capabilities that we have to best kind of build a product that would sort of help them at scale. So I think we have an interesting organization in this regard, but mostly I would say because we are a developer-based product, right? I would say that's true. And then also kind of like what you said for the engineering team itself, we are, you know, the team structure is it's fairly flat.

1:02:28We try to go with two pizza teams, teams that are fairly small, just because I think the problem is when a team gets too big, the person leading the team is no longer able to get in the weeds of the technology itself. And I think in a space that's moving this quickly, I think it's dangerous to have leaders that don't understand the technology deeply and are like, I'm not building. It's like very, very dangerous because there's too much like armchair quarterbacking. And so I think that's like maybe one other decision we made. And then teams are very, very flexible. So if we decide something is a new priority, we're very quick to kind of like change the way a team looks.

1:03:04And it's very centrally planned in this regard. The two pizza team concept I saw a tweet long ago where someone from India was like, there's always talk about two pizza teams, but pizzas in India are much smaller. and so the teams end up being smaller and they're like why can't we build as much as these teams in the u.s oh man okay so how many pms do you have so you said you have 150 employees something like that yeah we have so in terms of like the product strategy function we have we have uh we have three people in that role right now i see so it's like product it's like they're in their titles like it's product strategy not necessarily product management that's right interesting and then 50 engineers, you said 80-ish sales folks.

1:03:45Yes, that's right. And then obviously we have functions like recruiting, parts of GNA like finance. We have marketing at the company. So some other functions internally as well. It's interesting, and this is something you hear all the time with companies like Dario, for example, from Anthropic talking about how 90 % of code is going to be written by AI. But at the same time, all you guys are hiring engineers like crazy. Is that contradictory? Is that contradictory? Will there be an inflection point of like, all right, now we don't need them anymore. You know, I think it really comes down to do you get incremental value by adding more engineers internally?

1:04:19Like I'm going to take, first of all, you know, maybe just to set the record straight, if AI is writing over 90 % of the code, that doesn't mean engineers are 10x as productive, right? Engineers spend more time than just writing code, the review code, test code, debug code, design code, deploy code, right? Navigate code. There's probably like a lot of different things that engineers do. There's this one famous law in parallel computing, it's called Amdahl's law. I don't know if you've heard about it, but it basically says if you have a graph of tasks and you have this critical path and you take any one task and parallelize it a ton, which is make it almost take zero amount of time, there's still a limit of the amount of how much faster it made the whole process go.

1:04:56So maybe put simply, let's say you have a hundred units of time and only 30 units of time is being spent writing software. And I took the 30 and made it three. I only took the a hundred and made it 73. It's only a 27 % improvement, right? In the grand scheme of things. So I think, look, we're definitely seeing over 30, maybe close to 40 % productivity improvements. But I think for the vision that we're solving for, I think like, you know, even if I were to say the company in the long tail had 200 engineers, probably be too low still at that point. So the question is like, how much more productivity do you get per person?

1:05:27You know, actually, maybe just to even say one other thing for some of these large companies, let's say you took the CIO of a company like J.P. Morgan Chase, her budget on software every year is$17 billion. And there's over 50 ,000 engineers inside the company. And you told her, hey, each of these engineers are now able to produce more technology. That's effectively what you've done. The right calculus that J.P. Morgan Chase or any of these companies will make is the ROI of building technology has actually gone up. So the opportunity cost of not investing more into technology has gone up, which means that you should just invest even more.

1:06:05And maybe in the short term, you have even more engineers, right? Now, that's not true across the board. There are some companies that are happy with the amount of technology they're building, and there's a ceiling on the amount of technology they want to build. But for companies that actually have a very high technology ceiling, this doesn't mean you stop. This actually means you hire more. This is a great bull case for engineers. I feel like there's like the canary in the coal mine for the engineering profession is when companies like yours slow down on hiring engineers. Yeah, that's not happening.

1:06:31Seems like Anthropic is also hiring a lot. Yeah, everyone is. So I think that's really promising. I think if you're in college, still makes sense to get into engineering at this point. Okay, let me ask you this question as a kind of a final question, maybe. What's maybe the most counterintuitive thing you've learned about building AI products, building windsurf, and just being in a space? I think one of the weird things is online, everyone is very excited about the short-term wins that we're making, right? Like what we're putting out maybe weekly. We do these waves every couple of weeks. But actually, like a lot of the bets we're making inside the company are for things that are not, you know, three, four weeks, maybe three, six months, nine months away.

1:07:11That's what we're working on internally. Because I think this is kind of like, Lenny, what I was mentioning to you before. Like one of the goals that I tell everyone at our company is we should be cannibalizing the existing set of our product every six to 12 months. Every six to 12 months, it should make our existing product look silly. It should almost make the form factor of existing product look dumb. So there's this weird tension where you want to have a product in market and you want to incrementally iterate and listen to users and keep making it better and better. But I would say we were the first identic IDE product out there, right?

1:07:44That's what we landed with. And I think that the value of that is going to depreciate very quickly unless we continue to reprove ourselves. And we will need to reprove ourselves in ways in which our users are not even asking. So there's this tension here, where incremental feels very safe, right? Add this one more button. Users say, hey, I would like to be able to have this drop down to do x. But that is not the reason why we're going to win. That's just that's like, you know, that's almost table sticks. Yeah, we'll decide to do some of these, we might not decide to do a lot of these things. but it's like it's these longer term efforts inside the company that almost disrupt the existing product that are ultimately the reason why we're going to succeed and it's this weird tension that you need to have in your head of you can't also not listen to your users at all because they're the reasons they're the reason you exist this reminds me of a recent podcast guest we had gara from captions on the podcast and he he told us that he had he has two roadmaps they have two roadmaps at the company they have the the real roadmap like the typical roadmap based on feature requests and user feedback and data and things like that.

1:08:44And then they have the secret roadmap, which is completely not informed by users or data. It's just them making bets on where they think the world is going. That's right. And I love that he calls it the secret roadmap just to make it very mysterious sounding. That's very smart. Okay, I have one more question. I apologize. What's one thing that you wish you had known before starting Codium? Honestly, I wish I had... Maybe humility is like the wrong term, but this idea of just being okay with being wrong faster. Like I always think about things on like when we make decisions, me and my co-founder, we always talk about it.

1:09:19We're almost like, hey, I wish we had made the decision to do this a couple months earlier. We always talk about this. And the weird thing is outside looking and everyone's like, wow, like actually, you know, the decision was made at the right time. But in my head, I'm always banging my head being like, what if we had made it a couple months earlier? And I think part of that is, you know, I waxed poetically about like, oh, you need to be irrationally sort of optimistic and uncompromisingly realistic. But it's very hard to do this in practice, right? Because you drink your own Kool-Aid, too. It's very because if you're not drinking your own Kool-Aid, you won't get up out of bed.

1:09:51Right. The answer is already solved. It's not actually any of these startups. The answer is Microsoft is going to be the be the winner in any software category. Right. Isn't that isn't that the answer? Just because of distribution, resources and capital. Right. They're going to. commoditize every space. So I think in some ways, this amount of just understanding that, hey, reevaluate your hypotheses and get into an uncomfortable space way more frequently is something I need to remind myself even to this day, and probably something that I didn't know coming in and starting the company. We started the company at peak ZERP time.

1:10:28At that time, probably everything seemed like it was going to moon. And there was probably a lot of irrational confidence, I would say, that we shouldn't have had it. Varun, we covered so much ground. What an incredible conversation. I learned so much just sitting here listening and asking you questions. Is there anything else that you wanted to share before or leave listeners with? Any last piece of nuggets or wisdom before I let you go? To be honest, I could give predictions about the space. Probably most of them are going to be wrong. I think the best thing to do is just get your hands dirty with all of these products.

1:10:59and I think one of the most obvious things that's going to happen is in the next year there will be a tremendous amount of alpha for anyone that is able to take maximum advantage of these tools, right? Just imagine how many of your coworkers just don't even know the existence of these tools, don't know what they can do and how much less productive they will be. And I would just say get your hands as dirty as possible, as quickly as possible. And when you say get your hands dirty, basically it's like download Widsurf, start coding, ask it to build things for you. Yeah, build apps, build apps, start using it for maybe even making making mocks, modifying your existing code base.

1:11:36Like there's probably ways in which you could be a force multiplier to your organization and ways in which they never even anticipated. Right. Imagine if you were a product manager that could actually very quickly make edits to the code base and and just start pushing changes yourself. You probably get a tremendous amount of respect from your own engineering peers. You could probably get way more done because of that. But it's just, I feel like there's no sort of ceiling at that point. I think this is such an underestimated point you're making here. There's apps that can build things from scratch.

1:12:06And then there's apps like this that can edit your existing code base. If you're a PM at, like, what's the largest company you work with, like, people-wise? Publicly, I'd say, let's just say JPMorgan Chase. They have over 50 ,000 developers. Okay, so you could be a PM at JPMorgan Chase and be like, I have a problem I need to solve. I want to move this metric. I want to change the step in the signup flow. You just open up Windsurf and tell it to do the thing you want. And then can you push straight to GitHub and do a... Yeah, actually, you could do that too. Merge request, okay. PR? Yeah, I could make a PR for you.

1:12:41This is insane. The future is out of control. Okay, that was such an important point at the end there because I think people may not realize this. They see all these other apps. They're like, oh, Bill likes prototypes. but this is like legitimately something NPM can actually do work with. Yeah. When you think about the people, at least that, I don't know, Lenny, who you respect the most, they're the people that somehow, despite their title, their level of agency and just output just to the, all the way down to the weeds to the highest level strategy is just perfection, right? They know when to go all the way down.

1:13:12And I think, you know, sometimes you see people that talk about roles and they irrationally feel like, oh, because I'm this role, I'm not allowed to touch this. Well, now everything's open season, right? And I think this is an opportunity to almost go all the way down to the weeds and all the way up to the top, right? And just be effective on every level. Unbelievable. All right. Well, with that, we'll leave folks. Varun, thank you so much for being here. Awesome. Thanks a lot, Lenny. What an incredible conversation. Thanks, Varun, and 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.

1:13:49Also, 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.