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 twelve months. Every six to twelve months it should make our existing product look silly. It should almost make the form factor of existing product look dumb. How do you know when it's time to hire someone? I want the company to almost be like this dehydrated entity. Every hire is like a little bit of water and we only go back and hire someone when we're back to being dehydrated.
Other skills you think people should be investing more in with the rise of AI building more and more of our products. 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.
Today my guest is Varun Mohan. Varun is the co-founder and CEO of Windsorf, which has quickly become one of people's favorite AI coding tools. It's basically the main competitor to cursor with over one million users four months in. In conversation, Varun shares what makes Windsorf unique. Why they decided to invest heavily in enterprise sales, very early in their history, why agency is going to 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 of the stack and the two pivots that got them to where they are today. He also gives a live demo advice for being successful Windsorf 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, 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 Lenny's newsletter.com. With that, I bring you Varun Mohan.
如果你喜欢这个播客,别忘了在你喜欢的播客应用或YouTube上订阅和关注。此外,如果你成为我新闻通讯的年度订阅者,你可以免费获得一年Perplexity Pro、Notion Plus Linear、Granola和Superhuman的使用权。请访问 Lenny's newsletter.com 查阅详情。现在,我为大家介绍 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 build 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 slash banking dash solutions. That's BREX.com slash banking solutions.
This episode is brought to you by Product Board, the leading product management platform for the enterprise. For over 10 years, Product Board has helped customer-centric organizations like Zoom, Salesforce and Autodesk build the right products faster. And as an end-to-end platform, Product Board seamlessly supports all stages of the product development life cycle. From gathering customer insights, to planning a roadmap, to lining 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 Product Board 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 Product Board 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 slash Lenny. That's productboard.com slash LENNY.
Varun, thank you so much for being here and welcome to the podcast. Lenny, thanks for having me a long time listener. 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 is definitely not an overnight success. But I feel like I've been hearing about Windsorf more and more as people's favorite AI tool. And I just don't think people know the story behind Windsor, behind Codium, the company that you built.
So I thought it'd be good to maybe just start there. And have you just briefly shared the history of Codium and how Windsorf emerged out of Codium? Yeah, so the company was actually started close to four years ago. As you know, AI Coding was not a thing four years ago. Chat GPT was not out four years ago. At the time, we actually started out building GPU virtualization and compiler software. Right. Before this, I worked in autonomous vehicles, my co-founder, who had known since middle school, worked on ARVR at Meadow. And for us, we believed deep learning would touch many, many industries. It wouldn't just touch, like sort of autonomous vehicles with touch financial services, defense, 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. We were able to optimize these workloads a ton. And then the middle of 2022 rolled around. And we had a couple million in revenue. We were managing upwards of 10,000 sort of GPUs. We had eight people at the time. We were free cash flow positive. But I think what we felt was when once these generative models started to get very good, 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? Any more that were like very, very custom models for would they just ask GPTN is to say positive or negative sentiment? Probably is going to be the latter, right?
And in a world in which everyone was going to 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 one. 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 Google, like Amazon. And we vertical integrated and actually took our infrastructure or inference infrastructure to go out and build code at the time. And at that time, we were early adopters of GitHub co-pilot. And we thought the coding space was going to get tremendously disrupted in the next coming years. So we actually took our infrastructure.
We ran our own models and massive scale. We even trained our own models. In the very beginning, it was very, very simple as 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, EMAX. 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 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 work with these large companies like Dell, JP, working Chase.
And for them, the bigger thing wasn't just, hey, could be 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'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 ID, 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 ID with some of these new, agente capabilities. And over time, in the last couple of years, the model capabilities have also been growing exponentially year over year. That's sort of where we are right now. Like I skipped a lot of pieces there, but that's what we've blended. 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 call GPC wrapper, not actually, but so I guess any, just like lessons there, just thoughts on just where you think value will end up in the world of AI and the stack of AI tools.
Maybe I can start by just saying like one thing about startups that I think are like really true. It's very unlikely the first thing that you believe you should go work on is going to be the right thing, which is like a very hard thing to kind of wrangle with being a startup founder. Right. You need to kind of be irrationally optimistic that what you're going to do is going to be differentially important. Because otherwise, why would you go out and do what you're doing? And if it's obvious, then a bigger company would have already done it. Right. But then you also need to be really, really realistic because most ideas that are that are I guess non-conventional are usually bad ideas. Right. So it's this weird kind of tightrope you need to 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 going to 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, sort of lighter neural nets with frustram 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 word to the middle of 2023, everything looks like it's going to be a transformer. So now our hypotheses are just wrong. So at this point, then most of the value is probably not going to accrue at purely they at least this is our belief at the infrastructure layer. It's going to 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, 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. You touched on the second thread that I thought was really interesting here is just how you guys pivoted from ideas that were working. Like you were making money. People loved it. You said you had millions of dollars of ARR revenue. And then you just like, no, we're going to completely change the business. So the question is just like, how do you, what have you learned about knowing with 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. You know, I think the way we sort of think about this is, you know, even when we're working right now, we just accept that we're going to get a lot of things wrong. We're just going to get a lot of things wrong. Obviously, that's a very big moment because that was a bet the company moment in the sense that we basically said to older investors, hey, we're making money on this. We had already raised 28 million dollars of capital. And we were just like, hey, we're just going to pivot entirely from this. And we did that overnight, right? This wasn't this thing where we just said, hey, maybe a quarter or 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, your guarantee going to fail is the thing you think is going to be big. Right? So that's like a, that's a very obvious thing there. But I think once you go in with the assumption that a lot of your hypotheses are going to 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 true seeking. I think a lot of people at the company have had their ideas tested over and over again.
Even just building Windsor 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 going to be low if you made the wrong decision. That that's the best, right? That means you have optionality for the rest of time. And Lenny, one thing that I try to tell the company about this is this year, the total amount of engineering output we'll have is much larger than that. And it's much larger than the engineering output we 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 that. That's so empowering.
It makes me think about or really Venus on the podcast, defender ways. And he has this phrase that he was on a shirt as book is called this fall in love with the problem, not the solution. And I feel like that's exactly what you're describing. Okay, so let's talk about Windsorff. What's the simplest way for people to understand what is Windsorff? Yeah, so Windsorff is an ID, right? It's an application to go out and build software and build applications. The crazy thing is a lot of people who use the product don't even probably know what an ID is, which is, which is crazy. And we'll get into that in a second. But why did we go out and build Windsorff? And what is Windsorff? Maybe. Why couldn't we have just done this on top of conventional IDs 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 going to change remarkably.
这让我想起了维纳斯在播客中的一个观点,他提到的一个短语写在他的书《爱上问题,而不是解决方案》的衬衫上。我觉得这正是你所描述的。好了,让我们谈谈Windsorff。什么是让人们理解Windsorff最简单的方法?Windsorff是一个集成开发环境(IDE),它是一个用于开发软件和应用程序的工具。有趣的是,很多使用这个产品的人可能甚至不知道什么是IDE,这挺不可思议的,我们稍后会深入讨论这个点。但为什么我们要创建Windsorff呢?或者说Windsorff是什么?为什么我们不能基于像Visual Studio Code这样的传统IDE来实现这些呢?也许可以这样解释,当我们看到人工智能越来越强大时,我们觉得开发技术的方式、界面将会有显著的变化。
It was not going to be a conventional pure text editor where the user is writing a handful of lines of code or most of the code. And the IDE provides like maybe some basic feedback on what the user is doing right or wrong. And the basic feedback to be, hey, there's a bug in your software or a compiler error in your software. It could do much more, right? It could actually go out and modify large chunks of code. And one of the key pieces that we recognized was with this new paradigm with AI, AI was probably going to 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 Windsorff.
Maybe when you're using the product actually a good chunk of the user's time is actually reviewing what the AI is opening. So we need to build custom review flows into the IDE to actually make it so that it was easier to actually go out and do that right because the developer is not spending all their time writing code. And this is the fundamental premise on why we built the product. We thought we were going to 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 that completes a handful of lines of code. Now we've actually launched this offering called Windsorff tab that basically shows you refactors as well. And these refactors are almost in line refactors.
And we were able to build a custom UI for that in Windsorff. But in VS code we needed to because of the access to the API is we needed to dynamically generate images right alongside the user's cursor because we just have access to the capabilities to showcase and edit properly. So what we realized is immediately by porting over to Windsorff our acceptance rate tripled. Same ML models, it just tripled. So what that I just 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 wind surface.
我们能够在 Windsorff 中为此构建一个自定义用户界面。但是在 VS Code 中,由于需要访问 API,我们需要动态生成图像,以便在用户光标旁边显示,因为我们具备展示和编辑能力。因此,我们意识到,一旦转移到 Windsorff,我们的接受率立即增加了三倍。使用相同的机器学习模型,只是三倍增加而已。这让我们确信,技术确实非常重要。当然,您可以说技术非常重要。但如果我们的用户从我们构建的技术中获得的价值很小,那么我们需要真正弄清楚,也许我们需要构建一个新的界面,这就是 Windsorff 的作用所在。
You took there just to make the super clear is you were initially working with an existing ideas that everyone is familiar with. And then it was like this isn't going to get us where we need to go. We're going to try to convince people to switch to something completely new because it's going to be so much better. It's our own ID. I think the I think maybe people may not recognize just how risky that is convincing engineers to use something completely new. That's a huge deal. Yeah, yeah, no, of course.
And one of the key 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. But there are lots of people that write in languages like Java, sort of C++ and so on and so forth. And they might use the jeopardy and family of IDs that are 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 IDs, which was Visual Studio code was limiting the sort of user interface that we could give to our actual customers.
其中一个重要的方面,也许可以和 Lenny 分享一下,就是我们的许多开发人员确实使用 Visual Studio Code。但是也有很多人使用 Java、C++ 等语言,他们可能会使用像 IntelliJ 这样的开发环境系列。对于我们来说,我们仍然致力于在这些平台上进行开发。我们只是觉得,作为其中一个主要的开发环境,Visual Studio Code 在某种程度上限制了我们能够提供给客户的用户界面。
What is the current state of traction for Windsor fear all these crazy numbers about all the competitors in your space. What can you share there for folks just to know. 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 right now. I love how like these days like a million. No big deal. Like if it's just the numbers are absurd these days. Like we're just getting used to just 100 million are here. A million users in four months there. It's just like, oh, of course, how could you not have that. But that's absurd. It's just like an insane time right now.
You touched on something that I wanted to get you later, but it 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 going to be written by AI in the future, Dario from the topic recently said the same thing. 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.
I think when we think about what is an engineer actually doing it probably falls into three buckets right. 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 going to do it and just going and doing it. AI is going to handle vast majority of not all of it. Right. 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 windy it 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, give invest practices when the company also gets all. 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 to 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. 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. 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. But also the same time it empowers a bunch of people that never understood all those things. How to actually build as well, which is another remarkable sort of thing that fell out through this whole process. I don't know if you have kids, but just like say you had kids or you had knee certain FU going to college, let's say, would you suggest they do software, do computer science, or would you suggest like you're not going to have a good time if that's the career issues right now.
Yeah, I think, you know, maybe I think back a little bit. So I went to MIT, a lot of us at the company went to MIT together on the engineering team. And I think like when I think about what we learn the most that I had on for engineering or computer science, it was not exactly like how do you write code. That's maybe that is like almost a given that you can you can kind of write code 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.
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 some design decisions were kind of made. And I think it's more like a problem solving kind of course, right. And 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 based on that, you can make some tradeoffs and solve a problem. So 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 learning 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 is 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. 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 kind of like building the mental model of how computers and systems work. Parallel processing, memory hard drives, Internet, things like okay. And then there's just like problem solving skills being able to solve interesting problems. Is there any other skills you think people should be investing more in with the rise of AI building more and more products?
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, you know, you have a lot of people they could go through college and go through school. And they're basically told exactly what to do on a piece that and you know they're giving these very, very, I would say well defined paths that they need to take. And I think I think maybe in society and just school, we don't prioritize. How do you how do you make sure you get people with real agency that want to build something right.
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 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 start up, 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. The 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.
And I'm going to phrase 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 will die. 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 mean, you try to stay really lean. That's a common theme across all the AI start ups 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. Right. That's what the goal is. And maybe 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 in the company. Our goal is to reduce the time it takes to build apps and technology by 99%. Right. It is a tremendously sort of ambitious goal.
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 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. 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 on and building inference technology. Unless we are underwater there, we will not go out and hire hire someone to go on and work work for that. Right. And the reason for that is actually think this is like this is the, this is a feature. Right. When when you hire for a role and you already have enough people there, what 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 intention. 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 start of 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 to be like raising their hands of being like, I'm dying. Like we need we need one more person and that's when we got in and hire someone. And one of the analogies I like to give is we I want to the company to almost be like this dehydrated entity. Right. And every hire is like a little bit of water. Right. And we only go back and hire someone when we're when we're back to being dehydrated. I love this metaphor so much.
And it sounds 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 just talk about just that side because I think it could sound like this is terrible. I don't want to work this way. You know what I actually think when he it's it's really good for a handful of reasons, which is that a lot of the 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 going to just tell me, hey, there are two things on the plate. I just don't have the ability to do to 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 kind of 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 plus and the one class that matters. And then I can get an F and all the other classes. And an F and all the other classes doesn't mean you know being, you know, just doing illegal things that basically means you just deep prioritize 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 Douglas being my co-founder, we can tell the company these are the two things that are the most important. And 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 is this? What's going to 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. Everyone listening that works at a big company knows exactly what you mean when you describe when there's just too many people they were all fine 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. Reaves. It is just the nature of too many people at a company.
And so I think this all really resonates to even getting 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? Varune, we need I need someone on this team. This is just not possible. Like what does that look like even more practically. Yeah, I think it's basically along those lines. It's that 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? 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 kind of stupid to believe that.
So I think basically comes down to that person coming out and being like, hey, look, like I don't have enough time to do X. I'm also having a conversation to be like, okay, what can you do then? And 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 you 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. So I think 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. There 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. There's no notion of someone owning people at the company that is a very bad and gnarly idea. 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 Cody at this point? So we have we have close to 160 people on the engineering team is over 50 people. Awesome. What is the other bigger functions? So we have go to market. We have a yeah. Oh, right. Okay. I want to talk about that. The sales learning that you guys had. Okay. Well, let's close out this hiring conversation. So we talked about what you look for to tell you the same 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 need 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. 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, they're not working very hard.
And I think one of the biggest dog muscles I sort of hear is when I ask people like how hard are you willing to work? 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 differentiate are going to be? Are 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 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 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? Not too much. Exactly. So for us, for us, I think that's what we more care about. Right. We have a culture where 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 a whole group of folks that are just like work like balance. I don't want to how dare you ask me to work crazy hours. And I love just the filter of front of 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. Yeah.
You said at some point earlier that your engineering pass rate is you said it was like 0.6% of candidates. I'm like that. Yeah, it's probably posted at take home. It's probably that actually so the take home itself filters probably another 10 15 X 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 we'd serve 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 white board 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 in a voice translator and sticking it into chat to be seeing the answer up. So 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 you. 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 management community. So I put the questions that I plan to ask every guest that's coming on the podcast. So I put my community resources. It's how I manage my workflows. Here's how Coda can help you imagine 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. If 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 C-O-D-A.io slash Lenny to get started for free and get six months of the team plan. Coda.io slash Lenny.
OK, let's talk about this good market sales experience you guys have. We started without, obviously, like most people started building without sales team and then you realized from what I hear that that was a huge mess and a big opportunity to talk about there because that's really unique I think. 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.
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 Dela Torre who used to be the CEO 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 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 and growth. And I think it's not that black and white like I think enterprise sales is really valuable.
当然,这里需要一点背景介绍。当我们创办这家公司时,我们实际上有一些天使投资人,他们实际上是负责市场运营的。例如,Carlos Dela Torre,他曾是MongoDB的CEO。对我们而言,我们从未将企业销售和销售视为一种非常负面的事情。我认为这是一个技术创始人有时不太喜欢的有趣观点。他们认为销售是一个过程中的负面部分,认为一切都应该依靠产品和增长。我认为情况不是那么非黑即白,我认为企业销售是非常有价值的。
But maybe when we were a GP 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 into a process that we could then go and scale. If I couldn't do one, 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 out?
On the other hand, for code, 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. 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 VP of sales and very quickly after that scaled 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. Also, there's co-pilot, 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, maybe a handful of things that I could share. So on the products side, I think we've invested a lot in making sure code based 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 MarketJays. 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'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 infrastructure background to go out and do that. That's maybe one. Let me actually follow that thread because I think people may miss under estimate 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 built something from scratch. They built, they write the code for you. So that versus just loading say Windsorf on your million flying code base say it or being the Aruba like it understanding what the hell you have and how 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 differentiators. You guys started there actually. And then Windsorf is now building up that advantage. 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 in a bit here. Awesome.
The second key piece probably is we're not only tied to the to Windsorf actually this is probably like a weird statement given even we are talking about Windsorf, which is that actually we're pretty focused on supporting ideas like Jetrix. Right. You know, JetRains or IntelliJ has over 70 to 80% of all Java developers code in in JetRains based IDs. Right. The reason why we don't feel as big a need to almost build a competing product to JetRains is JetRains is actually a very sort of extensible product in a way that the S code is not.
The S 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 on to our ID. But we want to give this agent experience to every developer out there. And if that means there are Java developers that write in JetRains, that's fine. We work with a large lot of large enterprises that have 10 plus thousand developers were over 50% of the developers are on JetRains. 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 work on that too. The third key piece and this probably sounds in other key piece for enterprises is we work in like a lot of very secure environment. Right. We have fed RAM compliance. Right. We have which means we can sell to like very large government and these.
We have a hybrid mode of actually using the product, which means that all the code that lives that is like indexed actually lives on the tenant of the user. Right. Code is one of the most important IP 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. But that's part of it is because of the history of how we got here in the first place.
Okay, everyone enough teasing. Let's do a live demo of when surfs of folks can see what it's like and then I'm just going to 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 when surf 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. You can pass windsurf images of what you'd like the project to kind of look like of what I would like an Airbnb for dogs website to kind of look like beautiful, beautiful mockup. 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 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 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, let's let's continue the conversation.
Awesome. 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 when serve it 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 management products and designers. So you could sit next to every single user that opens up windsurf and whisper a couple tips in their ear to help them be successful with the product will be a couple tips each year. Tip 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. 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. And I think from there, one of the key pieces I think that it 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 septic 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 eat except this or 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 sort of command that you write. Is very complex you just expect a like the autocomplete is not going to 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 reevaluate.
It almost becomes the case that that it becomes materially better than it was in the past so I think I think maybe patients and being explicit or maybe to important key pieces that 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 abstract you can be and there's kind of this like gut feeling you start to build over time that's right yeah and with that it feels like we have a actual preview.
Guess what we have a nice you dogs 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 I could point to different elements and say hey like make the background. This is not great great design but I could basically say if I took this element make this background read right and just take a particular element and just change it and make it read 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 an app app world right you don't even maybe even need to look at the code right this looks hideous but.
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 like yeah when there's no more. Designers like maybe the answer the answer is like when you ask me what's your people be doing they should study great taste having great taste because I think taste is also very very hard right but maybe the other key piece learning 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 the eyes now change a lot in that it is now modifying large chunks of code for you and the job of the developer now is to is to actually review a lot of the code that the AI is generating and graduate right now during this during this part of the day.
I'm not going to review all the code that's getting get ready 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 spring 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 spring right and that's what I'm going to do I'm just going to tell the ad to continue.
And the cool part about this is when sir not only kind of knows about what the agent has done it also knows everything that the user is done like our goal here is to have this almost flow like state where everything the user is 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 spring and then it now has gone out and modified all the locations within the app from title to title spring.
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 air can go out and quickly make these changes for on the user's path imagine doing a refactor or migration and you just change one part of the code you can just tell the ad to continue the rest. 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 rate 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 so it should add leverage not only on developers that are just purely building apps but also developers that are just hands on keyboard to amazing that 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 that is extremely cool so interestingly so having just looked at lovable and bolt and replant 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 now yeah a little green button this is great okay so so I don't think people realize this about apps like Windsor 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 differences you need to start it with some code base you have this kind of boiler plate react project is there a reason you guys aren't taking math step and just doing that automatically for you is it because you're targeting engineers and they don't need that or you know any interesting thing is like the base app that you saw for this was also generated by Windsor the reason why we sort of didn't generated 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 within of the product probably zero to one build these apps and if I can say one interesting thing is when we launched Windsor actually we test everyone under a company to go out and build an app with Windsor 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 like our head of partnerships instead of going to buy. And then we actually built our 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 a company to operate more efficiently which is I would not have expected this probably six months ago. So it's incredibly interesting you don't need to name company names but I guess what's the space your least bullish on they think is going to have the most problem here with company people building their own version of these sorts of products. 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.
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 from class sales product there's not enough interest to do that. Or to build a best in class legal 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 having opinion it stands on how to do this higher good enough engineers to go on build the software. 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 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 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 one a 10% of the features.
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 and there's always yeah there's always been a story 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 it's five minutes and maybe even more custom to your system right like how many times if you bought a piece of bought a software and you build your almost like why is there no integration to X and I actually use X how annoying is that that actually makes the software.
It's less useful to you so I think what's cool is that 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 a Airbnb for dogs here's a stupid mark that I made like with some box like that's 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 and I'm going to do it.
So I'm going to do a lot of things about product building it's just describe it in some ridiculous way and draw a couple boxes of what you want to look like and it makes something for you shows that agencies 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 ever product manager that just 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 taking 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 sales person 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 I don't have time for this. And so that problem goes away which I think will make a lot of product leaders are 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 son it is a really really good planning model I think opening eyes GPT four is also good but the crazy thing is what we try to do is we try to make the anthropic base model or sonnet model try to do as much of the high level planning is 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. 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 hundred million line code base to send that entire code base to a topic 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 or just a mic to larger than the largest context lungs right now.
But you also wouldn't want to do that from like a cost and latency standpoint to so that's like one and the second piece that you saw was the models able to very quickly make edits to the to the software as well we have cost of models that we built that are post-craned 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 to so it can be better at applying changes than even after a lot of the time.
Then even a drop it's model to 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 we're not going to be good at good at a task and we think the open source better or at the office better we'll just use the open source or at the office and so the models you guys are building those are built on open source models that people are really 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 based on open source for interestingly for the one that does that does the edits and autocomplete that is also in house. Like 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 trade 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 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 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 users typing right imagine you're typing typing some code in a code base. The code is 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 get up. But we have a lot of data that looks like this so we're 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 are the frontier models of consume 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 as kind of true on retrieval right there's a way to find out are we retrieving the right data right that the user accepted code change after that was the retrieval actually good retrieval 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 event right I think that would that would not be a 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 code where we've seen the evolution of code across millions of users we feel like we can do a great job.
I think it's interesting about this is this is another differentiator slash mode for companies that end up winning in the spaces you just have more and more of that data than other companies if you're ahead. Yeah, this is sort of why maybe at a high level like we like the zero to one up 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 as a company. As 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 whatever other sonnet wrapper is doing there's not a lot of differentiation or 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 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 were just better off just plugging in some 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 abstract is your one up builder it's a actual ID you are coding in. And you talked about how I asked and solve dependencies which is kind of a painful thing and the reason has to do that is because it's running locally on your machine versus in the cloud like say lovable and replete and all these guys although I think both runs in your browser in this really cool way. So that's an important distinction this is like you're running this locally in a machine and as all the 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 and what are called 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 let's imagine you're building a GP 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 I think that people have done for you know decades so probably it's not going to go away in the next couple years.
I love that your sales folks now are running like a lot of servers and 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 podium. So 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 other companies are doing it or 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 for the core engineering side of the company and by the way that's purely because we build for developers and our product is is built by developers so I think the intuition from our own developers are 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 in the other 90 who are 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 I don't think our engineers wake up and they're like we need fed ramp right. Like 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 what the customer wants and understands the technical capabilities that we have to under the best kind of build a product that would that would sort of help them at scale.
So I think 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 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 very very dangerous because there's too much like armchair quarterbacking. And so so I think I think that's like maybe maybe maybe 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 it's very centrally planned in this regard.
The two pizza team concept I saw a tweet long ago or 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 like like can we build as much of these teams in the hands. 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 a we have three people in that role right now. I see so it's like product it's like they're in their title is like this product strategy not yeah product manager that's right that's just thing and then 50 engineers you said ADS sales folks. 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.
It's interesting and then this is something you hear all the time with companies like Dario for example from Anthropic talking about 90% of code is going to be written by AI but all at the same time all you guys are hiring engineers like crazy. Yeah is there is that contradictory. It's 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 like I'm going to take first of all you know maybe just to set the records rate 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 engineers do.
There's this one famous law and parallel computing. It's called Omdol's law I don't know if 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 paralyze it a ton which is make it almost take zero amount of time there's still limit of the amount 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 it took the 30 and made it three I only took the 100 and made it 73 it's only 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 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 JP work and chase right. Her budget on software every year 17 billion dollars 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 JP more in chase or any of these companies will make is the RY of building technology has actually gone up. So the opportunity cost of not investing more into technology has gone up means that you should just invest even more and maybe in this work from 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 for for companies that actually have a very high technology technology ceiling. This doesn't mean you stop this actually means you hire more.
This is a great bullcase for engineers I feel like there's like the canary in the coal mine for the engineering profession is when companies like yours to slow down on a year years. Yeah that's good. See I think it's also I agree. 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.
Yeah. Okay let me ask you this question as a kind of a final question maybe what's maybe the most counter intuitive thing you've learned about. Building AI products building windsurf in this just being in a space I think one of the weird thing 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 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.
好的。让我问你一个可能作为最后一个问题的问题,你在构建 AI 产品或从事风帆产品中学到的最违反直觉的事情是什么?我认为其中一个奇怪的事情是在网上,每个人对我们取得的短期胜利都非常兴奋,比如我们每周发布的内容,或是每隔几周推出的一些成果。但实际上,我们在公司内部做的很多决策是为了那些三四个星期无法见效的事情,而可能需要三到六个月,甚至九个月才能见到成果。
That'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 under our company is 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 existing product with dumb.
So it there's this weird tension where you want to have a product and market and you want to incrementally iterate and listen to users and keep making it making it better and better. But I would say we were the first. Agentic ID product out there right that's what we landed with and I think that the value of that is going to depreciate very quickly unless we continue to reproversel and we will need to reproversel in ways in which our users are not even asking.
So there's this tension here where incremental feels very safe right at 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 a you know that's almost table stakes. 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 for captions on the podcast and he told us that he had just two roadmaps they have two roadmaps of the company they have the the real road map.
Like the typical road map based on feature request and user feedback and data and things like that and then they have a secret road map 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 road map just to make it very mysterious. That's very smart.
Okay I have one more question I apologize. What's one thing that you wish you have known before starting code and 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 we'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 at 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 I waxed poetically about like oh you need to be a rationally sort of optimistic and uncompromisingly realistic but it's very hard to do this in practice right because you drink your own cool it to it's very because if you're not drinking your own cool it you you won't get up out of bed. Right the answer is already solved it's not actually any of these startups the answer is Microsoft is going to be the 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 come out of that every space.
So I think I think in some ways you this this amount of just understanding that hey like 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 right I we started the company at like peak zirp time at that time probably like 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.
Roon we covered so much ground what an incredible conversation I learned so much just just sitting here listening and asking questions is there anything else that you wanted to share before or leave listeners with any last piece and I get so 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 with all of these products and 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 and just 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 would serve start coding ask it to build. Yeah build apps build apps start using it for maybe even making making mocks modifying your existing code base like 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 are 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 it's just I feel like the there's no there's no sort of.
See link at the point I think this is such an under estimated point you're making here there's apps that can build things from scratch and then there's apps like this like an edit your existing code base if you're PM at like what's what are the what's the largest company work with like people wise probably like it publicly I'd say let's just say JP Morgan chase okay they have over 50,000 developers okay so you could be a PM JP Morgan Chase and be like I have a I have a problem I need to solve I want to move this metric I want to.
Change the step and sign up flow you 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. Yeah, okay yeah you are yeah I could make up the earthery this is insane yeah future is out of control okay that was such an important point in there because I think people may not realize this they see all these other apps they're like oh Bill ice prototypes but this is like legitimately something if you can actually do work with yeah when you think about the people I 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.
And I think you know sometimes you see people that talk about roles and they irrational I 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 the weeds and all the way up to the top right And just be effective on every level and I believe the world all right well with that we'll leave folks are in thank you so much for being here awesome thanks Well, I'm an incredible conversation thanks for 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 Also, please consider giving us a rating or a leaving review as that really helps other listeners find the podcast you can find all past episodes or learn more about the show at Lenny's podcast dot com see you in the next episode.
非常感谢您的收听!如果您觉得这有价值,可以在 Apple 播客、Spotify 或您喜欢的播客应用上订阅我们的节目。此外,请考虑给我们评分或留下评论,这可以帮助其他听众找到这档播客。您可以在 Lenny's podcast dot com 找到所有的往期节目或了解更多关于节目的信息。我们下期再见!