Windsurf CEO & Co-Founder, Varun Mohan: AI's Biggest Acquisition to Date!

Varun, I'm so excited for this, dude. I've heard so many good things, by the way, from Lee Fixel, from Neil Mehta, and from many others. Thank you so much for joining me, man.

Thanks a lot, Harry, for having me.

Not at all, dude. I've literally just been running, and I've been listening to some of your shows before. There were a couple of segments where I was like, “Damn, I wish we had double-clicked on that.” There was one that I wanted to start with.

You said it's very rare that the first thing you believe will be the right thing. How have you changed your mind on what a truly great idea is versus what's not?

1. When to Give Up vs When To Stick at It

I think there's a lot that's right about the likely Peter Thiel-ism that you want to pick something that seems a little bit not obvious to start with, for whatever company you're starting. The problem is that most ideas that are not obvious are just bad ideas. Most ideas that are unconventional are not good ideas just because they're unconventional. I think people sometimes forget that.

At a high level, though, if you pick an idea that is obvious to everyone, there's probably no alpha. A big company is going to go out and already beat you to the market because it has more distribution, resources, and capital than you. Startups usually win by picking ideas that are unconventional to the public, but you need to be humble enough to understand that there's probably a good chance your weird idea is not actually a good idea.

What do you believe was your unconventional insight when you made the pivot to Windsurf?

I could even start before this. The first idea that we had—even our company name has changed twice at this point—was called Exafunction. When we first built GPU virtualization technology, we thought GPU workloads were going to power the world. That was the mission there. A lot of us at the company had previously worked in autonomous vehicles and AR/VR, and we had a fairly small team that was actually right about GPUs becoming very popular.

We basically said, “NVIDIA is going to sell a lot of GPUs.” The thing we were wrong about was how diverse the GPU workloads were going to be. We thought a bunch of different model architectures would be run. We thought there were going to be hundreds of different model architectures, and we were wrong. All of them ended up being transformers.

In a world in which all the architectures look the same, there's very little reason for us to be a differentiated infrastructure provider in that category, so we needed to pivot at that point. That's one of those things where you don't know going into the market that that's how the world is going to turn out. We were just wrong about our hypothesis, and sometimes you have a take that is not very obvious at the time and then you can be wrong.

2. “Never Fall in Love With Your Idea”

Totally. The trouble is, many people are in love with their thesis. That's why I hate thesis-driven investors, bluntly. Many people are in love with their ideas, and they're told that the true grit and persistence of an entrepreneur is what separates those that win from those that don't. How do you think about that versus a brilliant statement, which I agree with, that you said: “Never be too in love with your ideas”?

I think this is the hardest part about starting or building a company in the first place. It requires these 2 almost countervailing beliefs in your head: irrational optimism, because if you don't have any optimism at all, you won't do anything and you won't get out of bed, and uncompromising realism.

Every single day, you need to be asking yourself, “Do we have a reason to exist?” If the answer is not really, you need to change your mind really fast and reorient the entire company really fast. One of the weird things about startups is that you don't win an award for doing the same wrong thing for longer.

It might feel better to tell your coworkers, investors, and friends, “Hey, I'm still doing the thing I did.” But down the line, when you fail, none of them will care.

What idea do you think that you are too in love with today?

For me as an investor, it's discipline around portfolio construction. I love the belief in a disciplined investor and the craft of portfolio building. The challenge is that, in today's world, you have to break most rules. It doesn't mean you're a cowboy and you're gambling, but it means you're much more elastic than the more concrete investor mind. That's what I'm too in love with. What do you think you're too in love with?

If I was to go empirically, we were too in love with our ideas every time. Other people looking in from the outside might have been like, “This company has pivoted multiple times,” and viewed that as a positive outcome, but I wish we had done it faster.

I still beat myself over the head about why we didn't pivot from GPU virtualization to the code AI company 3 months earlier. I think we had the signals, but we waited until the companies we were working with were starting to go belly-up before we actually pivoted the company.

A lot of our customers at the time were autonomous vehicle companies, and it was the peak ZIRP era. Then, in the middle of 2022, when a lot of them were unable to raise their next funding round, that's when we started to question, “Hey, the market is changing. The technology is also changing, but our future customers don't look like they're going to be able to satisfy our market.” I wish we had done that faster.

The same is also true for ideas like Windsurf. I think we knew agents were going to be very powerful, and we could have built Windsurf a couple of months earlier. I think we should have done that if we could have.

Can I ask you a question? I just had the CEO of Fiverr on the show, and he said that time to clone is one of the most important things that have changed over the last few years. Time to clone is the amount of time it takes for someone to copy exactly what you have.

My question to you is: How important is it to be first if time to clone is shorter than ever before?

Being first does 2 things. I think it's a signal of how you're running the company, and the second thing is that it allows you to learn faster.

I'll double-click on the first one. Companies that are usually first to a new paradigm are companies that are willing to disrupt themselves. They're organizations that are open to the idea of changing on a dime, very quickly, and they're always investing in technologies that are not incremental and are willing to break themselves. I think that's a good organization in a category like software or code AI, where the space is changing so quickly.

Then, 2, it boils down to what it means if you're first. It means you get to learn from the market faster, and that means you're first to the next idea, too, because you see where all the dead bodies are in your category.

3. What Founders Get Wrong About Being First

One of the nice things that I like to think is: If we have a product in the market earlier, what are all the things we can learn in the first month that enable us to build the next product in the market as well? I think that could give us a compounding advantage with time.

Is it not more helpful seeing someone else go first, seeing what mistakes they make, learning from their mistakes, leveraging the cost that they have incurred, and then doing it without that cost for you?

I think the problem in software in general is that they could have made a lot of mistakes internally during research and development that we could never take a look at. Organizationally, now I believe our company has so much wisdom in our category that there are ideas we would not even touch because we're just like, “Hey, we've tried this before, and it didn't actually work.”

That's something that's built into the DNA of the company as we continue to innovate, and it's just not easy to look at from the outside.

What have you tried before that didn't work that the world doesn't know about?

We shipped a beta version of this product, but we were dogfooding it for such a long time. I'll give you a couple of examples here.

The first thing is that we actually shipped a beta product for code review last year, and we tried out different ways of shipping a code review product. We had a Chrome extension. We did something internally where we built a parallel website, and we were able to try a bunch of things internally. None of them felt quite right.

