Windsurf's Bet: Build the IDE That Makes Today's IDE Look Dumb

Varun Mohan explains that the company began nearly four years ago, before AI coding and ChatGPT were mainstream, as a GPU virtualization and compiler software company. He had worked in autonomous vehicles, and his co-founder, a friend since middle school, had worked on AR/VR at Meta. They believed deep learning would touch many industries beyond autonomous vehicles, so they built software that let complex deep learning applications run on computers without GPUs while managing the GPU workloads behind the scenes. By mid-2022, the company had a couple million dollars in revenue, managed upwards of 10,000 GPUs, had eight people, and was free-cash-flow positive.

Once generative models became very good, Varun felt that much of what the company had built was losing value. He reasoned that customers might stop training bespoke sentiment classifiers and simply ask GPT-N whether a piece of text was positive or negative. If everyone was going to run generative AI models, he argued, then infrastructure alone would not be a durable differentiator. The team decided generative AI could be like the next internet, so they should build the next great applications, and they took their inference infrastructure to build Codeium.

Codeium started as a simple autocomplete model that completed the next one to four lines of code, offered for free across VS Code, JetBrains, Eclipse, Visual Studio, Vim, and Emacs. Varun says the team could offer it for free because of its infrastructure background and ability to optimize the workloads heavily. Large businesses such as Dell and JPMorgan Chase then wanted secure offerings personalized to their private codebases, which pushed Codeium into an enterprise motion and deep codebase understanding. Six months before the interview, the team concluded that existing IDEs capped the AI capabilities it could show users, so it forked VS Code and built Windsurf.

Varun describes the startup tension as needing irrational optimism that your work matters while also being uncompromisingly realistic, because most unconventional ideas are bad and obvious ideas would already be taken. The original infrastructure thesis assumed model architectures would stay heterogeneous, but by mid-2023 transformers dominated and much of the value looked likely to accrue at the application layer. Even though Codeium was already making money and had raised $28 million, the team pivoted overnight for focus, because working on something they did not believe in would guarantee failure at the bigger bet. The culture he wants is truth-seeking and not in love with ideas, so wrong bets do not permanently lower morale or destroy optionality.

Varun defines Windsurf as an IDE, an application for building software, though he notes that many users may not even know what an IDE is. The team believed that as AI became more powerful, the interface for building software would change from a conventional text editor where the user writes most code and gets basic compiler feedback. If AI writes well over 90% of software, the developer's role shifts toward reviewing large chunks of generated code, which requires custom review flows inside the IDE. The existing text editor model, he argues, would severely limit what Windsurf could build.

He gives a concrete example: Windsurf Tab shows inline refactors alongside the user's cursor. In VS Code, the team lacked the APIs needed to build that UI properly and had to dynamically generate images next to the cursor. After porting the same feature into Windsurf with a custom UI, acceptance rate tripled with the same ML models. Varun says this gave the team confidence that technology alone is not enough if users get little value from how the technology is surfaced.

Lenny notes that convincing engineers to switch to a brand-new IDE is a huge risk, and Varun agrees. He says Windsurf remains committed to platforms such as JetBrains because many Java and C++ developers rely on IntelliJ-family tools. The team simply felt that VS Code, one of the dominant IDEs, was limiting the user interface it could deliver. On traction, Varun says Windsurf launched a bit over four months before the interview, more than a million developers had tried it, and it had many hundreds of thousands of monthly active users.

Varun breaks engineering work into three buckets: figuring out what to solve, deciding how to solve it, and actually solving it. He believes AI will handle the vast majority, if not all, of the pure execution work. With deep understanding of an organization's environment and codebase, AI will also get closer to deciding how to solve problems according to best practices. Engineering then moves toward what people originally wanted engineers to do: identify the most important business problems, prioritize product capabilities, and make the right technical decisions.

Lenny asks whether this means a computer science degree no longer matters, and Varun pushes back on that idea. He says most full-stack developers rarely touch kernel schedulers, but operating systems principles help them understand why applications are slow and why some design decisions are better than others. He describes computer science as almost synonymous with problem solving under constraints such as memory speed, computation per cycle, and system trade-offs. AI may empower people who never learned those底层 details, but understanding them still makes a good engineer better.

