Windsurf: The Enterprise AI IDE - with Varun and Anshul of Codeium AI

21:20In some ways, I want like a snapshot of the system that I can like constantly checkpoint and move back and forth. And then also on top of that, I might want to do multiple rollouts of this. So basically, I think there needs to be a way to almost like move forward and move backwards the system. And whether that's locally or remotely, I think that's necessary. But every time if you move the system forward, it destroys your machine. It's probably going to be a hard system to potentially destroy your machine. That's just not a workable solution. So I think the local versus remote, I think you still need to solve the problem of this thing is not going to destroy your machine on every execution, if that makes sense.

21:52Yeah, there's a category of emerging infrastructure providers that are working on time travel VMs. And if Vern's first episode on this podcast was any indication, we like infrastructure problems. Okay, so you're going there. That's funny, right? It's like when we first had you, you were doing so much on like actual model inference, optimization, all these things. And today it's almost like it's Claude, it's Oro. It's like, you know, people are like forgetting about the model, you know, and that's all about at a higher level of abstraction. Yeah. So maybe I can say like a little bit about how our strategy on this has like evolved because it objectively has, right?

22:27I think I would be lying if I said it hasn't. The things like autocomplete and supercomplete that run on every keystroke are entirely like our own models. And by the way, that is still because properties like FIM, fill-in-the-middle capabilities, are still quite bad with the current... Non-existent. They're very bad. Non-existent. They're not good, actually, at it. Because FIM is an actual, like, how you order the tokens. Yes, it's how you order the tokens, actually, in some ways. And this is sort of, if you look at what these products have sort of become, and this is great, is a lot of the clods in the OpenAI's have focused on kind of the chat-like assistant API, where it's like complete pieces of work, message, and other complete piece of work.

23:03So multi-turn kind of back and forth systems. In fact, like actually even these systems are not that good at making point changes. When they make point changes, they kind of are like off here and there by a little bit. Because yeah, when you like are doing multi-point kind of like conversations, it's, you know, exact GIFs getting applied is not like even a perfect science still yet. So we care about that. The second piece where we've actually sort of trained our models is actually on the retrieval system. And this is not even for embedding, but like actually being able to use high powered LLMs to be able to do much higher quality retrieval across the code base, right?

23:36So this is actually what Anshul said. For a lot of the systems, we do believe embeddings work, but for complex questions, we don't believe embeddings can encapsulate all the granularity of a particular query. Like imagine I have a question on a code base of, find me all quadratic time algorithms in this code base. Do we genuinely believe the embedding can encapsulate the fact that this function is a quadratic time function? No, I don't think it does. So you are going to get extremely poor precision recall at this task. So we need to apply something a little more high-powered to actually go out and do that.

24:04We've actually built large distributed systems to actually go out and run these at scale, run custom models at scale across large code bases. So I think it's more a question of that. The planning models right now, undoubtedly, I think the clods and the OpenAIs have the best products. I think Lama 4, depending on where it goes, it could be materially better. It's very clear that they're willing to invest a similar amount of compute as the OpenAIs and the Anthropics. So we'll see. I would be very happy if they got really good, but unclear so far. Don't forget Grok. Hey, dude, I think Grok is also possible.

24:35I think don't doubt Elon. Okay, so I didn't actually know. It's not obvious when I use Cascade. I should also mention that I was part of the preview with Xcode letting me in. I've been maining Windsurf for a long time. It's not actually obvious. You don't make it obvious that you are running your own models. I feel like you should. I feel like it has more differentiation. I only have exclusive access to your models via your IDE than having the drop-down as his cloud in 4.0? Because I actually thought that was what you did. No, so actually the way it works is the high-level planning that is going on in the model is actually getting done with products like the cloud.

25:09But the extremely fast retrieval, as well as the ability to take the high-level plan and actually apply it to the code base, is proprietary systems that are running internally. And then the stuff that you said about embeddings not being enough, are you familiar with the late interaction? No, I actually have never. Yeah, so this is Colbert, or like the guy, Omar Khatab from, I think Stanford, has been promoting this a lot. It is basically what you've done. Sort of embedding on retrieval rather than pre-embedding. Okay. In a very loose sense. I think that sounds like a very good idea that is very similar to what we're doing.

25:42Sounds like a very good idea. I think we'd say that. That's like the meme of Obama giving himself a medal right there. Well, I mean, there might be something to learn from contrasting the ideas and seeing where the sort of opinion difference is. It's also been applied very effectively to vision understanding. Because vision models tend to just consume the whole image, if you are able to focus on images based on the query, I think that can get you a lot of extra performance. The basic idea of using compute in a distributed manner to do operations over a whole set of raw data rather than a materialized view is not anything new.

26:19I think it's just like, how does that look like for LLMs? When I hear you say build large distributed systems, You have a very strange product strategy of going down to the individual developer, but also to the large enterprise. Is it the same in front that serves everything? I think the answer to that is yes. And the only reason why for the answer is yes. And to be honest, our company is a lot more complex than I think if we just wanted to serve the individual. And I'll tell you that because we don't really pay other providers to do things for our indexing. We don't pay other providers to do our serving of our own customer models.