A couple of weeks ago, we actually shipped a code review product, and it feels much better and is providing a lot more value. We shipped it the way we did because of all the failed attempts we made last year.

I'll give you a second example here. For the code agent product that we launched with Windsurf, we actually had our first cut of that product at the beginning of last year, and it was not good. It was not good for a variety of reasons, and that enabled us to go back to the drawing board and fix up the different elements that would allow us to ship Windsurf.

We needed to get much better at codebase understanding, and the models needed to get better. Once the models had gotten better, our internal R&D on codebase understanding had gotten good enough that we were ready to go and ship the product. This is one of those things where, if we had just waited for the rest of the world to have it, we would have needed to play catch-up on multiple axes just to ship the product.

Can I ask you: do you advise founders to raise as much as possible early because it is about the number of at-bats that you have and the experiments that you can take? If you raise more, you have more experiments. Fundamentally, do you advise that, given the experience that you have?

We're obviously—just to shed some light here—we actually raised our Series A on the GPU virtualization idea. Greenoaks actually led that round.

They led your seed as well?

Yeah, they led our seed too. Whether or not they should have invested in the Series A on that one, I'll leave that to the audience. But I think what that did give us is the confidence that, if we pivoted, we would still have the cash to go out and pursue an idea.

We actually launched Kodium, the extension product, entirely free before this. We were able to do that because of the infrastructure expertise inside the company, but also because we confidently knew we had cash in the bank to go out and actually ship this product without having to worry about any details there. So I actually agree with you: it does give you more shots at that. But I think you need to be a company that is able to pivot very quickly.

4. What Would Windsurf Do If They Had Unlimited Resources

Most companies, I would say, when they have 10, 15, or 20 people, are unwilling to change their idea entirely. We, on the other hand, decided we wanted to work on Kodium over a weekend. My co-founder and I told the company on Monday, and everyone started working on it that Monday, despite the fact that we were making a couple of million in revenue off the previous business.

Is there anything that you can structurally do to increase the response time of an organization to move faster post-pivot?

I think the answer is that, for a startup, one of my true beliefs is that companies don't succeed because they do many things well. They succeed because they do maybe 1 thing really well. Having 1 good idea already is like a miracle for most startups.

When you think about a company from that perspective, think about 2 companies. Any product has some sort of exponential curve at which it's able to grow. There's some R value attached to a product. The right thing for a startup to do is always focus on the product with the higher R value. It never makes sense to divert your resources to work on 2 different products that have different exponential growth curves if they're completely disjoint.

So when you do a pivot, I think the right answer is that you should just give up what you were doing in the past, because the thing you were doing in the past probably will have no relevance to your business going forward. The revenue multiple on that business is not going to look at all like the revenue multiple of the other business. If you can go cold turkey and make your organization work completely on the new thing, you're more likely to succeed.

But that's scary, right? You need to tell people, tell your investors, and tell your customers that you're no longer going to support that. But I think once you make the tough decision, it's really easy.

Dude, revenue cannibalization when you're doing millions in revenue is hard. So, yes, I completely agree with you. You said that success is about doing 1 thing really well, and it's hard enough to have 1 thing. You have that, but what thing would you most like to do that you're not doing because you retain that element of a focused mindset?

In our category, a lot of our users of Windsurf are actually non-developers. They're people that are building apps, and they're using it for productive use cases. Internally at our company, we have someone who's a non-developer who leads partnerships and has used our product to build apps that replace a lot of sales tool spend—over $500,000 of sales tool spend internally.

They built apps inside the company for a partner portal, a quoting tool, and so on and so forth. These are sales tools that in the past cost hundreds of thousands of dollars a year.

They've coded $500,000?

Yeah. They built apps inside the company for a partner portal and quoting tool, and so on and so forth. These are sales tools that in the past cost hundreds of thousands of dollars a year.

They deserve a pay rise, right?

Yeah, I mean, we should get—we should consider that. But the reason why that was the case before, not to go on a tangent, was because no one really wanted to build these very bespoke tools. These are very bespoke tools that do a singular function, and no single company wanted to build them out themselves in the past.

Now, with software being so cheap to build—ephemeral software or simpler software being so cheap to build—you can have nontechnical people building these apps. I think, Harry, one interesting avenue for us is: how do we make that user much more productive than they are right now?

But there's always this tension. If we make that user much more productive, we might be giving up the ability to make developers that operate on large codebases much more productive, too. It's just a focus game.

Is Windsurf about making engineers 10x better, or is it about making the normal person able to be an engineer?

I think we are focused on the former. We're focused on the former, and a consequence of that is the latter, because the technology underneath is capable of doing that. But the focus is definitely the former.

Will Cursor and you converge to eat the Lovables and Bolts, and will the Lovables and Bolts converge to try and eat you?

I think this is a really common question we get. The tools that are very focused on the Lovables and Bolts, which are very focused on the non-developer, are going to need to build out more and more tunables and more and more ways to configure the product with time.

For us, if we can deeply understand code—large codebases—it will naturally follow that, with very little effort, nontechnical people can build apps. But my point is, if we build for that use case right now, we're going to be forgoing the ability to help developers.

5. Will Lovable and Bolt Ultimately Compete with Windsurf and Cursor

I think it will converge over time between both of these categories. A company that deeply understands your codebase will be able to, with very little natural language, build an entire app that is consistent with existing codebases inside the company.

If you had infinite resources—I'm so enjoying this, by the way. I'm sorry, I had this beautiful schedule, but fuck it—if you had infinite resources, is there anything that you would do differently from how you're doing it today?

I think we would be making many more bets. We'd be making many more bets inside the company, trying many more things. As I said, probably 50% or more of the things that we try inside the company actually fail. We're investing a lot of our product technology in things that are in the future, and most of it fails.

Actually, I would like to fail even more. But the weird thing about startups is that the 1 thing that works pays for the hundreds of things that fail internally at a startup.

I spoke to Neil Mehta about stuff that I had to ask you before, and he said, “You do have to ask him about how he builds product and his product-building cycle.” You mentioned there that 50% fail. Can you talk to me about some unconventional ways that you think about internal product building that you think are important?

