Varun Mohan: How Windsurf's dehydrated team out-ships rivals

1. 0:00 – 3:57

   Varun’s background

   1. VMVarun Mohan0:00

      (instrumental music) A lot of the bets we're making inside the company are for things that are not, you know, three, four weeks away. We should be cannibalizing the existing state 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 our existing product look dumb.

   2. LRLenny Rachitsky0:13

      How do you know when it's time to hire someone?

   3. VMVarun Mohan0:16

      I wanted the company to almost be like this dehydrated entity. Every hire is, is like a little bit of water, and we only go back and hire someone when we're back to being dehydrated.

   4. LRLenny Rachitsky0:24

      Any other skills you think people should be investing more in with the rise of AI building more and more of our products?

   5. VMVarun Mohan0:29

      The engineers are now able to produce more technology. The ROI of building technology has actually gone up. This actually means you hire more. The best thing to do is just get your hands dirty with all of these products. You could be a force multiplier to your organization in ways in which they never even anticipated.

   6. LRLenny Rachitsky0:45

      (instrumental music) Today, my guest is Varun Mohan. Varun is the co-founder and CEO of Windsurf, which has quickly become one of people's favorite AI coding tools, and is basically the main competitor to Cursor, with over one million users four months in. In our conversation, Varun shares what makes Windsurf unique, why they decided to invest heavily in enterprise sales very early in their history, why agency is gonna be the most important skill for engineers and product builders to build. Also, the story of how they started out as a GPU infrastructure company and realized there was a much bigger opportunity up the stack, and the two pivots that got them to where they are today. He also gives a live demo, advice for being successful at Windsurf, and so much more. There's so much to learn about where things are heading for engineers and product builders in general in this conversation, and I'm really excited to bring it to you. Thank you to everyone on LinkedIn and Twitter and my newsletter community for suggesting great questions to dig into with Varun. If you enjoy this podcast, don't forget to subscribe and follow it in your favorite podcasting app or YouTube. Also, if you become a yearly subscriber of my newsletter, you get a year free of Perplexity Pro, Notion Plus, Linear, Granola, and Superhuman. Check it out at lennysnewsletter.com. With that, I bring you Varun Mohan. This episode is brought to you by Brex, the financial stack used by one in every three US venture-backed startups. Brex knows that nearly 40% of startups fail because they run out of cash, so they built a banking experience that focuses on helping founders get more from every dollar. It's a stark difference from traditional banking options that leave a startup's cash sitting idle while chipping away at it with fees. To help founders protect cash and extend runway, Brex combined the best things about checking, treasury, and FDIC insurance in one powerhouse account. You can send and receive money worldwide at lightning speed. You can get 20X the standard FDIC protection through program banks, and you can earn industry-leading yield from your first dollar while still being able to access your funds anytime. To learn more, check out Brex at brex.com/banking-solutions. That's brex.com/bankingsolutions. This episode is brought to you by Productboard, the leading product management platform for the enterprise. For over 10 years, Productboard has helped customer-centric organizations like Zoom, Salesforce, and Autodesk build the right products faster. And as an end-to-end platform, Productboard seamlessly supports all stages of the product development life cycle, from gathering customer insights, to planning a roadmap, to aligning stakeholders, to earning customer buy-in, all with a single source of truth. And now, product leaders can get even more visibility into customer needs with Productboard Pulse, a new voice of customer solution. Built-in intelligence helps you analyze trends across all of your feedback, and then dive deeper by asking AI your follow-up questions. See how Productboard can help your team deliver higher impact products that solve real customer needs and advance your business goals. For a special offer and free 15-day trial, visit productboard.com/lenny. That's productboard.com/L-E-N-N-Y. (instrumental music)

