Visual summary of operating lessons from Varun Mohan.

Lessons from Varun Mohan

Varun Mohan is the co-founder and CEO of Codeium and the Windsurf IDE. He previously built a profitable GPU infrastructure business called Exafunction, but pivoted his team to the application layer after realizing raw compute would inevitably become a commodity. This collection gathers his thinking on deep learning latency, hiring density, and the unglamorous mechanics of growth.

Part 1: The Codeium Pivot and Startup Agility

  1. On Pivoting vs. Failing: "Pivoting isn't failure. Sticking with the wrong thing is." — Source: [Lenny's Podcast]
  2. On the Value of Adaptability: "It’s more valuable to be adaptable than to be right. The first idea you’re going to have when you start a company is very unlikely to be the right idea." — Source: [Alejandro Cremades Podcast]
  3. On Recognizing Commodity: "If the type of software we were providing infrastructure for was largely looking all the same, we would become a commodity." — Source: [EducationNext]
  4. On Killing Ideas: "Most ideas are bad ideas, and you need to kill your ideas fairly quickly... this is like this tension that a company is always going through." — Source: [Lenny's Podcast]
  5. On the Freedom of Clear Failure: "I actually like failures a lot. One of the things I hate the most is doing something and not knowing if it's working or not... it's very freeing to know when something fails because that's very obvious." — Source: [Lenny's Podcast]
  6. On Intellectual Honesty: "Intellectual honesty is vital for startups. It's very hard as the company gets bigger for a large group of people to analyze what they're doing and to say, 'Hey, we should stop working on this.'" — Source: [Lenny's Podcast]
  7. On Speed of Execution: "Get your hands as dirty as possible, as quickly as possible. There is a tremendous amount of alpha for those who master these tools first." — Source: [EducationNext]
  8. On Focusing Resources: "The right thing for a startup to do is always focus on the product with a higher R value. It never makes sense to be diverting your resources to work on two different products." — Source: [Lenny's Podcast]
  9. On the Weekend Pivot: "We had a successful GPU infrastructure business, but when we saw the trajectory of LLMs over a weekend, we walked away to build an AI coding assistant." — Source: [EducationNext]

Part 2: The Fallacy of Product-Market Fit

  1. On the Myth of Permanent PMF: "Product-market fit is temporary. If you're not paranoid about becoming irrelevant, you already are." — Source: [Lenny's Podcast]
  2. On PMF Inducing Laziness: "Product-market fit is a dangerous myth. It makes founders lazy. The moment you think you have it, you stop listening." — Source: [Medium]
  3. On Continuous Re-evaluation: "You have to constantly earn your fit in the market; it is not a destination you arrive at and stay at without effort." — Source: [Medium]
  4. On Ignoring the Status Quo: "Success in startups isn't about being right from the start; it is about being honest and relentlessly focused on customer value." — Source: [EducationNext]
  5. On Building for Real Problems: "A lot of companies build tech looking for a problem. We look at the drudgery of engineering and build AI to solve it directly." — Source: [Software Engineering Daily]
  6. On Avoiding Iterative Traps: "In some ways, too much customer obsession might be bad in that if you do things that all of your customers ask you to do, sometimes you might incrementally iterate to actually build a really bad product." — Source: [Lenny's Podcast]
  7. On Listening to the Market: "Failure is not the enemy; it is the signal. It cuts through noise." — Source: [Medium]
  8. On Growth Masking Flaws: "Growth can mask a loss of product-market fit. You have to look at whether the fundamental utility is still there for the end user." — Source: [Lenny's Podcast]
  9. On Paranoia in Startups: "Companies should be operating as if almost existential dread; not in that it's causing paralysis, but in that it causes the agency to figure out what the next thing to do is." — Source: [Lenny's Podcast]

Part 3: Building Agentic IDEs

  1. On Why They Built Windsurf: "If we launch this agentic product on top of a system that we didn’t have a lot of control over, it’s just going to limit the value of the product... That’s why we were super excited to launch Windsurf." — Source: [Latent Space]
  2. On the Cascade Feature: "We are centering it around this idea of a Cascade flow which allows the model not only to autocomplete one line, but do multi-step editing of multiple files with the same flow as an engineer." — Source: [Latent Space]
  3. On Toy Apps vs. Deep Systems: "We had the technology to go out and build these zero-to-one apps very quickly. But the real value... is actually much, much deeper than that. It’s actually that you take a large codebase, and it’s actually a really good first pass." — Source: [Latent Space]
  4. On the Iterative Nature of Coding: "Code is not really built as you have a PRD and then you get some output out. It’s more like you have a general vision." — Source: [Latent Space]
  5. On Avoiding Single-Prompt Paradigms: "That’s why we don’t believe in this sort of modality where you just write a task and it just goes out and does it... We’ve been seeing real value in the process of actually evolving code from a very basic idea." — Source: [Latent Space]
  6. On Flow-Aware Editing: "By fully integrating the IDE, we can provide the model with deep context, creating what we call flow-aware editing that anticipates the developer's next move." — Source: [Latent Space]
  7. On Enterprise Codebases: "The hardest challenge in AI coding isn't generating a script; it is reasoning about massive, existing enterprise repositories securely." — Source: [Latent Space]
  8. On Control Over the UX: "You cannot build the best agentic experience when you are constrained by the extension APIs of an existing IDE. You need control of the whole environment." — Source: [Latent Space]
  9. On Windsurf's Capability: "I do think it is the most powerful IDE system out there right now in the capability. And this is just the beginning." — Source: [Latent Space]
  10. On the Future of the IDE: "The IDE is shifting from a passive text editor to an active participant in the software development lifecycle." — Source: [Latent Space]

Part 4: The Developer of the Future

  1. On the Mission of AI in Dev: "What we actually believe or the mission of Codeium is to enable developers to dream bigger. If a developer takes a year to go out and build a project, I would like it to be the case that they can use Codeium and instead it would take them weeks." — Source: [Unite.AI]
  2. On Augmentation over Replacement: "I think the biggest advice is to understand these programming tools are purely meant to augment the developers, not replace them. So they should think about these tools as helping automate routine tasks to save time, like an assistant." — Source: [Unite.AI]
  3. On Writing Boilerplate: "I believe developers will still be writing code inside applications in the next couple of years. But I think what is going to happen is the amount of work it takes for them to write boilerplate applications to do tasks like migrations, to do tasks like refactors is going to go down tremendously." — Source: [Alejandro Cremades Podcast]
  4. On the ROI of Engineers: "I believe there will be more developers, not fewer. AI tools increase the ROI of engineering investment." — Source: [Lenny's Newsletter]
  5. On Vibe Coding: "With the rise of natural language as a programming interface, we are moving toward an era of vibe coding, where developers focus on architectural logic rather than syntax." — Source: [Lenny's Podcast]
  6. On the 90 Percent Rule: "Eventually, 90 percent of code will be AI-generated, but the demand for engineering jobs will actually increase because the complexity and volume of what can be built will explode." — Source: [Lenny's Podcast]
  7. On the Superpower of AI: "Codeium is a superpower engineers learn to wield very effectively, but the superpower never replaces them. It makes their day more enjoyable and satisfying." — Source: [Unite.AI]
  8. On Developer Joy: "The ultimate goal is removing the friction from development so engineers can spend their time in a state of creative flow." — Source: [Software Engineering Daily]
  9. On the AI as a Problem Solver: "AI is going to handle the vast majority, if not all, of the solving part of coding." — Source: [EducationNext]
  10. On Managing AI Output: "The developer's role is shifting from primarily writing code to reviewing, managing, and guiding AI-generated output to ensure system-level correctness." — Source: [Software Engineering Daily]

Part 5: Deep Learning at Scale

  1. On the Cost of Latency: "If we add a couple hundred milliseconds of latency to autocomplete, we've noticed a massive decline in sort of the usage of the product." — Source: [Gradient Dissent]
  2. On Owning the Stack: "Part of the reason why we don't use standard libraries is not because we don't like Nvidia... we want a system that is tunable where we can control performance." — Source: [Gradient Dissent]
  3. On Autocomplete Complexity: "Autocomplete as a product looks actually quite different than an arbitrary chat product. It requires millisecond-level responsiveness." — Source: [Gradient Dissent]
  4. On Latency and Quality: "If the latency is incredibly high, the quality better be perfect... you can ship a demo that works one in a 100 times but then the reality is you will erode developer trust very, very quickly." — Source: [Gradient Dissent]
  5. On Infrastructure as a Moat: "We trained our own proprietary models specifically optimized for our infrastructure because API latency from third parties was simply too high for real-time editing." — Source: [Latent Space]
  6. On Managing GPU Scale: "At Exafunction, managing over 10,000 GPUs taught us exactly where the bottlenecks in deep learning inference actually live." — Source: [Software Engineering Daily]
  7. On Enterprise Resource Efficiency: "Because we built our own GPU compiler and virtualization layer, we can run our enterprise product on dramatically less hardware than competitors." — Source: [Software Engineering Daily]
  8. On Custom Models vs. General Models: "General LLMs are great for planning, but you need custom, low-latency models for keystroke-by-keystroke interaction." — Source: [Latent Space]
  9. On Building for Reliability: "Infrastructure isn't just about speed; it is about predictability. A system that is fast 90 percent of the time and slow 10 percent of the time is unusable for developers in flow." — Source: [Latent Space]

Part 6: Hiring and Dehydrated Scaling

  1. On Dehydrated Growth: "We operate as a dehydrated company. The moment people are no longer underwater, we don't scale the company anymore." — Source: [Lenny's Podcast]
  2. On Hiring for Agency: "We hire for agency. If we don't innovate and do crazy things, we're going to die." — Source: [Lenny's Podcast]
  3. On Earning Hires: "We only hire someone when we ourselves did something and we didn't do it that great... we never hire a sales rep until we've proven the process ourselves." — Source: [Lenny's Podcast]
  4. On Personal Involvement in Recruiting: "Even with 200 employees, I still interview every single hire personally. Culture fit is that critical." — Source: [Lenny's Podcast]
  5. On Maintaining Startup Energy: "Big companies are not that different than small companies in their flaws. The hardest thing to maintain as you scale is intellectual honesty." — Source: [Lenny's Podcast]
  6. On Avoiding Bloat: "Scaling headcount before you have scaled your understanding of the problem is a guaranteed way to build a mediocre product." — Source: [Medium]
  7. On Team Density: "We believe in high engineering density. A small team of exceptional people with high agency will consistently outperform a massive team." — Source: [Medium]
  8. On Delegating After Doing: "You cannot effectively manage a function in a startup if you haven't first painfully attempted to do it yourself." — Source: [Lenny's Podcast]
  9. On Existential Urgency: "The feeling of being overwhelmed isn't something to cure with hiring; it is the natural state of a startup pushing its boundaries." — Source: [Lenny's Podcast]

Part 7: Customer Obsession and Realism

  1. On the Danger of Pure Obsession: "In some ways, too much customer obsession might be bad in that if you do things that all of your customers ask you to do, sometimes you might incrementally iterate to actually build a really bad product." — Source: [Lenny's Podcast]
  2. On Uncompromising Realism: "You need some form of irrational optimism... but also at the same time, you need to be very realistic. And I think this comes with uncompromising realism—you need a healthy amount of both." — Source: [Lenny's Podcast]
  3. On Free Tier Philosophy: "We keep the core tool free for individual developers because the barrier to entry for great tools should be zero." — Source: [Software Engineering Daily]
  4. On Building What Users Need vs. Ask For: "Customers can tell you where the pain is, but it is the founder's job to invent the cure. They won't ask for a paradigm shift." — Source: [Medium]
  5. On Trust and Demos: "You can ship a demo that works one in a 100 times but then the reality is you will erode developer trust very, very quickly." — Source: [Gradient Dissent]
  6. On Security for Enterprise: "Enterprise adoption of AI isn't blocked by a lack of interest; it is blocked by a lack of trust in how their proprietary data is handled." — Source: [Latent Space]
  7. On Usage as the Ultimate Metric: "Revenue is a lagging indicator. The real pulse of a product is how viscerally angry users get when you take it away." — Source: [Medium]
  8. On Frictionless Onboarding: "If it takes more than a few minutes for a developer to see value from an AI tool, you have already lost them." — Source: [Software Engineering Daily]
  9. On Product Discovery: "The UI discovery that tripled our adoption wasn't adding more AI; it was making the existing AI fit more naturally into the developer's peripheral vision." — Source: [Lenny's Podcast]
  10. On Honest Feedback Loops: "We prefer users who complain loudly over users who quietly churn. Loud complaints mean they care enough to want it fixed." — Source: [Medium]

Part 8: The Economics of AI Adoption

  1. On Software Commoditization: "If the type of software we were providing infrastructure for was largely looking all the same, we would become a commodity." — Source: [EducationNext]
  2. On AI Value Capture: "The value of AI isn't in generating syntax; it is in reducing the cost of translating human intent into functional software." — Source: [Software Engineering Daily]
  3. On Competing with Giants: "To beat incumbents, you cannot just be incrementally better. You have to be architecturally different from the ground up." — Source: [Alejandro Cremades Podcast]
  4. On the Cost of Context: "Providing an AI with entire codebase context is incredibly expensive computationally, which is why optimizing inference is a business imperative, not just a technical one." — Source: [Latent Space]
  5. On the Velocity of AI Development: "The half-life of an AI advantage is measured in months, not years. You have to keep pushing your own boundaries." — Source: [Latent Space]
  6. On Open Source vs. Proprietary: "There is a place for both, but for highly specialized tasks like low-latency coding assistance, deeply integrated proprietary stacks currently win." — Source: [Software Engineering Daily]
  7. On Developer Demographics: "By lowering the barrier to writing boilerplate, AI will dramatically expand the demographic of who can participate in software creation." — Source: [Unite.AI]
  8. On the Economics of Refactoring: "Tasks like migrations and refactoring have historically been economically unviable for many companies. AI completely changes the ROI on paying down technical debt." — Source: [Alejandro Cremades Podcast]
  9. On the Next Decade: "The next ten years of software won't look like the last fifty. We are moving from writing instructions to orchestrating intent." — Source: [Latent Space]