Varun argues that agency is undervalued in how people are educated and hired. School often gives students well-defined problem sets with clear paths, while startups need people who will go build something without being told exactly what to do. He says Windsurf looks for high-agency people because if the company does not innovate and do crazy things, it will die. In contrast, he suggests that the average software engineering interview at a large company probably does not test for this trait.

Varun says he likes lean companies but does not idolize being a tiny company at all costs. The goal is to be the smallest company that can satisfy the ambition, not to stay small for its own sake. He uses an autonomous vehicle analogy: a ten-person team claiming to build an autonomous vehicle would not be serious. Windsurf's ambition is to reduce the time it takes to build apps and technology by 99%, which will require a sizable company even if it tries to operate like a startup.

The hiring rule is to hire only when a function is actually underwater. Varun argues that hiring when a team already has enough people creates weird politics, not because people are malicious but because new hires will manufacture work and convince the organization that it matters. He wants people raising their hands and saying they are dying for one more person. His metaphor is that the company should be a dehydrated entity, and every hire is a little bit of water; the team hires only when it is dehydrated again.

Varun says this constraint forces ruthless prioritization. He tells the company that school rewards a high total GPA, but a company needs an A+ on the one class that matters and can afford an F in the others by deprioritizing them. If leadership says two things are most important but staffs the company with 20% more people than necessary, the organization will find ways to spread work. He also says people's value should not be tied to team size, and the most valuable person is the one who can do a crazy project with as few people as possible.

Beyond the technical bar, Windsurf looks for people passionate about the mission and willing to work very hard. Varun does not try to sell the company as chill; he says the space is competitive and the team should expect to lose if people are not working hard. He treats 'I work smart' as a dog whistle when asked about work ethic, because the differentiator is smart people who also work hard. Interviews still bring people on site to see how they think through problems, and while candidates can use AI tools, relying only on ChatGPT to solve a hard problem is a concern.

Varun says Windsurf hired its VP of sales over a year before the interview, and the go-to-market team had grown to over 80 people. Early angels included go-to-market operators such as Carlos Delatorre, formerly CRO of MongoDB, so the team never viewed enterprise sales as a negative. Varun explains that technical founders sometimes believe everything should be product-led growth, but enterprise sales is valuable and more nuanced. At the earlier infrastructure company, he did not hire sales because he did not know how to scale the function himself; at Codeium, large enterprises reached out, the team ran tens of pilots concurrently, and the enterprise motion became obvious.

When Lenny asks how Windsurf differs from Cursor and how it wins long term, Varun starts with codebase understanding. Windsurf invested heavily in understanding very large codebases because it worked with companies such as Dell, whose codebase has over 100 million lines of code. Making large-scale changes in such environments requires models that can consume and rank large chunks of code across thousands of GPUs to find the most relevant snippets. Lenny points out that this is very different from building a new app from scratch, and Varun agrees that understanding an existing million-line codebase is a major differentiator.

Varun says Windsurf is not tied only to its own IDE. JetBrains and IntelliJ account for a large share of Java developers, and Windsurf wants to meet developers where they are rather than force everyone onto its editor. Many large enterprises have more than 10,000 developers, with over half on JetBrains, so supporting that platform matters commercially. Windsurf also invests in secure environments: it has FedRAMP compliance for government entities and a hybrid mode where indexed code lives on the customer's tenant. Code is critical intellectual property, so these enterprise requirements are part of the product strategy.

Varun demos Windsurf on a basic React project and passes it an image mock-up of an Airbnb for dogs. He asks Windsurf to change the React app to match the image and preview it, and the agent begins reading the repository and determining the necessary changes. Lenny notes that Windsurf had never seen this codebase before and is still able to act on a natural-language request plus a design image. The demo produces a working dog-themed app with a preview inside the editor.

Asked what advice he would whisper to new users, Varun says to be patient and explicit. Agents can make many irrelevant changes, so starting with smaller changes reduces blast radius; refactoring an entire directory can destroy many files if the agent gets it wrong. He compares learning the product to learning autocomplete: users accept suggestions only about 30% of the time, but it is not annoying because they learn when it helps and when a command is too complex. Those hills and valleys get re-evaluated every few months as the product materially improves.