I think there's conventional wisdom from other people that a company with more engineers is just going to succeed. But that makes software engineering and R&D feel like a factory-building process.

I think the right way to look at it is that when a product or an idea has no legs and you're proving it out, you should actually have very few people working on an idea. This is something everyone will understand: imagine having 10 people working on something that has not been proven out. Everyone has opinions and everyone has ideas, and nobody's ideas are wrong because no one has proven anything out. So it's very hard to get alignment, and it's very hard for people to work in 1 direction without causing communication issues.

6. The Product Development Rule That Breaks All Startup Rules

Instead, what's really good is to have a handful of people with an opinionated stance who can go out and prove out an idea. Then the question is: if you can go and get a nugget of value, how do you know when to stop working on it?

I think there's this interesting piece of wisdom that we've built, and a lot of us at the company have worked in hard tech before this, at companies like autonomous vehicle companies. When you have a new, great idea, even the crappy version of that idea is already amazing.

It already proves something amazing, right? For instance, when we built the first working version of the agent in Windsurf, even the crappy version was able to do things that we were never able to do in the past 8 or 9 months, right? We were like, “Okay, this thing has legs.” At that point, once you’ve proven the crappy version has legs, you can then resource more people on the project to actually pursue it more deeply.

That’s no wonder Neil loves you, because he always talks to me about the real customer delight moment and that shock and awe that people feel when they have that first agent experience that you mentioned. I totally get that. Can I just dig in on a couple of elements before we carry on? You mentioned a handful of people. How many is that? How do you structure these teams on new bets?

It’s maybe 3 or 4 people.

Okay. And a couple of engineers and a designer.

Yeah. Or actually, in the case of a purely systems technology, it could be just pure engineers building this out. One of the cool parts about our product is that we are a developer product, so our developers themselves have some intuitions about a crappy version and how useful it could be—at least the V0, right? Because we’re building a product for developers.

Budget-wise and time-wise, do you set that? Do they set that? How does that work?

I don’t think we actually think about that, and I think that’s partially because we’re in an unconstrained market right now, right? The value of great technology that could accelerate software development is so valuable to our customers that, for us, broadly speaking, we don’t think about it from the perspective of, “What is the budget of a particular project?”

What we do look at inside the company is what progress we’re unlocking in a project over time, and whether or not we should decide to move on and work on something else, table it, and work on it later. That is something that we decide, and that’s not a democratic process inside the company. It is a little bit of a top-down process inside the company.

Is there anything that you’ve tabled where, with the benefit of hindsight, you’re like, “Oh, Varun, I should have kept going with that one”?

Yeah, I think so. An example of something we probably did table was the autocomplete experience, which is the first product that we actually built out. I think we actually delayed building a much better product experience sooner rather than later.

7. The Cold Truth About Moats in the AI Era

Part of the reason why the product experience wasn’t as good, actually, was because we were stuck in VS Code, and VS Code didn’t give us the UI capability to make the product much better. Once we had Windsurf, we were able to invest much more in the capability.

You mentioned VS Code there. It brings me to the topic of moats and defensibility. I’m obviously an outsider to this field, as well as being a terrible British podcaster. Moats are dead in a world of AI. You’re not blind to this. Everyone says, “Cursor, Windsurf—I can switch between the two.” Help me understand: are moats dead, and how do you think about that?

I think startups, by and large, this idea of a startup having a moat is usually kind of silly, for the most part. Take the conventional 7 Powers, if anyone in the audience has actually read the book.

I love it.

Yeah, it’s a great book. I think it’s just premature for a startup, for the most part, because, okay, fine, you have a company with 50 engineers. You could have the best engineers in the world. I think we have amazing engineers. A majority of our engineers are from MIT. I think we do get the top few percent of MIT to come to the company.

Still, if we have 50 to 100 engineers, it’s only hundreds of engineering years that have gone into our product. This is not something where, ultimately, someone else can’t build something in this space as well. I think the only moat in our category is speed. It’s kind of like what I just said: learning where the dead bodies are, learning how to compound an advantage.

Maybe an example of this that I like to bring up is even a company like NVIDIA. I think everyone looking from the outside in is like, “CUDA is the real moat,” or something like that. I think that’s just inaccurate, right? When you look at large companies like OpenAI, Anthropic, and Google—let’s say Google, if they were buying NVIDIA—I know that they build their own TPUs. They spend tens of billions of dollars on chips. Are you telling me that if CUDA didn’t exist, they would not use NVIDIA GPUs? No. They’d find a way to write assembly, the lowest-level code, and make that run on the GPUs. It’s that expensive for them, right?

The reason why people use it is that it’s just awesome. They’ve made it really capable at doing low floating-point math. They’ve made the interconnect really good. The compute’s really fast. Every year, they have a ticking time bomb on their head: if they don’t make the hardware, the interconnect, and the memory bandwidth much faster every year, they’re going to lose. Their profit margin is going to shrink, right? AMD will be on their case.

That’s a little bit of a surprising feeling. NVIDIA doesn’t have the same properties as a company like Google, right? But it’s still one of the most valuable companies out there.

I agree totally in terms of the moats for startups. If you have 2 companies starting at the start line today, but 1 of them becomes part of a very large company—say, an OpenAI or an Anthropic—and they suddenly have distribution, brand, and resources to buy chips at scales that are unparalleled compared to what any other startup can do, suddenly 7 Powers becomes increasingly prominent and moats exist.

No, I think the reason why some of this wisdom is potentially not correct is that speed is still important in that case, right? And the reason why is: why does a startup ever win? Why does a startup ever win in an important category? Why did Google win in the early 2000s when Microsoft was already a behemoth at that point?

I think it’s just that if a company has good insights and is able to out-execute strategically another company, they will win. They will win in a space.

I would argue that distribution is more important than speed. Listen, you’re the multibillion-dollar founder, so please correct me, but partnership agreements are really what propelled Google in the early days to be so successful.

But it was also that there were lots of companies in the category and they had the best product, and for that reason a lot of people wanted to partner with them. Maybe let me put it this way: our space is very, very valuable, I would say. But if you actually look at a lot of the hyperscalers, their products in the category are not amazing products, even though they have a lot of distribution already. Why is that?

I think it’s actually because it is hard to marshal together talent to actually go out and execute in this category very quickly, right? We’re the kind of company where, right now, we’re shipping a major release every 1 to 2 weeks. Name a large company that is able to learn that quickly.