2. 3:57 – 12:58

   Building and scaling Windsurf

   1. LRLenny Rachitsky3:59

      Varun, thank you so much for being here, and welcome to the podcast.

   2. VMVarun Mohan4:03

      Lenny, thanks for having me. A long-time listener.

   3. LRLenny Rachitsky4:05

      Oh, I really appreciate that. I'm so excited to have you here. I feel like just you guys have become this overnight success, which was definitely not an overnight success, but I feel like I've been hearing about Windsurf more and more as people's favorite AI tool, and I just don't think people know the story behind Windsurf, behind Codium, the company that you built. So, I thought it'd be good to maybe just start there, and have you just briefly share the history of Codium and how Windsurf emerged out of Codium?

   4. VMVarun Mohan4:31

      Yeah. So, the company was actually started close to four years ago. Uh, as you, as you know, AI coding was not a thing four years ago. ChatGPT was not out four years ago. At the time, we actually started out building GPU virtualization and compiler software, right? Uh, before this, I worked in autonomous vehicles. My co-founder, who I'd known since middle school, uh, worked on ARVR at Meta. And for us, we believed deep learning would touch many, many industries, right? It wouldn't just touch, uh, like sort of autonomous vehicles. It would touch financial services, defense, uh, healthcare. And we believed these applications were hard to build, these deep learning applications, so we made it possible for you to effectively run these complex applications on computers without GPUs, and we would handle all the complexity of being able to actually run the workload on the GPUs for you, right? And we were able to optimize these workloads a ton. And then the middle of 2023, 2 rolled around, and we had a couple million in revenue, and we were managing upwards of 10,000 sort of GPUs. We had eight people. At the time, we were free cash flow positive. Uh, but I think what we felt was when- once these generative models started to get very good, uh, we sort of felt a lot of what we built was not as valuable, and this was like a very, very hard moment for us at the company. We were only eight people at the time. But we felt, hey, would people be training these very bespoke sentiment classifier models anymore that were like very, very custom models? Or would they just ask GPT-N, "Is this a positive or a negative sentiment?" Probably is gonna be the latter, right? And in a world in which everyone was gonna run generative AI models, why would an infrastructure company be a differentiator? Because everyone is going to run the same kind of infrastructure down the line. So instead, what we decided to do was we believe...... generative AI was almost going to be like the next internet. And in that case, what we should go out and do is build the next great apps like, uh, Google, like Amazon. And we vertically integrated and actually took our infrastructure, our inference infrastructure, to go out and build Codium, uh, at the time. And at that time, we were early adopters of GitHub Copilot, and we thought the coding space was gonna get tremendously disrupted in the next coming years. So we actually took our infrastructure, we ran our own models in massive scale, we even trained our own models. In the very beginning, it was very, very simple. It was purely an autocomplete sort of model, right? Which basically means that as the user was typing, we'd complete the next one or two or three or four lines of code. But we provided the product entirely for free in all the IDEs that developers coded, right? That meant VS Code, JetBrains, Eclipse, Visual Studio, Vim, Emacs. And the reason why we were able to build it for free was because of our infrastructure background. We were able to optimize these workloads a ton. And, uh, I guess very quickly after that, some large businesses also wanted to work with us, and we built out the kind of this enterprise motion to, to work with these large companies like Dell, JP Morgan Chase. And for them, the bigger thing wasn't just, hey, could we autocomplete code or could we chat with the code base? It was, could you offer us a secure offering that was also personalized to all the private data inside the company? So we took our infrastructure and made it so that we invested a ton in making sure that we deeply understood these large companies' code bases, right? And that's what we were working on until six months ago. And it, it's not that we've stopped working on that, but basically what we realized six months ago was we were getting limited by the IDEs that we were already working in. So VS Code, which is a very popular IDE, had a ceiling for the AI capabilities we could showcase our users. And because of that, we decided to go out and fork VS Code and build our own IDE with some of these new agentic capabilities. And over time, in the last couple years, the model capabilities have also been growing exponentially year over year. And that's, that's sort of where we are right now. Like I, I skipped a lot of pieces there. Uh, but, but that's, that's where we've landed.

   5. LRLenny Rachitsky8:05

      There's so many interesting threads there. One is just, there's always this question of just where value will accrue in AI. And it's so interesting you guys started almost at the bottom layer of infrastructure GPUs, and then you went to what people, uh, call GP- a GPT wrapper. Not, not actually, but, uh ... So I guess any just like lessons there, just thoughts on just where you think value will end up in this world of AI and the stack of AI tools.

   6. VMVarun Mohan8:28

      Maybe I can start by just saying like, one thing about startups that I, that I think are like really true. It's very unlikely the first thing that you believe you should go work on, uh, is gonna be the right thing. Which is like a very hard thing to kind of wrangle with being a startup founder, right? Uh, you need to kind of be irrationally optimistic that what you're gonna do is going to be differentially important, because otherwise, why would you go out and do what you're doing? And if it's i- if it's, if it's obvious, then a bigger company would've already done it, right? Uh, but then you also need to be really, really realistic, because most ideas that are, uh, that are I guess, uh, non-conventional are usually bad ideas, right? Uh, so, so it's, it's this weird kind of tightrope you need to, you need to kind of, uh, you know, kind of balance on top of, where you're kind of pushing for a future that you believe is true, but all the while you're getting new information. You need to kind of kill the beliefs that you had. And if I were to start with the infrastructure piece, we first went in with the assumption that model architectures were gonna be really, really heterogeneous. Working from an autonomous vehicle background, there were many different types of model architectures out there. There were convolutional neural networks, graph neural networks, recurrent neural networks, LSTMs, uh, sort of lighter neural nets with, with frustum point networks, right? And there were maybe like tens of architectures we were dealing with. And at that point we were like, the complexity of this is so high that it's very clear if someone offloaded the complexity, there would be a lot of value. Fast-forward to the middle of 2023, everything looks like it's gonna be a transformer. So now our hypotheses are just wrong. So at this point then, most of the value is probably not gonna accrue at purely the, at least this is our belief, at the infrastructure layer. It's gonna accrue somewhere else. Where is the layer that you can actually differentiate on? And we believe the application layer is a very, very deep layer to go out and differentiate on, right? What are the number of ways we can build better user experiences and better workflows for developers? We think there's effectively no ceiling on that, on how much better we can make the lives of developers basically.

   7. LRLenny Rachitsky10:22

      You touched on the second thread that I thought was really interesting here, is just how you guys pivoted, uh, from ideas that were working. Like you were making money, people loved it. You said you had millions of dollars of ARR or revenue, and then you're just like, no, we're gonna completely change the business. So the question there is just like, how do you, what have you learned about knowing what to follow? And one thing I heard there that was really interesting is just once your assumptions change about, that you built your idea on, it's time to rethink this idea and maybe try something else.

   8. VMVarun Mohan10:47

      You know, I, I think the way we sort of think about this is, you know, e- even when we're working right now, we just accept that we're gonna get a lot of things wrong. We're just gonna get a lot of things wrong. Um, obviously that's a very big moment because that was a bet the company moment in the sense that we basically said, told our investors, "Hey, you know, we're making money on this." We had already raised $28 million of capital and we were just like, "Hey, we're just gonna pivot entirely from this." And we did that overnight, right? This wasn't this thing where we just said, "Hey, maybe a quarter, one or two quarters," because one of the things we knew that's very important for startups is focus. And if you're, if you're trying to do another thing that you think is big and you're focused on something that you don't believe is valuable, you're guaranteed gonna fail at the thing you think is gonna be big, right? So that's like a, that's a very obvious thing, uh, there. But I think once you go in with the assumption that a lot of your hypotheses are gonna be wrong, but you will do the most concentrated work possible to go out and validate these hypotheses, and you won't be in love with your ideas. Like I think ideas, it's awesome when you have a great idea, but you should never be too in love with your ideas. And you have an organization that is very truth-seeking. I think a lot of people at the company have had their ideas tested over and over again. Even just building Windsurfer, that is not a complete company pivot, but that's a big decision that we made at the company. You kind of need to make some bets. And sometimes you're wrong and sometimes you're right, but if you have an organization that comes out and you feel like morale is not gonna be low if you made the wrong decision, um, that- that's the best, right? That means you have optionality for the rest of time. And, and Lenny, one thing that I try to tell the company...... about this, uh, is this year the total amount of engineering output we will have is much larger than the engineering output we've- we've had since the beginning of the company's creation till now. So that almost means every year is a new lease on life for us, right? It's almost a new way for us to test out an entirely new set of hypotheses, and maybe we were wrong about our original hypotheses, like, in the- in the first place. What- what makes us more smart than everyone else to be right, you know, more times than them?

   9. LRLenny Rachitsky12:46

      That's so empowering. Makes me think about, uh, Uri Levine was on the podcast, co-founder of Waze, and he has this phrase that he- he wears on his shirt, his book is called Just Fall in Love With the Problem, Not the Solution. And that feels like that's exactly what you're describing.