26:52And I think that's a core competency within our company that we have decided to build. But that's also enabled us to go and make sure that when we're serving these products in an environment that works for these large enterprises, we're not going out and being like, we need to build this custom system for you guys. This is the same system that serves our entire user base. So that is a very unique decision we've taken as a company. And we admit that there are probably faster ways that we could have done this. I was thinking, when I was working with you for your enterprise piece, I was thinking this philosophy of go slow to go fast.

27:20build deliberately for the right level of abstraction that can serve the market that you really aren't going after. Yeah, I would say when I was writing that piece, looking back and reading it back, it sounds almost obvious. Not all of those are really conscious decisions we made. I'll be the first to admit that. But it does help when we go to an enterprise that has tens of thousands of developers, and they're like, oh wow, we have tens of thousands of developers, and does your infrastructure work for tens of thousands of developers? We can turn around and be like, Well, we have hundreds of thousands of developers or an individual plan that we're serving.

27:51I think we'll be able to support you. So being able to do those things, we started off by just like, let's give it to individuals. Let's see what people like and what they don't like and learn. But then those become value propositions when we grow the enterprise. And to recap, when you first came on the pod, it was like auto-completion is free. And Copala was 10 bucks a month. And you said, look, what we care about is building things on top of code completion. How did you decide to just not focus on short-term growth monetization of the individual developer and build some of this? Because the alternative would have been, hey, all these people are using it, so we're going to make this other five bucks a month plan, monetize.

28:29I think this might be a little bit of commercial instinct that the company has and unclear if the commercial instinct is right. I think that right now, optimizing for making money off of individual developers is probably the wrong strategy. Largely because I think individual developers can switch off of products very quickly. And unless we have a very large lead trying to optimize for making a lot of profit off of individual developers, it's probably something that someone else could just vaporize very quickly and then they move to another product. And I'm going to say this very honestly, right?

29:01When you use a product like Codium on the individual side, there's not much that prevents you to switch onto another product. I think that will change with time as the products get better and better and deeper and deeper. I constantly say this, there's a book in business called Seven Powers And I think one of the powers that a business like ours need to have is like real switching costs. But like you first need something in the product that makes people switch on and stay on before you think about how do you make people switch off. And I think for us, we believe that there's probably much more differentiation we can derive in the enterprise by working with these large companies in a way that is like that is interesting and scalable for them.

29:36Like I'll be maybe more concrete here. Individual developers are much more sort of tuned towards small price changes. They care a lot more, right? If our product is$10,$20 a month instead of$50 or$100 a month, that matters to them a lot. For a large company where they're already spending billions of dollars on software, this is much less important. So you can actually solve maybe deeper problems for them, and you can actually kind of provide more differentiation on that angle. Whereas I think individual developers could be churning as long as we don't have the best product. So focus on being the best product, not trying to take price and make a lot of money off of people.

30:09and I don't think we will for the foreseeable future try to be a company that tries to make a lot of money off individual developers. I mean, that makes sense. So why$10 a month for Windsurf? Why$10? $10 a month was actually the pro plan. So we launched our individual pro plan before Windsurf existed because I think there's, let's all start, we all said to be financially responsible. Yeah, yeah, we can't run out of money. You raise$150 million. There's a lot of things because of our infrastructure background we can give for essentially free unlimited autocomplete, unlimited chat on our faster models.

30:43We have a lot of things actually out for free. But yeah, when we start doing things like the super completes and really large amounts of indexing and all these things, there is real cogs here. We can't ignore that. And so we just created$10 a month pro plan, mostly just to cover the cost. We're not really operating, I think, on much of a margin there either. But okay, just to cover us there. So for Winsurf, it just ended up being the same thing. and everyone who downloads Windsor in the first, I forget, a couple of weeks, they get two weeks for free. Let's just have people try it out, let us know what they like, what they don't like, and that's how we've always operated.

31:16I've talked to a lot of CTOs in the Fortune 100 where most of the engineers they have, they don't really do much anyway. The problem is not that the developer costs 200K and you're saving 8K. It's like that developer should not be paid 200K, but that's kind of like the base price. But then you have developers getting paid 200K that should be paid 500K. So it's almost like you're averaging out the price because most people are actually not that productive anyway. So if you make them 20 % more productive, they're still not very productive. And I don't know in the future, is it that the junior developer's salary is like 50K?

31:51And it's like the bottom of the end gets kind of squeezed out and then the top end gets squeezed up. Yeah, maybe Alessio, one thing that I think about a lot because I do think about this, the Perseed, anything, all of this stuff I think about a good deal. Let's take a product like Office 365. I will say a lawyer at Codium uses Microsoft Word way more than I do. I'm still footing the same bill. But the amount of value that he's driving from Office 365 is probably tens of thousands of dollars. By the way, everyone, Google Doc's a great product. Microsoft Word is a crazy product. It made it so that the moment you review anything in Microsoft Word, the only way you can review it is with other people in Microsoft Word.

32:25It's like this virus that penetrates everything. And it's not only penetrates it within the company, it penetrates it across company too. The amount of value it's driving is way higher for him. So for these kinds of products, there's always going to be, for these kinds of products, this variance between who gets value from these products, right? And you're right. It's almost like a blended because you're actually totally right. Probably this company should be paying that one developer maybe like four times as much. But in a weird way, software is like this team activity enough that there is a bunch of blended outcomes.

