Context: Windsurf focuses on building code agent systems for software engineers and gained widespread attention after being acquired in one of the largest M&A deals in the AI sector to date. This interview, hosted by “20VC” founder Harry Stebbings, was published in June 2025 and covers core topics including AI product development, startup strategic transformation, and the convergence trend of Agents and IDEs.
Harry: Varun, I’ve been really looking forward to this conversation. I’ve heard so many great things about you from Lee Marie, Neil Mehta, and others. Thank you so much for being here today.
Varun: Thank you for having me, Harry.
“Choosing Right Is More Important Than Working Hard”
Harry: You once said that truly great ideas almost never appear fully formed. I’d like to start there: how did you come to rethink what a genuinely excellent idea really is?
Varun: Peter Thiel’s theory has merit—for example, the idea that you should start in a direction that’s not obvious. But the issue is: most “non‑obvious” ideas are bad ideas. Taking a non‑traditional route doesn’t necessarily mean your idea is good, and that’s often overlooked.
From a higher standpoint, if you choose something that everyone considers obvious, then almost certainly there’s no “alpha” advantage. Big companies will enter first because they have more channels, resources, and capital.
So startups typically must win by choosing directions that seem unusual to the masses. At the same time, you must be self-aware enough to recognize that your “special” idea might not actually be good.
From Failure to Breakthrough: Strategic Transformation and Rapid Growth
Harry: When you pivoted to Windsurf, what did you find was the most “non‑typical” insight or realization?
Varun: Actually before that, we had already pivoted our first‑version product once, and even changed the company name twice. Initially, we were called Exafunction, working on GPU virtualization technology. Our logic was that future compute workloads would increasingly depend on GPUs. That was our initial mission. Many on the team previously worked in autonomous driving, AR/VR, and the team was quite small.
It turned out we were right in one sense—GPUs would indeed become more important, and NVIDIA would sell lots of GPUs. But we underestimated the concentration of GPU workloads. We assumed many different model architectures would emerge in the market. In reality, almost all converged on the transformer architecture. In that landscape, as an infrastructure provider, there was little differentiation to gain. So we had to pivot. But that’s the reality of the market—some things are hard to know before you enter. When your initial assumptions are wrong, you must abandon them. Sometimes you have a “special” viewpoint, but the market completely unfolds differently.
Harry: I completely agree. But the problem is many people get too attached to their “thesis.” That’s also why I dislike “thesis‑driven” investors. Many founders are deeply infatuated with their ideas, and they’ve always heard: “Only the persevering founder wins.” But you emphasized “don’t be too in love with your own idea.” What do you make of that tension between stubborn persistence and rational detachment?
Varun: That’s indeed one of the hardest parts about founding a startup. You must simultaneously hold two seemingly contradictory beliefs: one is irrational optimism—if you don’t believe, you won’t get out of bed; the other is ruthless realism. Every day you have to ask yourself: “Why do we exist?” If the answer is uncertain, you must pivot immediately and bring the whole company with you. In startups, it’s absurd that you get no praise for persisting at doing the wrong thing. You might tell colleagues, investors, or friends: “I’m still doing this.” But when you fail, no one cares how long you persisted.
Harry: Which current idea are you “too in love with” right now? I can share an example: as an investor, I’m obsessed with “portfolio discipline.” I like managing risk and opportunity through precise portfolio construction. But the reality today is that you must break many rules. I’m not advocating blind risk, but you have to be far more flexible than traditional models. That’s what I can’t let go. How about you?
Varun: From an empirical standpoint, we’ve always been too attached to our ideas. From the outside, someone might think: “Pivoting one after another is a positive sign.” But I’ve been reflecting: why couldn’t we pivot earlier?
For example, from GPU virtualization to code AI products—I still blame myself for delaying three months even though the signals were there. At that time, many of our partner companies were in autonomous driving, during the “ZIRP” (zero interest rate policy) peak. But by mid‑2022, many of them couldn’t continue financing, and we realized the market and technology were shifting, and our potential customers might not survive. Looking back, I wish we had acted three months sooner.
With Windsurf, it’s similar. We knew Agents were going to be powerful—we could’ve started earlier.
Harry: I recently interviewed the Fiverr CEO. He said one huge change in recent years is that “time to clone” has shrunk massively—you innovate, and someone else can replicate it almost instantly. In that scenario, how important is being the “first mover”?
Varun: Moving first brings two benefits. First, it reflects how your company operates; second, you learn faster from the market.
Let me explain the first: companies that enter a new paradigm first are typically willing to self‑disrupt. Their organizational structure is open to change, they can pivot quickly. They invest in non‑incremental innovations and break their own structures. This trait is critical in fast‑changing fields like software or code AI.
Second: being first means you enter the market sooner, you learn sooner, which increases your chance to lead the next iteration. You’ll see “where the corpses lie” first—you learn which directions die fastest, which pits you fell into, which are worth persisting with.
I often ask: if we launch earlier, what can we learn from users in the first month? Can that knowledge help build our next version faster? I believe this “learning advantage” compounds over time.
Harry: But from another angle, watching others fail first isn’t that bad? You observe where they go wrong, then avoid those mistakes yourself, saving major trial‑and‑error cost.
Varun: The issue in software is: many mistakes happen internally during development, which outsiders can’t see. A company builds an internal “category intuition”: some ideas you won’t even touch because you tried them yourself and they failed. That “memory of failure” gets encoded into your organization. Our innovation now often builds on these prior failures. It’s hard for outsiders to see that.
Harry: What did you try that failed, which outsiders didn’t know about?
Varun: We did release a beta version of the product, and dog‑fooded it internally for a long time. Let me give two examples.
First was a code‑review beta. We tried many delivery methods—Chrome extension, a parallel web app—internally nothing felt ideal. Only a few weeks ago did we release the current code‑review product, which is much more polished and valuable. We arrived at this approach by learning from last year’s failed attempts.
The second example is the code Agent product released with Windsurf. We built a first version early last year, but it didn’t work well—for many reasons. That failure sent us back to the drawing board to rebuild—fixing critical components, perfecting code‑based understanding, and waiting until the underlying model improved. Once model performance improved and code‑based understanding matured, we were ready for release. That’s what happens when you wait for others: you end up catching up on multiple dimensions to push out the product.
Harry: Windsurf has grown very fast—some even call it the fastest-growing AI code product ever. From a growth engine perspective, what worked best for you?
Varun: Word of mouth. That’s it.
We did nothing special—no marketing, no sales team. We just had a Discord server and an X (formerly Twitter) account. All we did was let engineers use the product freely. They liked it, and told other engineers. And they told others. It was completely organic.
In the end, your product has to be the reason people want to talk about it. Engineers are incredibly smart users—they only share something if it’s truly valuable. If they try your product and it’s not amazing, they’ll leave immediately. That’s the brutal truth.
Harry: Do you worry about being copied?
Varun: Not really. I think most people underestimate how difficult these products are to build. Even with open-source models available, just calling an API isn’t enough.
Many assume they can replicate what we do by building a frontend over GPT-4. But that’s not how our system works. There’s deep infrastructure and proprietary understanding behind it. We spent years developing ways to interpret large codebases, trace dependencies, and build agent systems that operate safely and effectively.
Also, the market moves fast. By the time someone replicates what we’ve done today, we’ve already shipped the next iteration. So the real challenge for others isn’t copying today’s product—it’s matching our rate of learning and iteration.
Harry: What do you think is the most misunderstood idea in AI product design?
Varun: That “adding more features” makes a product better.
The opposite is often true. Especially in agent systems, every new feature increases complexity exponentially. If the system needs to write, execute, test, and fix code across dozens of environments, adding one more action can make failure rates spike.
The hardest thing in AI products is to keep them narrow and sharp. Define a single job, get really good at it, and only then expand. Otherwise, you end up with a mediocre agent that tries to do everything and fails at all of it.
Harry: There’s a quote I like: “Product-market fit doesn’t feel like a celebration—it feels like a stampede.” What was the exact moment you felt you hit product-market fit?
Varun: When users started saying “I can’t work without this anymore.”
You see it in usage patterns. Before, users tried it out of curiosity. Later, they integrated it into their daily workflow. Then they began asking for deeper integrations: “Can you hook into our CI/CD pipeline?” or “Can you support our internal monorepo?”
That’s when we knew: this wasn’t just a cool demo. It was becoming infrastructure.
Harry: Many companies in the devtools space suffer from “shelfware” problems—tools that get tried once and never used again. How did you avoid that?
Varun: We made sure the product provided value within seconds. You don’t need onboarding or training. You install it, it works, and it solves a real pain point fast.
Also, we dogfooded it relentlessly. Our own team used it to write code, file PRs, do reviews. We forced ourselves to be the most demanding users possible. If it didn’t help us, we knew it wouldn’t help others.
Harry: Last question. If you were starting over, what’s the one thing you’d do differently?
Varun: I’d move faster.
Every time we hesitated—whether in pivoting, launching, or iterating—it cost us time. We often knew what needed to be done, but we waited for more data or perfect conditions.
Now I believe: If you’re 80% sure, go. Let the market correct you. Momentum is everything in a startup.
Comments
Post a Comment