3. 12:58 – 17:11

   Windsurf: The new purpose-built IDE to harness magic

   1. LRLenny Rachitsky12:59

      Okay, so let's talk about Windsurf. Uh, what's the simplest way for people to understand what is Windsurf?

   2. VMVarun Mohan13:04

      Yeah, so Windsurf is an IDE, right? It's an application to go out and- and build software and build applications. Um, the- the, you know, the crazy thing is a lot of people who use the product don't even probably know what an IDE is, uh, which is- which is crazy, and we'll get in- we'll get into that in a second. But why did we go out and build Windsurf and what is Windsurf, maybe? Why couldn't we have just done this on top of conventional IDEs like Visual Studio Code? So maybe just to get into this a little bit, as we saw that AI was getting more and more powerful, the way people go out and build technology, we thought the interface for that was gonna change remarkably. It was not going to be a conventional pure text editor where u- the user is writing a handful of lines of code or most of the code and the IDE provides, uh, like maybe some basic feedback on what the user is doing right or wrong. And the basic feedback could be, "Hey, there's a bug in your software or compiler error in your software." It could do much more, right? It could actually go out and- and modify large chunks of code. And one of the key pieces that we recognized was with this new paradigm with- with AI, AI was probably gonna write well over 90% of the software, in which case the role of a developer and what they're doing in the IDE is maybe reviewing code. Maybe it's actually, like, a little bit different than what it is in the past, and we'll see this very soon with- with Windsurf, um, maybe, you know, when you're using the product, actually a good chunk of the user's time is actually reviewing what the AI is outputting. So we needed to build custom review flows into the IDE to actually make it so that it- it was easier to actually go out and do that, right? Because the developer's not spending all their time writing code, and this is the fundamental premise on why we built the product. We thought we were gonna get limited a ton if we had very, very basic UI out there. And I'll give you even a simple example here. We have this autocomplete product, right, that completes a handful of lines of code. Now, we've actually launched this offering called Windsurf Tab that basically shows you refactors as well, and these refactors are almost inline refactors, and we were able to build a custom UI for that in Windsurf. But in VS Code, we needed to, because of the access to the APIs, we needed to dynamically generate images right alongside the user's cursor, uh, because we just didn't have access to the capabilities to showcase and edit properly, and what we realized is immediately by porting over to Windsurf, our acceptance rate tripled. Same ML models, it just tripled. So what that I guess gave us confidence in is, yeah, like, you could argue technology is very important, and I think technology is very important, but if our users are getting very little value from the technology we're sort of building, you need to really clarify, maybe we do need to build a new surface and interface, and that's what Windsurf is.

   3. LRLenny Rachitsky15:39

      So the big bet you took there, just to make this super clear, is, hmm, you were initially working within existing IDEs that everyone was f- familiar with, and then it was like, "This isn't gonna get us where we need to go. We're gonna try to convince people to switch to something completely new because it's gonna be so much better. It's our own I- IDE." Uh, I think pe- I think maybe people may not recognize just how risky that is, convincing engineers to use something completely new. That's a huge deal.

   4. VMVarun Mohan16:02

      Yeah. No, of course. And one of the cre- key pieces that I just, maybe, Lenny, that would be important to share is we... A lot of our developers do use Visual Studio Code, uh, but there are lots of people that write in languages like Java, uh, sort of, uh, C++ and so on and so forth, and they might use the JetBrains family of IDEs that, like IntelliJ, and for us, we're actually still committed to building on those platforms, right? We just felt though that one of the dominant IDEs, which was Visual Studio Code, was limiting the- the sort of user interface that we could give to our actual customers.

   5. LRLenny Rachitsky16:35

      What is the current state of traction for Windsurf? You hear all these crazy numbers about all the competitors in your space. What can you share there for folks just to know?

   6. VMVarun Mohan16:43

      Yeah. So maybe a handful, we launched the product, like, a bit over four months ago, and in that period of time, over a million developers have tried the product, and obviously we have many hundreds of thousands of monthly active users, uh, right now.

   7. LRLenny Rachitsky16:54

      I love how, like, these days, like, "Oh, a million. No, no big deal." Like, it's just the numbers are absurd these days. Like, we're just getting used to just 100 million AR here, million users in four months there. It's just like, oh, of course, d- how could you not have that? (laughs) Uh-

   8. VMVarun Mohan17:09

      Yeah.

   9. LRLenny Rachitsky17:09

      ... but that's absurd. It's just, like, an insane