32:52But, hey, like 20 % of the four times and there are four people is still going to cover the cost across the four individuals, right? And that's how roughly these products kind of get priced out. I mean, more than about pricing, this is about the future of the software engineer. We could be very wrong also. Yeah. I think nobody knows. Reserve the right to be incredibly off. Yeah. I mean, business model does impact the product, product does impact the user experience. So it's all of a kind. I don't mind. We do are as concerned about the business of tech as the tech itself. That's cool. Speaking of which, there's other listener questions.

33:25Shout out to Daniel Enfeld, who's pretty active in our Discord, just asking all these things. Multi-agent, very, very hot and popular, especially from the Microsoft research point of view. Have you made any explorations there? I think we have. I don't think we've called it a multi-agent, which is more so like this notion of having many trajectories that you can spawn off, that kind of validate some different hypotheses and you can kind of pick the most interesting one. This is stuff that we've actually analyzed internally at the company. By the way, the reason why we have not put these things in, actually, is partially because we can't go out and execute some random stuff in parallel in the meantime.

34:01In the meantime, on other sides. Because of the side effects. Because of the side effects, right? So there's some things that are a little bit dependent on us unlocking more and more functionality internally. And then the other thing is, in the short term, I think there is also a latency component. And I think all of these things can kind of be solved. I actually believe all of these things are solvable from. They're not unsolvable from. And if you want to run all of them in parallel, you probably don't want N machines to go out and do it. I think that's unnecessary, especially if most of them are IO-bound kind of operations where all you're doing is reading a little bit of data and writing out a little bit of data.

34:29It's not extremely compute intensive. I think that it's a good idea and probably something we will pursue and is going to be in the product. I'm still processing what you just said about things being IO bound. So for a certain class of concurrency, you can actually just run it all in one machine. Yeah, why not? Because if you look at the changes that are made for some of these, it's writing out like what, a couple thousand bytes? Maybe like tens of thousands of bytes on every tree. That's not a lot, very small. What's next for Cascade or Windsurf? Oh, there's a lot. I don't know. We did an internal poll and we were just like, are you more excited about this launch or the launch that's happening in a month?

35:04Or what we're going to come out with in a month? And it was almost uniformly in a month. I think there's some obvious ones. I don't know how much, Vern, you want to say. I don't want to speak of. But I think you'd look at all the same axes of the system. How can we improve the knowledge retrieval? We'll always keep on figuring out how to improve knowledge retrieval. In our launch video, we even showed some of the early explorations we have about looking to other data sources. That might not be the coolest thing to the individual developer building a zero-to-one app, but you can really believe that the enterprise customers really think that that's very cool.

35:34I think on the tool side, I think there's a whole lot more that we can do. I mean, of course, Vern's talking about not just suggesting the terminal command, but actually executing them. I think that's going to be a huge unlock. You look at the actions that people are taking, like the human actions, the trajectories that we can build, how can we make that even more detailed? And I think all of those things, and you make some even a cleaner UI, the idea of looking at future trajectories, trying a few different things, and suggesting potential and next actions to be taken, that doesn't really exist yet.

36:04But it's pretty obvious, I think, how that would look like. You open up Cascade, and instead of starting typing, it's just like, here's a bunch of things that we want to do. We kind of joked that Clippy's coming back, but maybe now's the time for Clippy to really shine. I think there's a lot of ways that we can take this, which I think is the very exciting part. we're calling each of our launches waves I believe because we want to really double down on the aquatic themes. Does someone actually windsurf at the company? We're living out our dream of being cool enough to windsurf through the rocks.

36:34I don't think we can. That was actually something we learned because I don't think any of us are windsurfers. In our launch video we have someone using windsurf on a windsurf. You saw that? You saw that in the beginning of the video. And we didn't realize now apparently is the time of the year where there's not enough wind to windsurf. So we were trying to figure out how to do this like, you know, launch video with windsurf on the windsurf. Every windsurfer we talked to like, yeah, it's not possible. And there was like one crazy guy who was like, yeah, I think we can do this. And we made it happen.

37:02Oh, okay. That's funny. Is there anything that you want feedback on? Like maybe there's a fork in the road. You want feedback. You want people to respond to this podcast and tell you what they want. Yeah, I think there's a lot of things that I think could be more polished about the product that we'd like to improve. Lots of different environments that we're going to improve performance on. And I think we would love to hear from folks across the gamut. Like, hey, if you have this environment, you use Windows in X version, it didn't work, or this language, it was very poor. I think we would like to hear it.

37:33Yeah, I gave Preb and Kevin a lot of shit for my Python issues. Yeah, yeah, yeah. And I think there's a lot to kind of improve on the environment side. I think, for instance, even just a dumb example, and I think ServiceWix, this was a common one. It's like, yeah, the virtual environment, where's the terminal running, what is all this stuff? These are all basic things that, to be honest, this is not rocket science, but we need to just fix it. We need to fix it. We would love to hear all the feedback from the product. Was it too slow? Where was it too slow? What kind of environments could it work way more in?