Why do large companies suck at velocity of development when the market is as hot as it is today?

I think it’s existential dread. A startup has existential dread over whether or not it can survive if it doesn’t ship fast enough, if it doesn’t learn fast enough.

If I’m inside a behemoth—like, I’m inside Amazon, and Amazon has a product in our category right now—do you think the employees working on this are worried about whether they’ll have a job in 6 months if they don’t ship a great product? If we had shipped the same quality product that some of these hyperscalers have shipped, we’d have been out of the market a year ago. But they probably still have their jobs right now.

It’s the 7-days-a-week culture that’s becoming the norm again in Silicon Valley, huh?

We’re an in-person company, actually, right now. Yeah, we’re a 100% in-person company.

8. Remote vs. In-Person

Can you build a company today remotely as efficiently as the in-person, 7-days-a-week Silicon Valley specialness that you’re seeing return to the Valley again?

I think it might just be a little bit harder, right? I think you need to be a much more principled company to start with. But I also think it’s just an unfair advantage if a company is able to get its engineers in the same room and on the same page every 5 minutes if necessary, right?

It’s an unfair advantage on speed compared to a company where people are in different time zones, where you don’t know when you can reach out to someone. Right now, if it’s 2 or 3 PM, everyone at the company can be called, can be brought into a room at that very moment, right? So it just makes your flexibility a lot faster.

In the early days, Harry, when I was talking about how obvious it is that your first idea, or your ideas, are not going to be accurate, you should be able to pivot extremely fast and marshal everyone at the company as quickly as possible.

Do you think brand power is important in your category? People associate with being a Windsurf user or a Cursor user. Do you think brand has that same power that it does in other categories?

I think having a good, large brand is just helpful. It enables you, as you ship more and more new products, to have more and more people be able to use them and not have to build the user base up from scratch.

But if I was to remind everyone, a year or two ago, probably in Silicon Valley, GitHub Copilot was the product that everyone was talking about. At that time, and if I was to talk about it a year ago—actually, a bit over a year ago—there was the Devin launch. For 3 to 6 months, I was not hearing anything but Devin from everyone.

I think in our category, we need to prove ourselves almost every day. If in 3 months we don't ship something amazing to our users, we will become irrelevant to a lot of them. If we don't keep up with the pace of innovation, we will become irrelevant.

So I think it's a little bit of: if you can maintain and continue to innovate at a breakneck pace, the brand is definitely helpful, but I don't think the brand gives you the right to move slower as a company.

But should these businesses not be valued inherently less, or at a much lower multiple, if their sustenance of value is able to deteriorate more quickly than ever before? As you mentioned, even GitHub Copilot is a brilliant example, and then suddenly has such a fast reduction in value. Should they be valued in the same way?

I think there are still qualities of our company that we haven't really talked about, such as having a large enterprise business, being wall-to-wall at very large Fortune 500 companies, and being able to work properly for large teams. That has inherent switching costs for the business—not the same class of switching costs as some products like Salesforce yet. I don't think we've built that out.

There's a trade-off where, if you focus so hard on making your product difficult to switch off of, but you also don't improve your product fast enough, people will just switch onto the better product despite the fact that it is hard to switch off of your product.

I always remember seeing a tweet from Tom Blomfield, who's a friend of mine. He was like, "I don't really get this space. I was a Cursor user and I switched to Windsurf, and it was better or just as good." He switched to Windsurf for this one project. I have no idea if he stayed. I'm not making a comment. Tom, don't kill me.

My question to you was: how do you think about switching costs and retention? Is it that easy to switch between the two?

We need to innovate on features and products fast enough that we're able to build differentiated experiences for folks. That actually takes a lot of work. As I was saying, most of the products that we end up building don't end up working.

Even though we're shipping releases every couple of weeks, some of the more complex pieces of technology that we've shipped take months to actually ship. I'll give you an example: a couple of weeks ago, we shipped a model that was comparable to some of the frontier models on agentic workloads. Our model suite 1 is much faster, much cheaper for us to run, and capable of operating over a large codebase as well.

We were able to do that by learning from our users about how they use the product internally. That was not a single-month experience for us; it took us many months to actually build out that model internally.

These are the kinds of things that take time to build out. Now, it processes hundreds of billions of tokens of code a day. That single model is running on our own GPUs.

For everyone in the audience, folks like Tom probably never heard of our company or used our product 10 months ago. These things change extremely quickly, but you're totally right: the fact that it can change this quickly means that you need to be ultra-vigilant.

The same reason why no one had heard of us in Silicon Valley 10 or 12 months ago, and now a lot of folks have heard of us, means the same thing can happen in the other way too.

You mentioned the strength of enterprise in your business. How much of your revenue or usage today is enterprise versus bottoms-up?

I would say that, of our total amount, over 50% is actually enterprise.

What are the biggest questions and lessons—what are the things that enterprises care about when they buy you?

I think there are maybe a handful of things. The first thing is that a lot of enterprises and large companies—this is something that's not very obvious to folks outside looking in—have a lot of Java developers. Most large companies have a lot of code in Java.

They use an IDE called likely IntelliJ as part of the JetBrains family. This is an interesting fact: even though we have the Windsurf editor, we still support plugins into all the JetBrains IDEs, and they have the same functionality as the Windsurf editor.

The reason why we forked the VS Code editor was because we didn't have enough flexibility to build out the UI that we wanted to give users the new agentic experience. But we were able to provide that entirely in JetBrains through the plugins.

I'll give you an example. JPMorgan Chase, who is a customer of ours, has over 50% of its developers using JetBrains inside the company. For those people, we're able to support all of their developers. We're not a product that's only for their VS Code users; they can move over to Windsurf.

9. Who Actually Counts as an Engineer in 5 Years?

That's an interesting fact that I think people looking from the outside don't really understand. For the enterprise, there are lots of these IntelliJ users that we need to satisfy. When we go into an enterprise, we don't want to tell them, "Only 40% of your users can use our product." We want to make sure all of their developers can use our product.

Do you think your customers will have more or fewer engineers in 5 years' time?

It depends on the type of customer, and the word "engineer" is going to become a very flexible word. As the technology gets better and better, people who are technically adjacent are going to be using Windsurf as well. We're already seeing this at some of the companies.