4. 17:11 – 21:30

   The future of engineering and AI

   1. LRLenny Rachitsky17:11

      time right now. You touched on something that I wanted to get to later, but I may as well bring it up now, the question of just how engineering will change in the future. You throw out the stat that like 90% of code is gonna be written by AI in the future, Dario from Anthropic recently said the same thing. Uh, you guys have a really interesting glimpse into just how things will look in the future. So I guess the question just, how do you think coding specifically will look in the next few years? How different will it be from today?

   2. VMVarun Mohan17:39

      I think when- when we think about what is an engineer actually doing, it probably falls into three buckets, right? Um, what should I solve for, how should I solve it, and then solving it. And I guess, like, everyone who's working in this space is probably increasingly convinced that solving it, which is just the pure, "I know how I'm gonna do it," and just going and doing it, AI is going to handle vast majority, if not all of it, right? Um, in fact, it probably actually, with some of the work that we've done in terms of deeply understanding code bases, how should I solve it is also getting closer and closer to getting done, right? If you deeply understand the environment inside an organization, if you deeply understand the code base, how you should solve it, given best practices within the company also gets solved. So I think what engineering kind of goes to is actually what you wanted engineers to do in the first place, which is, what are the most important business problems that we do need to solve? What are the most important capabilities that we need our application or product to have?... and actually going and prioritizing those, and actually going and making the right technical decisions and go out and doing it, right? And I think that's where engineering is probably heading towards. Now, does that mean that no one needs a CS degree? I think, I think that's maybe a little bit overplayed, uh, a little bit, just because, you know, maybe, maybe here's, here's maybe my argument for that. A lot of developers nowadays that build full stack applications, at least until, like, a handful of years ago, they probably went to college and took an operating system course, right? And in theory, they're not really, like, playing around with the operating system, like the kernel scheduler, like, very frequently. But do those principles help them in understanding why their applications are slow? Do they help them in understanding why, why some design decisions are better than the other? Yeah. That makes them a much better engineer than, than another engineer. And I think that idea and the understanding of what's going on at the bottom will make a good engineer even better, right? Um, but also at the same time it empowers a bunch of people that never understood all of those things, how to actually build as well, which is another remarkable sort of thing that fl- fell out through this whole process.

   3. LRLenny Rachitsky19:33

      I don't know if you have kids, but just, like say you had kids or if you had a niece or nephew going into college, let's say. Would you suggest they do soft- they do computer science, or would you suggest, like, you're not gonna have a good time if that's the career you choose right now?

   4. VMVarun Mohan19:47

      Yeah, I think, you know, maybe I think back a little bit. So I, I went to MIT. A lot of us at the, at the company went to MIT together, uh, on the engineering team, and, uh, I, I think, like, when I think about what we learned the most at, at, uh, for engineering or computer science, it was not exactly, like, how do you write code? Right? That's maybe... that is, like, almost a given that you can, you can kind of write code after, after going to college. It's more like the principles of how you think about a problem and how you break it down, right? And how you solve it in an interesting way, right? So an example that, of a class that I really enjoyed was our distributed systems class. And there, you're kind of reading through literature and understanding how, how some design decisions were kind of made. And I think it's more like a problem-solving kind of course, right? And a, uh, a major. It's a major of how you solve problems given some constraints of how, you know, how computers today function, right? Like, here's the speed at which memory sort of operates, here's the speed at which, you know, here's how much computation you can do in one, one cycle or one second. And, and based on that, you can make some trade-offs and solve a, solve a problem. So I, I don't know if, if i would say that you shouldn't go get a computer science degree. I think computer science is almost synonymous with problem-solving. In that case, I think it's pretty valuable. Is everything you learn in your computer science degree useful? I'd say a lot of things that I learned in my computer science degree are not useful. I'll give you an example. I took a parallel computing class in Julia, and I don't think Julia's a very popular programming language anymore. Am I very sad that I took the class? No, the principles of parallel computing are still very useful, I would say today.

   5. LRLenny Rachitsky21:12

      So what I'm hearing is skills that you still want to build, whether it's computer science or maybe some version of computer science, is, uh, kind of like building the mental model of how computers and systems work. Parallel-

   6. VMVarun Mohan21:23

      That's right.

   7. LRLenny Rachitsky21:23

      ... processing, memory, hard drives, internet, things like that, okay. And then there's just, like, problem-solving skills, being able to solve

5. 21:30 – 23:07

   Skills worth investing in

   1. LRLenny Rachitsky21:30

      interesting problems. Is there any other skills you think people should be investing more in with the rise of AI building more and more of our products?

   2. VMVarun Mohan21:37

      I think one of the things that's maybe a little bit undervalued is this kind of agency piece, and I think about this a lot, which is, uh, you know, you, you have a lot of people that could go through college and go through school and they're basically told exactly what to do on a P set, and, you know, they're given these very, very, I would say, uh, well-defined paths that they need to take. And I think, I think maybe in society and just school, we, we don't prioritize g- uh, how do you, how do you make sure you get people with real agency that want to build something, right? Uh, like, 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, for this one website. Um, and I think that's maybe a skill set that is undervalued, uh, just right now, probably in the last, you know, maybe 10, 10 years or so, and I think that's gonna 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 gonna die. The company is just gonna 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.

   3. LRLenny Rachitsky22:52

      I love how you phrased that. If we don't, uh, do crazy things and innovate, we're gonna die.

   4. VMVarun Mohan22:57

      Yeah.

   5. LRLenny Rachitsky22:57

      That, that would be a great title for this podcast episode, and I think, and it's 100% true. There's just (laughs) a lot of crazy things happening and a lot of innovation happening and if you can't keep up, uh, you'll die.