38:01There's a lot of things that we don't know. Luckily, we're daily users of the product internally, so we're getting a lot of feedback inside. But I will say there's a little bit of Silicon Valley-ism in that a lot of us develop on Mac. A lot of people, once again, over 80 % of developers are on Windows. So yeah, there's a lot to learn and probably a lot of improvements down the line. Have you personally tempted, as you're CEO of the company, to switch to Windows just to feel something? Feel the Windows. You know what? Maybe I should. Actually, I think I will. Your customers, you know, everyone says it's 89 % on Windows, right?

38:35You live in Windows, you will never not see something that missed. So I think in the beginning, part of the reason why we were hesitant to do that was a lot of our architectural decisions to work on across every IDE was because we built a platform-agnostic way of running the system on the user's local machine that was only easily buildable on dev containers that lived on a particular type of platform, so Mac was nice for that. But now there's not really an excuse if I can also make changes to the UI and stuff like that. And yeah, WSL also exists. That's actually something that we need to add to the product.

39:09That's how early it is that we have not actually added that. We don't have remote. Anything else about Codium at large? You still have your core business of the enterprise Codium. Anything moving there or anything that people should know about? I think a lot are still moving there. I think it would be a little bit egotistical. We have Windsurf now, all of our enterprise customers are going to switch to Windsurf. You just talked about your Java guys loving JetBrains. They're never going to leave JetBrains. They're not. Forget JetBrains, there's still tons and tons of enterprise people on Eclipse.

39:43We're still the only code assistant that has an extension in Eclipse. That's still true years in. But that's because that's our enterprise customers. And the way that we always think about it is how do we still maximize the value of AI for every developer? I don't think that part of who we are has changed since the beginning. And there's a lot of meeting the developers where they are. So I think on the enterprise side, we're still pretty invested in doing that. We have a team of engineers dedicated just to making enterprise successful and thinking about the enterprise problems. But really, if we think about it from the really macro perspective.

40:13It's like, if we can solve all the enterprise problems for an enterprise, and we have products that developers themselves just truly, truly love, then we're solving the problem from both sides. And I think it's one of those things where I think when we started working with enterprise and we started building dev tools, right? We started as an infrastructure company. Now we're building dev tools for developers. You really quickly understand and realize just how much developers loving the tool make us successful in an enterprise. There's a lot of enterprise software that developers hate. I want to draw this flywheel.

40:43We're giving a tool for people where they're doing their most important work. They have to love it. And it's not like we're trying to convince... The executives at this company also ask their developers a lot, do you love this? That is almost always a key aspect of whether or not Codium is accepted or not into the organization. I don't think we go from zero to 10 million ARR in less than a year in an enterprise product if we don't have a product that developers love. So I think that's why we're just... The IDE is more of a developer love kind of play. It will eventually make it to the enterprise.

41:12We still solve the enterprise problems. And again, we could be completely wrong about this, but we hope we're solving the right problems. It's interesting. I asked you this before we started rolling, but it's the same team. That's the same edge team. In any normal company, or my normal mental model of company construction, if you were to have effectively two products like this, you would have two different teams serving two different needs, but it's the same team. Yeah, I think one of the things that's maybe unique about our company is this has not been one company the whole time, right? Like we were first, like this GPU virtualization company pivoted to this.

41:44And then after that, we're making some changes. And like, I think there's like a versatility of the company and like this ability to move where we think the instinct, we have this instinct where, and by the way, the instinct could be wrong, but if we smell something, we're going to move fast. And I think it's more a testament to I think the engineering team rather than any one of us. And Shul, you had December 19, 2022, you had one of our guest posts, what building Copala 4X? really takes. Estimate inference to figure out latency quality. Build first party instead of using third party as API. Figure out real time because chatGPT and Dali are too slow.

42:23Optimize prompt because context window is limited, which is maybe not that true anymore. And then merge model outputs with the UX to make the product more intuitive. Is there anything you would add? I'd give myself a B - on that. Some parts of that are accurate. Even the context, the one that you called out, models have larger context. Now that's absolutely true. It's grown a lot. But look at an enterprise code base. They have tens of millions of lines of code that's hundreds of billions of tokens. Never going to change. Still being really good at being able to piece together this distributed knowledge that's important.

42:56There are figures there that I think are still pretty accurate. There's probably some that are less so. First party versus third party. I think we're wrong there. I think I would nuance that to be there are certain things that it's really important to first party, like autocomplete. You have a really specific application that you can't just prompt engineer your way out of or just maybe even fine-tune afterwards. You just can't do that. I think there's truth there, but let's also be realistic. The stuff that's coming out for the third model providers, like Cascade and Windsurf would not have been possible if it wasn't for the rapid improvements with 4.0 and 3.5.

43:27That just wouldn't have been possible. So I'll give myself a B -. I'll say I passed, but yes, two hours, two years later. Just to be clear, we're not grading. It's more of a, what would you, you know. Where are they now? What would you have added? What would you like? Yeah, I mean, like that first post, right? Like that was when we had literally, I think that was like a few weeks after we had launched Codium. I think that's like, you know, Suix and I were talking like, maybe we can write this because we're like one of the first products that people can actually use with AI. That's cool. I specifically like the co-pilot for X thing because everyone is so hot.