What does "engineer" mean in 5 years' time? To explain it to an engineer, if you were to go back 50 years, everyone was writing assembly. After that, they were writing C. People still write assembly, though. After that, they wrote C++, then Java and Python, and now a lot of people are writing JavaScript.

I'm giving you an example of how the ease of programming has gone up, but a lot of the people who write JavaScript have no idea how to write assembly at this point. I think it's going to be something along those lines.

There will be people who are able to operate purely on a natural-language-based abstraction. The AI tools will be able to explain to them how different components of the software stack work, so even though they're operating on top of natural language, they're still able to be valuable to the company.

Ultimately, though, there will always be production-critical applications. Let's say I'm JPMorgan Chase and I'm building my transaction-processing system. You probably don't want to vibe-code that, Harry. If you give me $100, you probably don't want to lose that $100 and have me not give it to you. You're going to complain.

That's some transaction-processing system running in JPMorgan Chase that's probably doing millions or billions of transactions a day. For that, you probably want someone who can go all the way down into the weeds and validate that this actually makes sense, because that's core to the way the business operates.

I think you're going to have a spectrum of people: people who can operate purely on top of natural language and build capabilities, technology, and apps inside companies, but also people who can go down into the weeds. How many people need to go down into the weeds? Probably fewer than there are today.

10. Will Product Managers Even Exist in 2030?

I'm always told that PMs are the CEOs of the product, and many have said that we're not going to have PMs anymore. ElevenLabs—I had the head of growth on the show the other day—said, "We don't have PMs." Do PMs have a role in 5 years?

I think the expectation for PMs down the line is not going to be that they tell someone to go and build something. It's going to be that they should go out and build it too. There will need to be a lot more agency on their side, but the benefit is that these AI tools are going to give them that capability.

Let's say you do have a technical PM who understands code and can write code. They're even more deadly now than they were in the past. You don't need to give them a team of 10 people to prove out their idea.

One of the things that I don't like about PMs nowadays, in a lot of cases, is that they spend so much time writing documents to try to convince the organization to do what needs to be done. Instead, they should just go and build a version of what they want to get done and then prove to the organization that that's what needs to get done.

Why do you need to spend so much time babying your organization and playing a game of thrones? It doesn't really make a ton of sense in the future.

Do we skip the design stage and go straight to prototyping in the future?

Probably the ability to very quickly mock up a design that's consistent with the design inside your company and prototype it is going to be much faster. Internally, right now, when we build apps, we're not very quickly going to likely Figma at the very beginning if the app can be built very fast inside.

And then, obviously, if it's core to our product experience, we're going to go out and design the layout and make sure it's to our standards. But rapid prototyping means we can definitely skip a laborious design stage right now.

I'm just fascinated by where all of it converges together. As we said, you meet Lovable and Bolt in the middle, and then Figma is coming in now and actually saying, "Hey, turn design into code," and kind of coming in from outside. I'm trying to figure out what this kind of mess looks like in 5 years' time, respectfully.

Yeah, I think it's a fair question. Maybe one thing is, for people outside looking in, the things that Lovable and likely Figma do are maybe a very small fraction of what software is. Ultimately, most software is not just a website that has some backend attached to it. There are complex database systems, software out there, and all of this infrastructure.

Most of Google is not the front end of Google, right? Think about how much work goes into Google. Google is probably one of the most complex pieces of technology. There's a very complex reranker. There's this database called Spanner. That's a geographically consistent database that probably has tens of millions of lines of code, right?

And with all of those things, there's no one inside the company designing something in likely Figma for modifying the Spanner codebase, right? But we would like it so that they're using Windsurf to actually go out and do that. The way we like to look at it is that we don't sit and think about what these other companies are doing all the time. We're thinking about all the ways in which software engineers spend their time and how we make them much more efficient.

You're totally right that I think the design stage for a lot of things is going to get disrupted inside. But maybe one point I just wanted to add is that that's perhaps just the tip of the iceberg on what a software developer ultimately does.

11. Async Agents Are Coming But Most Will Fail & Why?

I was going through some of your tweets as well, and you said asynchronous remote agents will happen. I wanted to double-click on that first. Can you expand on how you think about this and which tasks will be automated first?

The idea of asynchronous remote agents is that, if you were to look at a product like Windsurf, Windsurf is actually a local agent that runs locally, and it can do very long-running tasks. You can migrate an entire codebase from one version to the next, and it should be able to do that without you having to touch your keyboard once you instruct it to, which is very powerful. This idea of being able to do it asynchronously is also very powerful. You can imagine just firing something off from your phone and it generating a pull request for you.

But I think one of the complexities of building products in our category is that there are 3 things that are really important. There's latency, so how long it takes to get the response back; there's quality, which is the correctness; and then there's correctability, or how quickly you can make a change.

I think people feel that if the technology is really good, they can ignore these factors, but they're really important. If you build an asynchronous experience and it takes 10, 20, 30 minutes, maybe a couple of hours, to go out and build something, people's expectations for the output are going to be really high. Your quality has to be really high, and if the quality is not high, it better be easy to correct.

But it's not very easy to correct. When the workflow of how people build software is that all I do at the very end is create a pull request on GitHub, which is the final way that people review the code, and even 20% of it is wrong, let alone 10%, I would say it has to be at least 90% correct. People were like, "It needs to be 99% correct," and I think they might be right, because if even 10% is wrong, people lose faith in the product.

They waited hours to get the result, right? They need to bring it back in locally, and modifying something that is 90% correct is not that easy, because you need to understand the 10% that is wrong also, which takes time. You're still human and time-limited at that point.

My rough feeling is that what is going to be done asynchronously and remotely are things where the task is so easy that it can actually get done properly. Complex tasks are still going to get done in Windsurf in the short term, just because, for things that are complex and require a lot of rapid iteration, it's unlikely that you're going to do something asynchronously, wait 30 minutes, go and look at it in GitHub, and then decide, "Hey, it's not correct," and bring it back in. The feedback loop is too slow at that point.

To what extent do users care about latency, have you found?

Very, very much. I'll give you an example. Even for a Tab product—which gives you not only autocomplete but also automatic refactors as the user is typing—every 10 milliseconds affects a percentage point in the acceptance rate for the product right now.