6. 23:07 – 35:22

   Hiring philosophy and company culture

   1. LRLenny Rachitsky23:07

      So 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?

   2. VMVarun Mohan23:22

      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, right? That'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 transform the way software gets built... I- we've mentioned this inside the company, our goal is to reduce the time it takes to build apps and technology by 99%, right? It is a, it is a tremendously sort of ambitious goal, and it's, it's not possible for us to be a 10, 20, 30, 40-person engineering team in the long term and actually satisfy that goal. We think it's, 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, that's the, that's the dream. Um, 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. Unless we are underwater there, we will not go out and hire, hire someone to go out and work, work for that. Right? And the reason for that is, I actually think this is like, uh, this is a, this is a feature, right? When, when you hire for a role and you already have enough people there, what you ha- you know, you get a lot of weird politics that ultimately ends up happening. And it's not because people are bad people. I don't... 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 should, they will go out and figure out something else to work on. And 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? Uh, for me, I would like to see everyone just almost like, be, 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, and hire someone. And one of the analogies I like to give is, we, I want, uh, the company to almost be like this dehydrated entity, right? And every hire is a- is like a little bit of water, right? And, and we only go back and hire someone when we're, when we're back to being dehydrated.

   3. LRLenny Rachitsky25:57

      I love this metaphor so much. Uh, and it sounds, uh, it sounds painful. It sounds painful that you need to be underwater and raising your hand, "I'm about to die, I'm 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 the, just that side of it.

   4. VMVarun Mohan26:16

      Yeah.

   5. LRLenny Rachitsky26:16

      'Cause I think it could sound like, "This is terrible, I don't wanna work this way."

   6. VMVarun Mohan26:19

      You know what I actually think, Lenny? It's, it's, uh, it, it's really good for a handful of reasons, which is that a lot of the pe- we respect and trust the people that work at the company, so this forces ruthless prioritization. You 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 gonna, uh, 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, you know, 10 things kinda well. You win by doing, like, one thing really well, and maybe you fail nine things. This is the thing that I've told the company. This is very different than school, right? In school, you optimize for your total GPA. But for companies, I just need to get an A+ in the one class that matters, and then I can get an F in all the other classes. Uh, and an F in all the other classes doesn't mean, you know, being, you know, just doing illegal things. That, that (laughs) basically means you just deprioritize things that don't matter. You know, that actually forces this organizational prioritization that is just really, really good, right? And, you know, Douglas and I, w- 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 do those, uh, what's gonna ultimately happen? Right? It's almost a forcing function for ruthless prioritization to have fewer people, or people that just, that are just underwater internally at the company.

   7. LRLenny Rachitsky27:46

      Everyone, uh, listening that works at a big company, uh, knows exactly what you mean when you describe s- 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 wanna show impact, they wanna, he- do well on their performance reviews. Uh, uh, that's just the nature of, of too many people at a company. And so, I think this all really resonates. To cl- even get even deeper on just what it looks like when someone's underwater to tell you it's time to hire. Is it just someone coming to you, "Varun, we need, I need someone on this team. This is just not possible." Like, what does that look like even more practically?

   8. VMVarun Mohan28:16

      Yeah. It's basically along those lines. It's that, hey, there's some pressure to get something done in a, in a short period of time. By the way, one of the things that we do believe, though, for software, if you wanna do great things, um, it's not possible to just say, "Hey, I wanna get it done in one month." If it is, like... Because y- 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? Like, 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 kinda stupid to believe that. So, I think basically it comes down to that person coming out and being like, "Hey, look, like-"

   9. LRLenny Rachitsky29:02

      Mm-hmm.

   10. VMVarun Mohan29:02

       "... I don't have enough time to do X." Us having a conversation to be like, "Okay, uh, what can you do then?" And if the answer is, "I, I can only do less than that," then maybe we make a decision actually, "Oh, wow, that's great. Maybe we actually should deprioritize Y." 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 wanna do a lot of things, right? There's an urge to do a lot of things, but if you, if we are forced to make a decision constantly on like, "We cannot do X," it's very clarifying. It's very clarifying, uh, 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, uh, really, really quickly either. Um, so I think, um, 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, we don't believe you should be doing this other thing." Um, and it's also clarifying for us, because we can also get on the same page with them, right? And sometimes we just kinda 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 that are directly responsible individuals for these projects, um, 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.

   11. LRLenny Rachitsky30:35

       How many people do you have at Codium at this point?

   12. VMVarun Mohan30:38

       So we have, we have close to 160 people and the engineering team is over 50 people right now.

   13. LRLenny Rachitsky30:42

       Awesome. Oh, what uh, what uh, what's the other bigger functions? So interesting.

   14. VMVarun Mohan30:45

       So we have go to market. We have uh-

   15. LRLenny Rachitsky30:47

       Okay.

   16. VMVarun Mohan30:47

       ... yeah. Yeah.

   17. LRLenny Rachitsky30:48

       Oh, right. Okay. I want to talk about that, the sales learning that you guys had. Okay. Uh, well 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?

   18. VMVarun Mohan31:01

       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. Um, I 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 uh, 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?" 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, uh, what's the differentiator going to be? Are you just gonna 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 uh, and I think the, the thing about a person that is, is not pulling their weight that's bad is not, it's not the productivity, right? At some point when the company becomes many hundreds of engineers, I'm not gonna 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 gonna feel like you should care?

   19. LRLenny Rachitsky32:21

       Not too much.

   20. VMVarun Mohan32:22

       Exactly. So for us, for us I think that's what we more care about, right? We have a culture where, where it's like, it's very collaborative. Uh, 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.

   21. LRLenny Rachitsky32:35

       So the question you asked there just basically is how hard are you willing to work? How hard-

   22. VMVarun Mohan32:39

       Yeah.

   23. LRLenny Rachitsky32:40

       ... do you want to work? And I, I know some people there, there's, you know, there's a whole group of folks that are just like work/life balance. I don't wanna, how dare you asking me to work crazy hours. And I, I, I love just the filter up front of w- if you work here you will work really hard, 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.

   24. VMVarun Mohan33:02

       Yeah.

   25. LRLenny Rachitsky33:03

       Uh, you said at some point earlier that your, uh, engineering pass rate is, you said it was like 0.6% of candidates, something like that?

   26. VMVarun Mohan33:10

       Yeah, it's probably post or take home it's probably that actually.

   27. LRLenny Rachitsky33:13

       Oh, man.

   28. VMVarun Mohan33:13

       So the take home itself filters, uh, probably another, you know, 10, 15x on top of that.

   29. LRLenny Rachitsky33:19

       Here's a question-

   30. VMVarun Mohan33:19

       Yeah.