43:57Everyone was just like, you know, that's all that was. So, but I think like, you know, that we didn't have an enterprise product. I don't even think we were necessarily thinking of an enterprise product at that point. So all of the learnings that we've had from the enterprise perspective, which is why I loved coming back for a third time now on the blog, some of those I think we kind of figured, some of those we just honestly walked backwards into. We had to get lucky a lot of the ways. We had many, we just did a lot. There's so many opportunities and deals that we had that we lost for a variety of reasons that we had to learn from.

44:31There's just so much more to add that there's no way I would have gotten that right in 2022. Can I mention one thing that I think is, hopefully this is not very controversial, but it's true about our engineering team as a whole. I don't think most of us got much value from ChachiBT. Largely because I think the problem was, and this is maybe a little bit of a different thing, it's like a lot of the engineers at the company who have been writing software for like over eight years, and this is not to say they know everything that ChachiBT knows, they don't. They'd already gone good enough at searching for Stack Overflow.

45:00invested a lot in searching code base, right? They can very quickly grab through the code incredibly fast, like every tool. And they've spent like eight years mastering that skill. And ChaiGPT being the thing on the side that you need to provide a lot of context to, we were not able to actually get, like my co-founder just basically never used ChaiGPT at all. Literally never did. And because of that, probably at the time, one of our incorrect sort of assumptions was probably that, hey, like a lot of these passive systems need to get good because they're always there and these active systems are going to be behind.

45:29I think actually Cascade was the big thing. It's a company where everyone is now using it. Literally everyone. Biggest skeptics. And we have a lot of people at the company that are skeptical of AI. I think this is actually important. Why do you hire them? No, I think here's the important thing. Those people that were skeptical about AI previously worked in autonomous vehicles. These are not crypto people. These are people that care about technology and want to work on the future. Their bar for good is just very high. They will not form a cult of this is awesome. This is going to change the world.

45:56They were not going to be the kind of people on Twitter that are like, Like this changes everything. Like software as we know it is dead. No, there are people that are going to be incredibly honest. And we know if we hit the bar that is good for them, we found something special. And I think at that time, we probably had a lot of sentiment like that. That has changed a lot now. And I think it's actually important that you have believers that are incredibly future looking and people that kind of rein it in. Because otherwise you just have, you know, this is like autonomous vehicles. You have a very discreet problem.

46:25People are just working in a vacuum. and there's no signal to kind of bring you down to reality, right? You have no good way to kill ideas. And there are a lot of ideas we're going to come up with that are just terrible ideas, but we need to come up with terrible ideas. Otherwise, like how does anything good come on? And I don't want to call these skeptics. Skeptics suggest that they don't know. They're realists. They're the type of people that when they see waitlist on a product online, they just will not believe it. They will not think about it at all. Kudos for launching without a waitlist.

46:48Yeah. Yeah. We, by the way, we will never launch with a waitlist. We will never launch with a waitlist. That's the thing at the company. We'd much rather be a company that's considered the boring company than a company that launches once in a while and hopefully it's good. My joke is generative AI has gotten really good at generating waitlists. Absolutely. Also, just to clarify, both of us used to work in a autonomous vehicle, so it doesn't come across as... We love that technology. We love it. I love hard technology problems. That's what I live for. Amazing. Just to push back on the first party thing, I accept that the large model labs have just done a lot of work for you that you didn't need to duplicate.

47:26But you now are sitting on so much proprietary data that it may be worth training on the trajectories that you're collecting. So maybe it's a pendulum back to first party. Yeah, I mean, I think we've been pretty clear from a security posture perspective. I think there's both customer trust and... I think that there is signals that we do get from our users that we can utilize. There's a lot of preference information that we get, for example. Which is effectively what you're saying of our trajectories. Go ahead. I will say this. The super complete product that we have has gone materially better because of us not only using synthetic data, but also getting the preference data from our users of like, hey, given these set of trajectories, here's actually what a good outcome is.

48:10And in fact, one of the really beautiful parts about our product that is very different than a chat GPT is we can not only see if the acceptance happened, but if something more than the acceptance happened. And it happened even more than that. Let's say you accepted it, but then after accepting it, you deleted three or four items in there. We can see that. So that actually lets us get to even better than acceptance as a metric. Because we're in the ultimate work output of the developer. It's the preference between the acceptance and what actually happened. If you can actually get ground truth of what actually happened, this is the beauty of being in the ID, then you get a lot of information there.

48:43Did you have this with the extension, or is this pure windsurf? We had this with the extension. Yeah, okay, right. The WinSearch just gives you more of the ID. Yes. So that means you can also start getting more information. Like, for instance, the basic thing that Anshul said, we can see if a file explorer was opened. It's actually just a piece of information we just cannot see previously. Sure, yeah. A lot of intent in there. A lot of intent. Second one. Oh, boy. How to make AI UX your mode. Oh, man. Isn't that funny that we now created the full UX experience with an ID? I think that one is pretty accurate.