When we think about these asynchronous remote agents that have to be incredibly responsive and correctable, what form factor do they take? We mentioned that earlier, like just pinging off a message. How do you envision the right form factor, and what will that take?

Yeah, I think it's not super clear. It's possible that the right form factor is that you need to fire this off from your IDE, because people are in their work state in their IDE. The question is, how common is the use case where people want to fire things off from their mobile phone? If they do, is it fine for it to just be on Slack? Do people want to continuously talk to something on their mobile phone?

I think the answer is maybe not, because if I get thousands of lines of code changes, I don't know how to review code very effectively on my phone. In which case, I don't want to interact with something on my phone back and forth.

Maybe I'm game to do one-and-done interactions on my phone, and then it better be 100% correct. I'll go back to my laptop and say, "Now, it's correct," and then stamp it, approve it, and merge the code. There are a lot of trade-offs here.

12. The Truth About Agent-Only Workflows

When we talk about the right form factor for these remote asynchronous agents, it makes me think about something that was likely said by Satya Nadella. I wrote it down because I wanted to make sure I got it right; I didn't want to misquote him. He essentially said that apps will collapse into agents and become just databases with business logic. Do you agree with him in that respect? Salesforce becomes a database that agents just crawl all over, HubSpot does the same, and you basically have their utility value reduced to just databases?

Yeah, I'm trying to think about why I think that is not exactly true, but you're totally right that, for any company, its entire state could be distilled down to a database. For any company. I don't know if I completely buy that, in the short term, these complex applications like Salesforce and Workday completely get replaced by another company that just builds a database and an agent operating on top of it.

I think a lot of complex workflow has been built around the idea of using Salesforce. I'll give you an example: when we built our sales team, everyone already knows how to use Salesforce down the line, and now we've built custom workflows inside Salesforce. You're right, those are all database transitions, but they affect the way humans operate with software.

It's very unlikely to me that what's going to happen is Salesforce will get dethroned by a company that is just a database with an agent operating on top of it. There's too much inertia for the company building out these complex workflows.

Maybe here's the final piece, and maybe why I believe that: I don't think agents are good enough today that you can just let them operate on top of a database and automatically write to the database without human supervision for some arbitrary workflow.

Right now, we're still at the stage where these agents are mostly reading from data sources. They're not modifying things at scale. That's just because maybe we don't have the trust—we don't trust these systems deeply enough right now.

Do you think we are overly optimistic about the progression of the agent landscape? Obviously, as a venture investor, the only thing we give a [__] about today is agents. Do you think we are overly optimistic about where we are?

This is going to be the most obvious statement, but I think people think these systems are way more capable than they are. A lot of investors might believe they're more capable than they are today.

I'll give you an example. My goal here is not to downplay anything, but I remember last March, when the Devin launch came out. Everyone was giddy with excitement at the idea that software engineering was getting replaced. A bunch of investors were like, "Oh, there's no reason to ever hire a junior developer. You will have this."

And now we're very far from that, right? At the time, we were very far from actually replacing a junior developer with an asynchronous AI agent, right? But I think what people don't understand is that, even if the technology is not there yet, they don't grasp how quickly the exponentials are improving.

In 6 months, what these models are capable of is going to be very different from what they're capable of today.

13. The One Area of Engineering That AI Will Eat Next

I think it's very hard for people to understand that. What I just said about agents and the fact that they're really good at reading systems at scale, but people don't trust them to make writes to systems—to internal databases—at scale, will probably change in 6 months. Eight or 9 months ago, people were not using agents a ton, so I think people underestimate the speed at which these things improve.

What do you think, in 12 months, will be crazy that we don't have today? Like you said there about the transition and models bluntly improving so fast in such short time frames: if you think about what we do today that we would consider crazy, but that will be a reality in 12 months, what do you think it would be?

I think, because I understand the software development landscape a lot better, the way these tools are going to end up is going to be, I think, shocking to people. Right now, if I was to say one of the biggest problems with these tools, it's that they mostly help in the code-writing experience. They're not helping in a lot of different aspects of the software development life cycle.

Software developers design software, right? They deploy software, review software, build, navigate—they do a lot of debugging and testing. They do a lot of different things, and I think the reason why it's mostly been siloed to 1 or 2 areas is that when you look at a software engineer and their job at a company, they look at a lot of distinct data sources. They look at a logging system, they might look at a database, and they might do all these other things.

I think these agents are going to have access to all of this data—all of this data, your browser data, all this stuff. What's going to be possible is debugging very complex tasks. Designing systems is going to be something that these agents are going to give much more leverage for than they do today.

I think this idea that there's a part of software engineering that AI is not going to touch because it's too hard is just going to be wrong. I think every aspect is going to become 10 times more effective.

Can I ask you a really hard one? You mentioned Devin there. If you look at, say, Cursor, what have they done well that you've learned from, and what do you think they've maybe made a mistake on that you've learned from?

I don't know about a mistake, but I think they took a really good approach to building a high-quality UI/UX. That actually proved to be what people really loved, right? I think that's very impressive—that they were able to do this right off the bat. I think that's not actually what our initial intuition was, and I think we executed it wrong.

What do you mean by that? It wasn't where you placed importance in terms of that initial UI/UX being seamless?

Yeah. For us to go out and build Windsurf, we actually felt that we needed a massive technical breakthrough—actually, a new product experience. I think that was the only reason why we decided to go out and build, and actually have, our own IDE.

If we didn't do that, I think we'd be the type of company that would not just go out and build UI/UX just for a much better experience by default, unless we had great technology. I like to think of ourselves as a technology company, and I think we ship product to maximize the amount of technology that our users can consume productively, right? We want UI/UX that is not harming people's experience of our product.

To what extent is the quality of your customer experience defined by the software that you create—the UI, the UX—versus the model progression that lies beneath it, being OpenAI, Anthropic, and so on?

You can't downplay the fact that the latter is very helpful, right? The frontier models are getting more and more capable. Every new capability unlocks maybe a new type of product experience that wasn't possible in the past.