Varun shows that users can point at elements in the preview and ask for changes such as making a background red, which lets someone live almost entirely in app space rather than reading code. He then demonstrates the AI review flow: the developer can edit a piece of code, and Windsurf knows both what the agent did and what the user did. When he renames a property from title to Title String, the agent notices the user's change and updates all corresponding locations in the app. This flow-like state is meant to support both non-developers building apps and developers doing hands-on refactors and migrations.

Lenny asks why Windsurf does not always generate the base app automatically, and Varun says the demo's base app was itself generated by Windsurf; installing dependencies just takes three or four minutes. He says many Windsurf users do zero-to-one app building, and when Windsurf launched, the company asked everyone, including go-to-market and sales, to build an app. That effort saved over half a million dollars in SaaS products the company would have bought, because the head of partnerships built a partner portal without prior software experience. Varun argues that domain specialists can now build the 10% of features they actually need instead of buying kitchen-sink vertical software.

Varun says Windsurf uses Sonnet as a strong planning model, with GPT-4o also good, but it does not send whole codebases to Anthropic. A 100-million-line codebase is roughly 1.5 billion tokens, orders of magnitude beyond current context windows and impractical on cost and latency. Windsurf instead runs its own models to chunk and understand the codebase, then performs high-quality retrieval for the agent. This lets the planning model operate on the relevant pieces rather than the entire repository.

For edits, Windsurf uses custom models post-trained on top of popular open-source models so it can apply changes quickly. Varun says these edit models can be faster and can hold more of the codebase in context than a frontier model, making them better at applying changes in some cases. The retrieval model was pretrained completely in-house, while edit and autocomplete models are also in-house. The guiding principle is to build or train models where Windsurf can be best and use open-source or Anthropic models where it cannot, rather than training for ego.

Varun says Windsurf receives tens of millions of pieces of feedback from users every hour, including preference data for autocomplete. That data is unusual because it reflects code as users type it, often incomplete, unlike the complete code found on GitHub or consumed by frontier models. Windsurf can therefore train autocomplete models on incomplete-code states that frontier models have seen very little of. Retrieval also gets signal from whether a user accepts a change, but Varun admits there is no coherent argument for Windsurf being best at pure code planning; the defensible ground is understanding gnarly intermediate codebases and the evolution of code across millions of users.

Varun says Windsurf does not have pure product managers for core engineering because the company builds for developers and its product is built by developers. The developers are expected to flex into product roles, and if their intuition is not valuable, the company may be hiring the wrong people. On the enterprise side, Windsurf does have product strategy people because engineers do not naturally wake up thinking about FedRAMP or other large-customer requirements; three people currently work in that product strategy function. Engineering teams are kept small and flat, with two-pizza teams and leaders who stay close enough to the technology to avoid armchair quarterbacking.

Lenny asks whether 90% of code being written by AI contradicts Windsurf hiring engineers aggressively, and Varun says it does not. Engineers do more than write code: they review, test, debug, design, deploy, and navigate code. He cites Amdahl's Law to explain that if only 30 units of a 100-unit process are coding and that 30 becomes three, the total process only improves to 73 units, a 27% improvement. Windsurf is seeing 30% to 40% productivity improvements, but its ambition still requires more engineers; for a company like JPMorgan Chase with a $17 billion software budget and over 50,000 engineers, higher productivity raises the ROI of building more technology, so it may hire more rather than less.

Varun says the public sees weekly product waves and short-term wins, but many internal bets are three to nine months out. He tells the company that Windsurf should cannibalize its existing product every six to 12 months, making the current product and even its form factor look silly. Incremental improvements and user-requested buttons feel safe, but they are table stakes, not the reason Windsurf will win. Lenny connects this to the idea of a secret roadmap not informed by users, and Varun agrees that the tension is to listen to users without being trapped by their requests.

Asked what he wishes he had known before starting Codeium, Varun says he wishes he had been more okay with being wrong faster. He and his co-founder often look back and wish they had made a decision a couple of months earlier, even when outsiders think the timing was right. The hard part is balancing irrational optimism with realism, because founders have to drink their own Kool-Aid to get out of bed while still re-evaluating hypotheses. His final advice is to get hands dirty with these tools as quickly as possible, because there will be enormous alpha for people who learn them; a product manager who can edit a codebase and push a PR can become a force multiplier for the organization.