49:14That one's an A? I think that one I'll give myself. I think we were doing that within the extensions. I still think that's true within the extensions as well. We got very, very creative with things. Like Rune mentioned the idea of just essentially rendering images to display things. We get creative to figure out what the right UX is doing there. We could create a really dumb UX that's like a side panel, whatever. But actually going the extra mile does make that experience as good as it possibly can there. But yeah, now look at some of the UX that we're able to build in Windsurf, and it's just like, it's fun.

49:44The first time I saw, because now we can do command in the terminal, like you can not have to search for a bash command. The first time I saw that, I was like, I just started smiling. And it's not like Cascade, it's not like a gentix system right in the lab, but I'm like, that is just a very, very cool. We literally couldn't do that in VS Code. Yeah, I understand that. I've implemented a 60-line bash command called please, and you can do that. Oh, wow. That's cool. Yeah, so please, English, and then... You know, that's actually really cool, because one of the things I think we believe in is actually I like products like autocomplete more than command purely because I don't even want to open anything up.

50:19So that thing where I just can type and not have to press some button shortcuts to go in a different place, I actually like that too. And I actually adopted warp, the terminal warp, initially for that because they gave that away for free. But now it's everywhere so I can turn off a warp and not give Sequoia my bash commands. I'm with you. No, I use warp. No, no, look. I use... Okay, I don't know. I'm going to go on a rant. Hopefully somebody... This is like Word product feedback. But they basically had this thing where you can do kind of like pound and then write a natural language. Yeah, you still do too.

50:54But then they have also the auto-infer of what you're typing is natural language. And those are different. When you do the pound, it's only like it gives you a predetermined command. When you talk to it, it generates a flow. Okay. It's a bit confusing of a UX. But going back to your post, you had the three Ps. Yes. of AI UX. What were they again? Present, practical, powerful. Actually, that was really good. I liked it. And I think in the beginning, being present was enough. Even when you launch, it's like, oh, you have AI, that's cool, other people don't have it. Do you think we're still in the practical where the experience is actually, the model doesn't even need to be that powerful, just having better experience is enough?

51:36Or do you think really being able to do the whole, because your point was like, You're powerful when you generate a lot of value for the customer. You're practical when you're busy wrapping it in a nicer way. Where are we in the market today? I think there's always going to be room for practical UX. I mean, the command terminal, that's a very practical UX. I do think with things like Cascade and these agentic systems, we are starting to get onto powerful. Because there's so many pieces from a UX perspective that make Cascade really good. There's really micro things that are just all over the place.

52:09But as we're streaming in, we're showing the changes, we're allowing you to jump in open diffs and see it. We can run background terminal commands. You can see what's running, background processes are running. There's all these small UX things that together come to a really powerful and intuitive UX. I think we're starting to get there. It's definitely just a start. And that's why we're so excited about where all this is going to go. I think we're starting to see the glimpses of it. I'm excited. It's going to be a whole new vlog, yeah. Yeah, awesome. First of all, it's just been really nice to work with you.

52:39I do work with a number of guest posters and not everyone makes it through to the end and nobody else has done it three times, so kudos. We're up for a hat trick. This one was more like the money one. It's funny because I think developers are quite uninterested in money. Isn't it weird? Yeah, I don't know if this is just the nature of our company. I think there's some people who said there's all the San Francisco AI companies and everyone's hyping each other on the tech and everything, which is great, the tech's really important. We're here in Mountain View, beautiful office. We just really care about actually driving value and making money, which is kind of like a core part of the company.

53:20I think maybe the selfish way of saying that, or a little more of the selfless way, is we can be kind of like this VC-funded company forever, but ultimately speaking, if we actually want to transform the way software happens, we need this part of the business that's cash-generative that enables us to actually invest tremendously in the software and that needs to be durable cash. Be cash that churns the next year. And we want to set ourselves up to be a company that is durable and can actually solve these problems. Yeah, excellent. So for people, obviously we're going to link in the show notes, but for people who are listening to this for the first time, I had a lot of trouble naming this piece.

53:58So we originally called it, you had like how to make money something. thing. It was super bitty. I apologize. I was super bitty. I think I was writing part of that journey on a plane flight, so I apologize for that. He had like $3 signs in the title. I was like, I can't do that. So it's either building AI for the enterprise, and then I also said the worst, the most dangerous thing an AI starter can do is build for other AI startups, which I think both of you will co-sign. And I think basically the main thesis, which I really liked, was go slow to go fast. If you actually build for like security, compliance, personalization, usage analytics, latency budgets, and scale from the start, then you're going to pay that cost now, but eventually it's going to pay off in the long run.

54:42And this is the actual insight. You cannot do this later. If you build the easy thing first as an MVP, it's like, yeah, I'll just ship it with whatever is easy to do. And then you tack on the enterprise ready.io set of 12 things that you have. You actually end up with a different product or you end up worse off than if you had started from the beginning. So that I had never heard before. Yeah, I mean, we see that repeatedly. I mean, just like right now, we have a lot of customers in the defense space, for example. We're going through FedRAMP accreditation right now. And people that we're working with, they saw all the fact, like, oh yeah, we already have a containerized system.