But I think it's a little bit of both. Maybe, to put it bluntly, we were the first agentic IDE experience when we launched Windsurf. We were the very first ones. Obviously, now that idea is not very non-consensus like it was; it was the obvious thing to do. But these models, like Sonnet, had existed for quite a while. It actually took us some work to put together an experience using these models, but also using our own models internally, to make this a usable experience with the UI/UX to be able to review all the software very quickly before people actually used it. The product experience kind of took off.

I think it's maybe a little bit of both, but I don't want to underplay how much the models actually affect the value people get from these experiences.

People often compare the model landscape to the cloud landscape. The thing that I find challenging about that is that with cloud, you generally stick to one provider. You're on AWS; you're not switching between AWS and Google and anyone else.

To what extent do you think the model landscape will be one where you have a preferential relationship with an AWS of the world in cloud—or Anthropic or OpenAI in models—versus actually just working between many different model providers and switching between them for different functions?

I think you're right. The space is very early. The reason why the switching cost of this category is not very high is that moving from one model provider to the next has very low switching costs, ultimately. By the way, that's because there's no state in these models, for the most part.

For the most part, it's almost like a Twilio-like experience, where it's like, “Send a text message.” You send a text message, but maybe you could send text messages with a lot of different applications. I don't take that as a big negative.

14. Are LLM APIs Already Commoditized?

I think what that means is that we're still evolving in this category. Down the line, you could imagine models can actually internally keep a lot of state about a user, about all the data they have inside their company, about all the data they use locally. If you were to look at a lot of large code bases, they're actually getting to billions of tokens of code. What if that's actually something stateful that you can inject and eject context about from a particular model provider?

I'm sure there are ways in which they can increase their switching costs down the line as the technology gets better and better. But I think this is what it comes down to, right, Harry: in a category that is evolving so quickly, and when the models are improving so quickly, it's actually bad for them to overinvest in ways in which they can increase switching costs. That just doesn't make sense.

Let's suppose they did do that, but they missed the next improvement in the model. They didn't do test-time compute or something. They would be behind, and then it wouldn't matter that they increased their switching costs. I think, ultimately, the analogy to cloud providers is not accurate right now. They don't have the same properties. It's not the same kind of business right now. But could it be down the line? I think it could.

Today, models do have non-commoditized properties. Anthropic is often hailed as being better for developers, for example, just as a basic example.

To what extent do we actually see the complete commoditization? There are literally 12 or 13 different providers in China who are racing faster than ever, and we'll reach some asymptotic utility point where all of them hit the same level. I'm sure the US will be the same.

To what extent do we hit that versus, “No, no, Anthropic is the one for developers, xAI is the one for whatever else”?

I think it's unlikely that, in the short term, you will have an ability for one model provider to just run away with a particular category, if the category is very valuable. I think it's unlikely that that's the case.

I do believe in things like the scaling hypothesis, which is to say, with more scale, you're able to build better and better models. You do have your hands tied if you're operating with less capital in the category. That's just the nature of the game right now.

But I don't think we're anywhere near the point at which you're going to have someone who's the defining leader in having a great model, and no one else can touch it for years. Maybe the reason for that is actually because, 6 months from now, if a new technique exists and someone else finds the new technique, ultimately they're able to do it in a much more efficient way.

If they're able to do it in a much more efficient way, it means that if you just miss it and you're still applying your previous technique, you're going to be behind them, right? Unless you believe that 1 company is going to get all the capital in the world, no one else is ever going to get the capital in the world, and 1 company has a monopoly on all great ideas, it's unlikely that you're going to have someone able to run away with something in the short term, if that makes sense.

Given the commoditization of that model layer, as we said, and no one being able to run away, to what extent do the model providers have to move into the app layer to have any form of differentiation?

Maybe on the API side, I think there are lots of ways you can build better APIs for a lot of different applications. Maybe you can focus on the applications you do support.

An example of this is, let's say you were working with a company like us and we were using a model provider. When we output code, maybe a lot of the code looks the same as existing code, and you can actually optimize from a latency perspective to help our workload versus another workload that exists for images out there. You can be a much better vendor to us than another company.

15. Should Model Companies Own the App Layer?

There is maybe specialization you can have on different axes to provide a better experience, but as you can see, you are seeing these model companies actually going up to the app layer, too, in whatever apps they see as valuable to them. I think you're seeing a little bit of both. People have too many opinions about what the right way to do things is, and I think you have to be rational about what the best way to win is. I think that's the only thing that matters.

The final thing I do have to touch on, because I've talked to you for a long, long time: Dario was talking at some event or conference the other day, and he was like, “In 2026, we'll have solo billion-dollar companies without doubt.” I wanted to touch on this with you. Do you agree?

No, I don't believe in that.

Please explain. This feels like a university essay: discuss.

The solo billion-dollar company would imply that no one else cares. We live in a capitalist market, so there's competition. If you're able to do something with one person, unless you're a thousand times smarter and more capable than everyone else, someone with 2 people who are as smart as you are is probably going to be able to do your idea.

If they do, that's going to compress your margins. That's going to compress your ability to be the pervasive brand out there. That's going to increase your customer acquisition cost. I don't know; it seems very hard for it to be the case that a single person is going to be able to run away with a billion-dollar product without continued investment.

The implication of that is that no one else cares about this, but magically you're able to do well. I don't know what people who believe this to be true get wrong. What are they fundamentally mistaking?

I've never understood this idea that a single person is going to be able to build a billion-dollar company. What is a company? A company is the sum of the discounted cash flows over time.

Down the line, you're going to need people, probably. If the AI is so good that you don't need people, at some point I would just wonder: What are you really contributing? Is the AI building the whole thing? In which case, that would increase competitive pressure, because everyone else will have access to the AI, too.

Can I ask you, you've been across multiple different cycles of the business, ups and downs: When did you question your love for it most? We often say, “I'm always inspired.” I'm not inspired every day to do what I do. Some days I am, some days I'm not. Was there a period where you were not, and how did you get through that period?

Basically, every time we've needed to make a strategic pivot. Before the pivot, that's probably the most anxiety-inducing, because you feel like something could be much better than it is, but you're not acting on it. I think that is potentially the part that is the most gut-wrenching.

When we pivoted from Exafunction to Kodium, I actually think post-pivot was the freest I've ever felt, because both my co-founder and I had written off in our heads that we were likely going to fail, but at least we were likely to fail at something that we believed in.