7. 35:22 – 39:37

   Sales strategy and market position

   1. LRLenny Rachitsky35:22

      Okay, let's talk about this go to market sales experience that you guys had. So you started without obviously, like most people, start- 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 'cause that's, that's really unique I think, that you guys have a large sales team and go to market team.

   2. VMVarun Mohan35:40

      Yeah. We actually made this decision pretty early in the company's history, I would say. Like, we hired our VP of sales, uh, over a year ago actually. And the go to market team is now over 80 people, uh, inside the company. So it's a pretty sizable function, um, 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 De La Torre who used to be the CRO of MongoDB. And I think for us we never viewed enterprise sales and sales as like a very negative thing. I think this is like a 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, it's, 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. So ultimately speaking, if it was hard for me to sell the product incrementally, I didn't know how we could make that uh-... into a process that we could then go and scale. Right? If I couldn't, if I can do one per, like, I didn't know how we could take the revenue of the business from a couple million to hundreds of millions, and I, let alone even tens. So, if I didn't know how to do that, how could I go out and hire someone and make them scale it up? Um, on the other hand, for Codium, very quickly, a lot of large enterprises sort of reached out to us. And from that alone, in, in the middle of sort of 2023, uh, we started, I guess, me and a handful of other folks at the company, started selling the product, and 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 this space. So, by the end of 2023, we actually hired our, our VP of sales, and, uh, and very quickly after that, scaled a, a sales team. And, uh, yeah, I mean, I mean, look, if you wanna sell to the Fortune 500, it is very hard to do that purely by swiping a credit card.

   3. LRLenny Rachitsky37:36

      Let's talk about Cursor. I ha- I don't want to spend too much time on competitors, but that's what-

   4. VMVarun Mohan37:39

      Yeah.

   5. LRLenny Rachitsky37:39

      ... everyone's always thinking about when they think of you guys. You guys are kind of the leading players, I think, in this space. Also, 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'll win in the space long term?

   6. VMVarun Mohan37:53

      So, I think maybe, maybe a handful of things that I could, I could share. So, on the product side, I think we've invested a lot in making sure code-based understanding for very large code bases is, 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, JPMorgan Chase. Companies like Dell have singular code bases that are over 100 million lines of code, right? So, being able to understand that really, really quickly to make large-scale changes is something that we 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 background to go out and do that. That's maybe one.

   7. LRLenny Rachitsky38:38

      Let me actually follow that thread, 'cause I think people may misunder- underestimate just how big of a deal that is. So, when we talk about, we had the founders of Bolt and Lovable on the podcast. So those products, they build something from scratch, they build, they write the code for you. So, that versus just loading, say, Windsurf on your million lying code base, say, at Airbnb or Uber, like, it understanding what the hell you have (laughs) 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, is you guys started there actually, and then Windsurf is now building on that advantage.

   8. VMVarun Mohan39:15

      That's right, yeah. So, we, that's, like, a big thing that we spent a lot of time on, which is just understanding sort of what the, what the code base is doing. And 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, um, you know, in a, in a bit here.

   9. LRLenny Rachitsky39:30

      Awesome.

   10. VMVarun Mohan39:31

       Um, the second key piece probably is, we're not only tied to the, uh, to Windsurf, actually.

8. 39:37 – 41:20

   JetBrains vs. VS Code: extensibility and enterprise adoption

   1. VMVarun Mohan39:37

      This is probably, like, a weird statement given, given we are talking about Windsurf, which is that, actually, we're pretty focused on supporting IDEs like JetBrains, right? Uh, you know, JetBrains or IntelliJ has over 70% to 80% of all Java developers code in, in JetBrains, uh, based IDEs, right? Um, 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. VS 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 IDE, 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 large, a lot of large enterprises that have 10-plus thousand developers, where over 50% of the developers are on JetBrains. Right? 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, right? So, it's a very, very large company. So, for us, that's another key piece. We actually, like, want to meet developers sort of where they are, and if they, if they use a different platform, we'll, we'll work on that too. The third key piece, and this probably sounds, uh, another key piece for enterprises is, um, we, we work in, like, a lot of very secure environments, right? Uh, we have FedRAMP compliance, right? We have, which means we can sell to, like, very large government entities. Uh, we have a hybrid mode of actually using the product, which means that all the code that lives, that is, like, indexed, it actually lives on the tenet of the user, right? Code is one of the most important I- pieces of IP for the company. So, 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. Uh, but that's, part of it is because of the history of how we got here

9. 41:20 – 42:46

   Live demo: building an Airbnb for dogs with Windsurf

   1. VMVarun Mohan41:20

      in the first place.

   2. LRLenny Rachitsky41:21

      Okay, Varun, enough teasing. Let's do a live demo of Windsurf 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.

   3. VMVarun Mohan41:33

      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 file, it's, 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.

   4. LRLenny Rachitsky41:56

      Beautiful. Beautiful mock-up, by the way. I love that this is, like, all you need.

   5. VMVarun Mohan41:59

      This is all you need. This is all you need. Uh, so basically, what we're gonna do is, we're gonna say, "Hey," um, this, one of the cool parts about Windsurf is it can actually work in an existing project already, right? 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, it 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, see what it's going to do. But while we're doing that, um, let's, let's continue the conversation.

   6. LRLenny Rachitsky42:45

      Awesome.

10. 42:46 – 46:38

    Tips for using Windsurf effectively

    1. LRLenny Rachitsky42:46

       Okay. So first of all, the...You kind of start, so you open up Windsurf. You had a boilerplate react project ready to go, and 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. Amazing.

    2. VMVarun Mohan43:02

       That's right. That's exactly right, yeah.

    3. LRLenny Rachitsky43:04

       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. So you could sit next to every single new user that, uh, 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?

    4. VMVarun Mohan43:25

       Tip number one is just be a little bit patient, and both patient and explicit, right? Uh, 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- 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? Uh, because then if it's wrong, it's gonna, like, basically destroy 20 files. And 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 auto-complete, right? When you use a product like auto-complete, 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. Or- or, uh, and the times that I do, I know how to get value from it, right? And you also know beforehand if a- if a- if a- if a sort of command that you write is very complex, you just expect, hey, like the auto-complete is not gonna work for it, right? So I think it's almost like a, like understand what the hills and valleys of the product are. The crazy thing is every three months that kind of gets changed and re-evaluated, right? It almost becomes the case that- that it becomes materially better than it was in the past. So I think, I think maybe patience and being explicit are- are maybe the two important key pieces that I would- I would tell users.

    5. LRLenny Rachitsky44:59

       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 you can be. And there's kind of this, like, gut feeling you start to build over time.

    6. VMVarun Mohan45:12

       That's right, yeah. Um, and with that, it feels like we have a- an actual preview.

    7. LRLenny Rachitsky45:18

       Oh. (laughs)

    8. VMVarun Mohan45:18

       And guess what? We have a- a nice-

    9. LRLenny Rachitsky45:20

       Cute dogs.

    10. VMVarun Mohan45:21

        ... a nice dog app. And one of the cool parts is that we've also done beyond just- just modifying code is actually being able to point to different pieces, and I guess I could just kind of say, uh, I could point to different elements and say, hey, like, make the background... And I'm... This is not great- 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, and 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- app world, right? You don't even maybe even need to look at the code. Granted, this looks hideous, but, uh, but in some ways, (laughs) if I wanted to, I could go out and do that, right? (laughs) Um-

    11. LRLenny Rachitsky46:09

        This is what happens when there's no more designers like you Yeah, when there's no more designers. Like- ... Mickey Wish tour. This is... (laughs)

    12. VMVarun Mohan46:12

        ... maybe the answer- the answer is, like, when you ask me, "What should people be doing?" They should study great taste, uh, having great taste, because I think taste is also very, very hard, all right? Um, but maybe the other key piece, Lenny, that I wanted to showcase here is, like, obviously you could keep going here. Like I could- 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, uh, changing components. But one of the cool pieces is the AI,