55:18We can already deploy in these manners. We've already gone through security. They're like, oh, you guys are going to have a much easier time doing this than most companies that are just like, okay, we have a big SaaS blob and now we need to do all these things. It might sound like a really deep thing. I think it's just anyone who's worked for an extended period of time at a company on a certain project has probably seen this happen. The technology just keeps on improving. And then you realize that you have to now re-architect your whole system to get something improving. Just making that kind of change when you've invested so much effort.

55:51People have important hours. They're emotionally invested. Whatever it might be, it's really hard to make that change. So I'm sure we're going to hit that also. Like, yes, I think we've done things a little bit earlier than most companies. I think we're going to hit points where we're going to see parts of our systems where we're like, oh, we really need to re-architect that. Actually, we've definitely hit that already. And I think that's just like at the project level, the product level, or is that like your whole company? And I think the thesis behind here is like to some degree your company needs to have this DNA from the beginning.

56:21And I think then you'll be able to go through those bumps a lot more smoother and be able to drive the valley. Can I say two points? So first point I'd like to say is, this is something that me and Douglas, my co-founder, talk about a lot. It's like, you know, there's this constant thing of like build versus buy. I think the answer is like, a lot of the time the answer should be buy, right? Like we're not going to go build our own sales tool. Just go buy Salesforce, right? That's kind of dumb. That's undifferentiated. And the reason why you go with buy instead of build is, hey, like look, the ROI of what exists out there is good.

56:51From like an opportunity cost standpoint, it's better to actually go out and buy it than build it and do a shittier job, right? There's a company that's actually going out and focused on that. But here's the hidden thing that I think is really important when you go out and buy. You're losing a core competency inside the company. And that's a core competency you can never get. Or it's very hard. Startups are so limited on time. Let me just say, let's say as a company, we did not invest in, I don't know, model inference. We have a custom inference runtime. We give that up right now. We will never get it back.

57:20It's going to be very hard to get it back. You can't just use VLM and TensorFlow. That would be our only option. Or just let me put it, if we use VLM, we would not be talking with you right now. Like, yeah, we would have, yeah. But the point is, this is more a question of like, you know, I try to think about it from first principles. Like, Google's a great company, makes a lot of money. What happens if they actually made the search index of the product something that someone else bought for them? It's like, they could. Maybe someone else could have done a good job. Maybe that's like a bad example.

57:46But like, particularly because Google is a search index. But like, tough luck getting that core competency back. You've lost it, right? And I think for us, it's more a question of what core competencies do we need inside the business? And yeah, sometimes it's painful. Sometimes actually some of these core competencies are annoying. Sometimes we'll be behind what exists out there. And we just need to be very honest. That's where the truth-seekingness of the company matters. Are we really honest about this core competency? Can we actually keep up? The answer is we truly can't keep up. Then why are we keeping up with the trade?

58:15We should just buy. Let's not build. The answer is we can and we think that this will differentiatedly make our company a better company in the long term. then the answer is we need to. We need to, because the race is not won in the next year. The race is won over the next five, 10 years, right? Maybe even longer, right? So that's maybe one thing. And then the second thing, actually from the enterprise standpoint, I think one of the unique parts of the company now is we have both this individual and enterprise that usually companies stick to one or the other. And I think that needs to be part of the DNA.

58:42I think kind of early on in the company, as Anshul said, I mean, there's stories of companies like Dropbox and stuff that tried, and Dropbox is an amazing company, fantastic company that one of the fastest growing consumer companies of all time consumer more on the software company of all time but yeah like when you have everyone sort of product oriented on the consumer side the enterprise is just it's checking off a lot of boxes that ultimately do not help the consumer at all doesn't help your growth metrics and effectively if the original group of people didn't care it's incredibly hard to get them to care down the line right yeah it's incredibly hard why do it and you need to feel like hey this is like this is an important part for the company's viability.

59:20So I think there's a little bit of the build versus buy part and then also the cultural DNA of the company that I think are both really important and it's something we think about all the time. I have the privilege of being friends with you guys off the air. I don't feel like, I think I know your work history. You say cultural DNA, but it's not like you've built giant enterprise SaaS before, right? Yeah. So where are you getting this from? Yeah. In fact, In fact, I think the only other sort of, I guess like, you know, when I look at my previous internships, maybe Anshul can provide some context here.

59:54It's like I worked at like LinkedIn and then Quora and then Databricks. And to be honest, like I was not that interested in B2B ETL software that much. That's not what drives me when I wake up at night. So because of that, I decided to go work in an autonomous vehicle company immediately after. I think part of it comes down to maybe a little bit of the unique aspect of the company. and the fact that we pivoted as a company is like, we want to be a durable company. And then the question is, how do you work backwards from that? There's a lot of things about being very honest about what we're good at and what we're not good at.

1:00:24Like, I think surprisingly enterprise sales is like, not something that like it came out of the womb knowing how to do. I didn't really know. And because of that, like, obviously like a lot of sales happen between sort of folks like Unshul and I helping partner with companies. But very soon we hired actually a VP of sales and we've actually been deeply involved in the process of scaling out like a large go-to-market team. And I think it's more a question of like, what matters to the company and how do you actually go out and build it? And I think one of the people that I think about a lot actually is someone like Alex Wang.