In the past, we were making a couple million in revenue, but I know what it means to be a very large, successful company. You need to be able to make billions in revenue, right? We were so far away from that outcome that it was almost like, “This feels very hard to do.”

After pivoting, we had a new lease on life. For us, and for me, the part that is the most anxiety-inducing is when we believe we could be doing much better, but there's random inertia or friction preventing us from doing the right thing. Even if doing the right thing has a low probability of success, actually starting to work on it is the freest experience that I feel like I've had at the company.

I heard you say once an interesting statement: You wait until you're drowning in a role before you hire for it. I thought it was really interesting, because I was always brought up on the value of board members being that they highlight hires you need to make 6 months ahead, so you don't have a bottleneck in 6 months' time. How do you think about those 2 seemingly opposing ideas?

We've had cases where I would say it's a little bit of an anti-pattern. For instance, before we hired our VP of Sales, who was really awesome, we actually closed some very large enterprise deals inside the company without any salespeople. That showed us what very large enterprise sales looked like inside the company, and it also proved to the person we were going to hire, Graham, that we were an awesome company to potentially work at.

I think it's an interesting trade-off. Maybe there's a belief that domain experts are awesome, but if inside the company you're not able to get an outcome that's even 1% or 10% as good, it's probably not the right time to go out and make the hire.

Let me put it this way. This is maybe the concise way to answer this: Startups don't fail because they look like messes inside. Startups fail because they don't do the right thing well enough. That is the reason why they fail.

People love to say, “I don't have this role, and that's why I'm not working.” Actually, when you look at the most successful companies, they look like train wrecks inside, right?

16. What Does Varun Want to be Remembered For?

Ultimately, as long as you are doing the basic things that make your product very successful, I think you can make these hires as necessary. I don't think it's critical that you make them 6 months in advance. The worst thing for me would be making a hire and for them not to be important on day 1, just to be told, “Chill out over here and wait for the next 3, 6, or 12 months,” because then they're going to manufacture something to work on, and I won't really care about what they're doing.

The final one before a quick-fire: What did you believe about management that you've changed your mind on? As an example, I brought in this incredible person, Julian. He led Workplace in Europe for 10 years, and I always believed, arrogantly, as a young person, that I could read Elad Gil's High Growth Handbook and know how to manage people. The wisdom and experience this guy brought from 15 or 20 years of leading teams is so nuanced and granular. I learned so much from him about management every day. You can't learn it in a book. I've changed my mind on that. What would your change of mind be on management?

The biggest change of mind I had was what you originally said: How large your team is is not a function of output. Output and ruthless focus are the only things that matter.

You can have a lot of people, but if those people are not ruthlessly focused on one thing, you are going to be very, very unsuccessful. It is much easier to run a company that is focused, where there's only one thing that matters, than it is to run a company with the same amount of revenue and 5 different priorities.

In retrospect, that always feels obvious. But at a startup like ours, where there are so many things we can do, there are always a couple of shiny things. You can always open Twitter and see that X is solved, Y is solved, and Z is solved.

17. Quick-Fire Round

Actually, being able to say no to things and focus on the one thing that matters, with many people ruthlessly optimizing for that, is very hard. But when you can get that right, you can make magic happen.

I could talk to you all day. I do want to do a quick-fire, and I have some great quick-fire questions for you. I'm going to start with one that I'm adding to these ones. Neil Mehta: I love him as an investor, and I'm an investor, so I don't see the same Neil Mehta that you see. What makes him so special for you as a founder?

His ability to analyze companies and be very intellectually flexible is actually pretty remarkable. The breadth of knowledge that he has about all these different businesses, but also his ability to understand what makes them work, some of the ways they could improve, and how that could be applicable to us, is very awesome.

He's also very generous with his time. You would assume, given the fact that he works with so many companies, that he would not have a lot of time, but he is extremely generous with his time.

Who do you not have on your board that you would most like to have on your board?

I would love to have someone like Scott Cook on our board—someone who's the CEO and founder of an extremely successful software company.

I've had a handful of conversations with him, and every time I walk away with a deep understanding of competitive dynamics and what it takes to run a very enduring, long-term, successful business.

That is a great shout. I haven't had that one before. If you had to make Windsurf open source tomorrow, how would you feel, and what would you do instead to win?

I feel like that's a question I've been getting recently. I don't think it would affect much if we had to make it open source, because most of the work is in the back end. It's like the thing I said before: Google has a front end, but the front end is just a single box. If they open-sourced the front end of Google, I don't think anything would really change about the world. That box—the UX for that—was not really the big deal.

I am aware of the fact that Copilot has done that, but most of our logic is actually in the back end, ultimately, so I don't think it would change a ton. I also don't think it would change our adoption of the product. Most of the differentiation has nothing to do with whether the front end is open source or not.

You have a sibling. They’re 18 years old, and they ask you, “Should I go to university? What should I study, and how should I position myself best for this new world of work?” What do you advise them?

Just focus on problem-solving, right? How do you break down problems? Be a high-agency individual. I think computer science, largely speaking, is just the study of problem-solving for the most part.

What doesn’t matter as much is whether you learned X language or Y language. Can you break apart a problem into its distinct pieces and actually go out and execute on them? That’s probably the most important thing.

What’s one thing that you think OpenAI did wrong that you’ve learned from?

Maybe naming. Let’s go with naming on that one.

Penultimate one: you can change one aspect of your CEO-ship. What do you need to change most?

I think there are probably some details I shouldn’t actually be looking at very deeply that fundamentally don’t matter for the long-term success of the company. I’m just a person who’s very neurotic, and I like to understand everything that’s happening internally, like what we’re spending money on, at a level that probably doesn’t matter.

I just waste cycles in my head that could be put to better use.

Final one for you. You can be known for having one impact on humanity. What impact do you want future generations to say, “Varun, my grandfather, he did X”?

I think the mission of our company is very exciting. I wouldn’t say it’s just me, but the team—we want to reduce the time it takes to build technology by 99%.

If we’re able to play a meaningful role in how that could shake out in the future, I would be extremely excited about that.

Brilliant. Listen, as I said, I heard so many things from Lee Fixel, from Neil. I was so looking forward to this. You’ve been fantastic. Thank you so much for putting up with my base level of knowledge, and I so appreciate it, man.

No, this was fantastic, man. Thanks a lot.