11. 46:38 – 48:56

    AI’s role in code modification and review

    1. VMVarun Mohan46:38

       um, there- there's like an AI review flow as well, right? Which is kind of like what I was saying, the goal of AI has 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- is to actually review a lot of the code that the AI has generated. And granted right now during this- during this podcast, I'm not gonna 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 it, 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- and say Title String, right? And that's what I'm gonna do, I'm just gonna 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. Like, our goal here is to have this almost flow-like state where everything the user has done, the AI also knows, and it- 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? And 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- no bug in the app, right? It still loads properly. I can obviously tell it to do even cooler things like make the- make the app retro, right? Um, 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, you know, 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. So it should add leverage to not only non-developers that are just purely building apps, but also developers that are just hands-on-keyboard too.

    2. LRLenny Rachitsky48:44

       Amazing. That's... 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, uh, reference that in your ask of here's what I want changed. Uh, I didn't know that was a feature, and that is extremely cool.So

12. 48:56 – 54:03

    Empowering non-developers to build custom software

    1. LRLenny Rachitsky48:57

       interestingly, so having just looked at Lovable and Bolt and Repl income, and apps like that, it's basically doing all the things those apps do. Oh, wow, there's the retro (laughs) version. That's, that's good.

    2. VMVarun Mohan49:08

       (laughs)

    3. LRLenny Rachitsky49:08

       I like that it built on your red and made it really nice, actually.

    4. VMVarun Mohan49:11

       Yeah. Actually, the red looks way better now.

    5. LRLenny Rachitsky49:12

       Yeah, the little green button. This is great.

    6. VMVarun Mohan49:15

       (laughs) Very cool.

    7. LRLenny Rachitsky49:15

       Okay, so then, 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. The 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 it other reasons?

    8. VMVarun Mohan49:39

       You know, 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 wanna wait. But totally, actually most of the users within, within, uh, of the product, probably zero to one build these apps. And if I can say one interesting thing is when we launched Windsurf, actually, eh, we tasked everyone at 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, 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, so. 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.

    9. LRLenny Rachitsky50:44

       That is incredibly interesting. Uh, you don't need to name company names, but I guess what's a space you're least bullish on that you think is gonna have the most problem here with company, people building their own version of these sorts of products?

    10. VMVarun Mohan50:56

        You know, 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. And I think sales products are an example of one of these things, right? You, and, and maybe this is a, I don't wanna 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 investment class legal, legal software product, or finance software product. It's very, very hard for us to do, 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. And our company's unwilling to do that. So previously, we would go out and buy the technology, right? Uh, because there would be no alternative. But now, one of the crazy things is that, uh, 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, why were these software companies able to exist, uh, 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. But that has now changed entirely. Now they can.

    11. LRLenny Rachitsky52:22

        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 could just..." But now it's, like, five minutes of time. Like-

    12. VMVarun Mohan52:28

        It's five minutes and maybe even more custom to your, to your system.

    13. LRLenny Rachitsky52:32

        Mm-hmm. Mm-hmm.

    14. VMVarun Mohan52:32

        Right? Like, how many times have you bought a piece of, bought a software and you b- 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.

    15. LRLenny Rachitsky52:43

        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, uh, build me a Airbnb for dogs. Here's a stupid mock that I made, like, with some boxes." (laughs) Like, that's, that's almost like a bad PM, uh, 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 s- go-to-market folks building their own things, it's like they don't need to know anything (laughs) 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.

    16. VMVarun Mohan53:20

        Which, which 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? Like, 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 say of the saking, uh, 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.

    17. LRLenny Rachitsky53:47

        I think, uh, even more acutely for product folks listening to this, uh, it's the, the salesperson coming to you being like, "Hey, I want this thing. It's gonna help me with my sales team." And you're like, "I don't have a million things to build. I don't have time for this." And so that problem goes away, which I think will make a lot of product leaders really

13. 54:03 – 1:00:43

    Training Windsurf

    1. LRLenny Rachitsky54:03

       happy. The model that this is sitting on, is it Sonnet?

    2. VMVarun Mohan54:08

       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-4O is also good. But the crazy thing is what we try to do is we try to make the, the Anthropic-based model or a Sonnet model, we 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. As you could see, the agent needed to understand what the rest of the code base ultimately did. Uh, we actually make sure we run models to actually chunk up the entire code base and understand the code base, uh, so that obviously it would not be a good idea if we had 100 million line 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 actually larger than the largest context lengths right now. But you also wouldn't want to do that from, like, a cost and latency standpoint too. So 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, and the reason why you would want to do that is it's A, faster, and B, also, that model can actually have more of the code base in context too. So, it can be better at applying changes than even Anthropic's 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? How do we build the best product possible and how do we, 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 gonna be good at, good at a task and we think the open source is better or Anthropic is better, we'll go and just use the open source or Anthropic.

    3. LRLenny Rachitsky55:47

       And so the models you guys are building, those are built on open source models that people have released?

    4. VMVarun Mohan55:51

       Yeah. Interestingly, the one that does retrieval is actually completely pre-trained in-house, that actually does that. But yeah, for, for a lot of different pieces, it's, it's based on open source. For... Interestingly, for the one that does, uh, that does the edits and auto-complete, that is also in-house. Like, as you're typing, we actually do some auto-complete related stuff. I'm happy to show that, but I think a lot of users are familiar with that capability. Um, 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 gonna be best at it, we should not, just for the sake of ego, go out and train something.

    5. LRLenny Rachitsky56:23

       This may be getting too technical, but just is there anything interesting around what you train on?

    6. VMVarun Mohan56:27

       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? It'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 auto-complete, 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, typing, um, some code in a code base. Uh, the code's gonna be incomplete as you're typing it, right? It's not gonna 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. So 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 or 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 preferencing 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? So 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 a g- I, 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, is very gnarly and here are some changes that need to get made, and we, we know the evolution of the coder or we've seen the evolution of code across millions of users, um, we feel like we could do a great job of that.

    7. LRLenny Rachitsky58:03

       I think what's interesting about this is this is another d- uh, differentiator/moat for companies that end up winning in this space is you just have more and more of that data than other companies if you're ahead.

    8. VMVarun Mohan58:14

       Yeah. This is sort of why maybe at a high level, like we like the zero to one app building product space. I think it's really... It's like 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.

    9. LRLenny Rachitsky58:35

       As a company, you mean?

    10. VMVarun Mohan58:36

        As a company.

    11. LRLenny Rachitsky58:37

        Versus as a user?

    12. VMVarun Mohan58:37

        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.

    13. LRLenny Rachitsky58:45

        I see. Because if they're just sitting on top of Sonnet and just doing what every other Sonnet wrapper is doing, there's not a lot of differentiation or or mo-

    14. VMVarun Mohan58:53

        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, eh, then, then the interface might be like high level enough that it's, it's hard to maybe get better than maybe what the frontier models are doing just across the board. You are just better off just plugging in Sonnet for everything.

    15. LRLenny Rachitsky59:14

        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... Uh, you... There's like a boilerplate code base that you st- you k- you wanna start with 'cause it's actually... 'Cause it's not a abstracted zero to one app builder, it's a actual IDE you're coding in. And y- you talked about how as- it has to install dependencies, which is kind of this painful thing. And the, the reason it has to do that is 'cause it's running locally on your machine versus in the cloud, like say Lovable and Replit and all these guys. Although I think Bolt runs in your browser in this really cool way. Uh, so that's an important distinction. This is like you're running this locally on your machine and has all the, all the libraries you need to actually run it.

    16. VMVarun Mohan59:54

        No, I think that's important. I think we believe a, 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. Uh, 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. Let's imagine you're building a GPU based application and the NVIDIA drivers are necessary. We 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 gonna go away in the next like couple of years.

    17. LRLenny Rachitsky1:00:29

        I love that your sales folks now are running like local host servers and... (laughs)

    18. VMVarun Mohan1:00:33

        Well, with the browser previews it's easier, right? You kind of just like open it up on the side.

    19. LRLenny Rachitsky1:00:37

        Yeah, yeah. Oh my god. Okay. I have a few more questions just about how you think and operate at, uh, at