1:00:51He dropped out of college. He was a year younger than us at MIT. And he has figured out how to constantly change the direction of the company. Effectively, it starts out as like, you know, human task interface, then an AV labeling company, then a cataloging company, then now a generative AI labeling company. And every time the revenue of the company kind of goes up by a factor of 10, even though the business is doing something Now it's all about military contracts. Yeah, now it's probably going to be military, and then after that it might be taking over the world. He's just going to keep increasing the stakes, and there's no playbook on how this really works.

1:01:19It's just a little bit of solve a hard problem and work backwards from that, right? And we'll get lucky along the way. I don't think, you think everything from first principles to the best of our abilities, but there's just so many variable unknowns that, yeah, we don't know everything that's happening in every company out there, and everyone knows how fast the AI space is moving. We have to be pretty good at adapting. I want to double-click on one thing, just because you brought it up and it's a rare thing to touch on. VP of sales. We talk to pretty early-stage founders mostly. They don't usually have a pretty built-out sales function.

1:01:54Advice, what kind of sales works in this kind of field? What didn't work? Anything you can share with other founders? I think one of the hard parts about hiring people in sales, and Graham Anshul can also attest, we have an amazing VP of sales at the company. One of the things is if you're purely a developer, salespeople, their job is to talk really well, prim and proper. Very obvious if you hear me talk, I'm not a very polished person. You're great by the way, I don't know. Compared to most pure, pure salespeople. So actually just checking based on the way they speak is not that interesting. I think what matters in a space like ours that is moving very quickly, I think is intellectual curiosity is very important.

1:02:37Intellectual horsepower. power, understanding how to build a factory. I'm not trying to minimize it, but in some ways, scales, you need to build something incredibly scalable here, right? It's almost like every year you're kind of making this factory twice, thrice, maybe as big, right? Because in some ways you have people that are quota carrying, you need some number of people and you need to make the math work. And you actually, the process of building a factory is not something you can just take someone who is a great rep at another company and just make them build a factory. This is actually a very different skill.

1:03:06How do you actually make sure you have hundreds of people that actually deeply understand the product? Actually, Unshul works very closely also with sales to make sure that they're enabled properly, make sure that they understand the technology. Our technology is also changing very quickly. Let's maybe take an example on how our company is very different than a company like MongoDB. When you sell a product like MongoDB, no one at the company is interested in how the data is being stored. It's not that interesting, right? I love databases. I would be interested. But most people are like, solve the application problem I have at hand.

1:03:32People are curious about how our technology works. People are curious about RAG, right? People that are buying our technology. And imagine we had a sales team that is scaling where no one understands any of this stuff. We're not going to be great partners to our customers. So how do you create almost this growing factory that is able to actually distribute the software in a way that is true to our partners and also at the same time, like taking on all the new parts of our products, right? Like they're actually able to expound on new parts of our product. So, sorry, that was more a statement of like building a scalable sales team, But in terms of who you hire is, you just need to have a sense.

1:04:05In some ways, this is maybe an example of talk to enough people, find out what good looks like potentially in your category, and find someone who's good and humble and willing to work with you. Yeah, that's just generic hiring. It's just generic hiring. I think here, there's sales for AI or sales for AI infrastructure. And then there's also the sales feeding into products in a way that we're talking about here, where they basically tell you what they need. I imagine a lot of that happened. I think a lot of that happened. I mean, still happened. And Rune mentioned, like, Rune, myself, a number of other people who are developers by trade engineers.

1:04:38Like, we're pretty involved in this sales process because, like, there's a lot to learn, right? Like, before we went out and hired a sales leader, like, yeah, if all we went is, like, neither of us had ever done a sale for Codium in our lives, and we went and tried to find a sales leader, we probably would have not hired the right person. Yeah, we had sold the product to, like, 30 or 40 customers of that kind. Like, we had done, like, hundreds and hundreds of deals cycles ourselves, personally. right without we read a lot of books and we just did a lot of stuff and we learned like what messaging worked like what did we need to do and then i think we found like the right person right a second ver like graham's amazing and who we brought on as our vp of sales that just has to be part of the nature and it doesn't stop now like just because we have a vp of sales and and people dedicated to sales it doesn't stop that we can't be involved or like engineering can't be involved right like we have lots of people like we hire plenty of deployed engineers These are people like Palantir kind of made this really famous.

1:05:31Deployed engineers work very, very closely with the sales team on very technical aspects because they can also understand what are people trying to do with AI? As in, they work at Codium as deployed engineers? Yeah. And they partner with our account executives to make our customers successful and learn what is it that people are actually getting value with AI. That's information that we keep on collating. We will both jump into any deal cycle just to learn more. because that's how we're going to just keep on building the best product. It comes back to the same, like just care, I don't know. And hopefully we build the right thing.

1:06:04Cool, guys. Thank you for the time. It's great to have you back on the pod. Yeah, thanks a lot for having us. Hopefully in a year we can do another one. Yeah. You'll be 10 billion by then. Yeah, exactly. At this rate, then next year. We try not thinking about that. Try to not be a zero billion company. There's that, yeah. All right, cool. That's it. Awesome.

1:06:29Thank you.