High Signal Podcasts Evidence ledger
Method
Browse
← Back to evidence

Evidence receipt / belief

Published · transcript-backed

Lenny Rachitsky: belief

20 Apr 2025 Lenny's Podcast Building a magical AI code editor used by over 1 million developers in four months: The untold story of Windsurf | Varun Mohan (co-founder and CEO)

“I think what's interesting about this is another differentiator/moat for companies that end up winning in this space, is you just have more and more of that data than other companies if you're ahead.”

— Lenny Rachitsky

Source trail

Everything needed to verify it.

Speaker
Lenny Rachitsky
Attribution
Verified speaker
Claim type
belief
Recorded
20 Apr 2025
Publisher
Lenny's Podcast

Transcript context

…Yeah, so one of the interesting things that we have from our users, and this is where we try to think like, "Why would we be any better?" is that, actually every hour, we get probably tens of millions of pieces of feedback from our users. We get a lot of feedback on what they like and what they don't like. For something like autocomplete, we get a lot of preference data, a lot of preference data. And the preference data is weird. It doesn't look like data that you find on the internet. It's like data as the user is typing. Imagine you're typing some code in a code base, the code's going to be incomplete as you're typing it, right? It's not going to be in a full-fledged form. It's not like it is on GitHub. But we have a lot of data that looks like this. So we are uniquely well-positioned to actually build a good model that can complete code even when it's in an incomplete state when the models that are out there, the frontier models have consumed very little code that looks like this. So for that case we're like, "Hey, we can go out and do a much better job potentially." And we'll go out and train models on all the preference data we have. The same is kind of true on retrieval, right? There's a way to find out, are we retrieving the right data? Did the user accept the code change after that? Was the retrieval actually a good retrieval a signal that we can get? So basically the way we like to look at it is, if something is just purely code planning, there's not a great reason why we would be the best at that. I can't come up with a coherent argument for that. But for something that looks more along the lines of, "Hey, here's an intermediate code base that is very gnarly and here are some changes that need to get made" and we know the evolution of the code or we've seen the evolution of code across millions of users, we feel like we can do a great job of that. I think what's interesting about this is another differentiator/moat for companies that end up winning in this space, is you just have more and more of that data than other companies if you're ahead. Yeah. This is sort of why maybe at a high level we like the zero-to-one app building product space. I think it's really... It's a good product space. But ultimately I think it needs to boil down to you understanding the code, because otherwise, you're living at too high a plane where it's not clear why you would be able to be the best at that compared to everyone else. It's not really clear.…

Stored transcript either side of the excerpt. The highlighted words are the published quote; the surrounding text is unedited source, never generated.

Search evidence