14. 1:00:43 – 1:06:40

    Windsurf’s unique team structure and product strategy

    1. LRLenny Rachitsky1:00:43

       Codium. So, hmm, you guys are kind of at the forefront of how product teams are gonna operate, like you're 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 tried stuff that has worked really well or tried stuff that hasn't been a huge disaster.

    2. VMVarun Mohan1:01:01

       You know, one interesting decision that we kind of have for core engineering is that we don't have pure product managers for, for the core engineering side of the company. And by the way, that's purely because we build for developers, and our, our product is, is built by developers. So I think the intuition from our own developers are, are, is, is hopefully, 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. Uh, 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? I don't think our engineers wake up and they're like, "We need FedRAMP," right? Uh, like this is probably something that a lot of customers come to us with, a- and tell us. We have people that kind of like flex in this product strategy world that understand kind of what the, what the customer wants and understands the technical capabilities that we have to under- like to best kind of build a, a product, uh, that would, that would sort of help them at scale. So I think, I think we have a, an interesting organization in this regard, but mostly I would say because we are a developer-based product, right? Um, 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, the team structure is, it's, it's fairly flat. We 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, uh, so, so I think, I think that's like maybe, maybe, uh, maybe, uh, like 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, and, and it's very centrally planned in this regard.

    3. LRLenny Rachitsky1:03:08

       The two pizza team concept, I saw a tweet long ago where someone from India was like, "There's all this talk about two in- 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 US?" (laughs) Oh man. Okay. So how many PMs do you have? So you said you have 150 employees, something like that?

    4. VMVarun Mohan1:03:28

       Yeah, we have ... So in terms of like the product strategy function-

    5. LRLenny Rachitsky1:03:31

       Yeah.

    6. VMVarun Mohan1:03:32

       ... we have, we have, uh, we have three people in that role right now.

    7. LRLenny Rachitsky1:03:35

       I see. So it's like product, it's like pro- uh, they're, and their title is like, is product strategy, not necessarily-

    8. VMVarun Mohan1:03:40

       Yeah.

    9. LRLenny Rachitsky1:03:40

       ... product management.

    10. VMVarun Mohan1:03:41

        That's right. That's right.

    11. LRLenny Rachitsky1:03:41

        Interesting. And then-

    12. VMVarun Mohan1:03:42

        Yeah.

    13. LRLenny Rachitsky1:03:42

        ... 50 engineers. You said 80-ish sales folks.

    14. VMVarun Mohan1:03:45

        Yes, that's right. And then obviously we have functions like recruiting, you know, parts of GNA like finance, right? We have marketing at the company, right? So some other, some other functions internally as well.

    15. LRLenny Rachitsky1:03:56

        It's interesting, and, and this is something that you hear all the time with companies like Dario, for example, from Anthropic talking about how 90% of code is gonna be written by AI. Uh, but all ... At the same time all you guys are hiring engineers like crazy.

    16. VMVarun Mohan1:04:08

        Yeah.

    17. LRLenny Rachitsky1:04:08

        Is ... Do you ... Is there a c-

    18. VMVarun Mohan1:04:09

        Is that contradictory?

    19. LRLenny Rachitsky1:04:10

        Is that contradictory? Will there be an inflection point of like, "All right, now we don't need them anymore"?

    20. VMVarun Mohan1:04:15

        You know, I think it really comes down to do you get incremental value by adding more engineers internally? Like, I'm gonna 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. They 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, I don't know if you've heard about it.

    21. LRLenny Rachitsky1:04:43

        Mm-mm.

    22. VMVarun Mohan1:04:43

        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, of how much faster it made the whole process go. So maybe put simply, let's say you have 100 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 100 and made it 73. It's still 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 are solving for, I, 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 f- per person? You 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 JPMorgan Chase, right? Her budget on software every year is $17 billion, and you ... there's over 50,000 engineers inside the company, right? And you told her, "Hey, like each of these engineers are now able to produce more technology." That's effectively what you've done, right? The right calculus that JPMorgan 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. And 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, technology ceiling, this doesn't mean you stop. This actually means you hire more.

Episode duration: 1:14:05