创业：不要爱上你的想法

初创公司有一件奇怪的事：你不会因为把同一件错事做得更久而获奖。到最后你失败了，没人会在乎。非常激动地欢迎来自硅谷最热门、最受关注的初创公司之一 Windsurf 及其 CEO Varun。通常率先进入新范式的公司是那些愿意自我颠覆的公司。当你有一个伟大的新想法时，即使那个想法的粗糙版本也已经很棒了。初创公司失败不是因为内部看起来一团糟，而是因为没有把正确的事情做得足够好。经营一家只有一件重要事情的公司，比经营一家收入相同但有五件重要事情的公司要容易得多。你今天对什么想法过于执着？我想如果凭经验来说，准备好了吗 Varun，我太兴奋了。顺便说一句，我从 Lee Marie、Neil Mater 和其他人那里听到了很多关于你的好话。非常感谢你加入我，伙计。

One of the weird things about startups is that you don't win an award for doing the same wrong thing for longer. Down the line when you fail, none of them will care. So excited to welcome one of the hottest, most talked about startups from the valley, Windsurf and their CEO, Varun. Companies that are usually first to a new paradigm are companies that are willing to disrupt themselves. When you have a new great idea, even the crappy version of that idea is already amazing. Startups don't fail because they look like messes inside. Startups fail because they don't do the right thing well enough. It is much easier to run a company that has only one thing that matters than it is to run a company with the same amount of revenue with five things that matters. What idea do you think that you are too in love with today? I think if I was to go empirically ready to go Varun, I'm so excited for this dude. I've heard so many good things by the way from Lee Marie, from Neil Mater, from many others. So, thank you so much for joining me, man.

是的，非常感谢 Harry 邀请我。

Yeah, thanks a lot Harry for having me.

没事的，伙计，但我想深入探讨一下。我刚刚一直在跑步，之前听过你的一些节目，有几个片段让我觉得，天哪，真希望我们能深入聊聊。其中有一个我想从这里开始。你说过，你最初相信的东西很少会是正确的东西。你是如何改变对什么是真正伟大的想法、什么不是的看法的？

Not at all dude, but I wanted to kind of pick apart. I've literally just been running and I've been listening to some of your shows before and there are a couple of segments where I was like, damn, I wish we double clicked on that. And there was one that I thought 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?

我认为彼得·蒂尔的观点有很多正确之处：你想选择一些一开始看起来不太明显的东西，对吧？无论你创办什么公司。问题在于，大多数不明显的想法只是坏主意。就像大多数非传统的想法，仅仅因为你不传统并不意味着你会选到一个好主意。我认为人们有时会忘记这一点。但从高层次来看，如果你选择一个对所有人来说都很明显的想法，可能就没有超额收益了，对吧？大公司会抢先进入市场，因为他们比你拥有更多的分销资源、资源和资本。所以初创公司通常通过选择对公众来说非传统的想法来获胜。但你需要保持谦逊，明白你的奇怪想法很可能实际上并不是一个好主意。

I think there's a lot that's right about the Peter Thiel-ism of you want to pick something that seems a little bit not obvious to start with, right? For whatever company you're starting. And the problem is most ideas that are not obvious are just bad ideas. Like most ideas that are non-conventional, just because you are non-conventional doesn't mean you're going to pick a good idea. And I think people sometimes forget that. But I think at a high level though, like if you pick an idea that is like obvious to everyone, there's probably no alpha, right? A big company is going to go out and already beat you to the market, right? Because they have more distribution resources and capital than you. So startups usually win by picking non-conventional ideas to the public. But you kind of need to go in and be humble enough to understand that probably there's a good chance that your weird idea is not actually a good idea.

你认为你在转向 Windsurf 时的非传统洞察是什么？

What do you believe was your non-conventional insight when you made the pivot to Windsurf?

是的，我甚至可以从更早开始说。我们的第一个想法，甚至公司名字都改过两次了。最初叫 Exa Function，我们构建了 GPU 虚拟化技术，认为 GPU 工作负载将驱动世界，这差不多就是当时的使命。公司里很多人之前从事自动驾驶和 AR/VR 工作。我们有一个相当小的团队，准确预测了 GPU 会变得非常流行。我们基本上说英伟达会卖出大量 GPU。但我们错的是 GPU 工作负载的多样性，对吧？我们以为会运行许多不同的模型架构，会有数百种不同的模型架构，但我们错了。最终它们都变成了 Transformer。在一个所有架构看起来都相同的世界里，我们几乎没有理由成为那个类别中差异化的基础设施提供商。所以我们当时需要转型。但这就是那些事情之一：你进入市场时不知道世界会变成那样。我们只是假设错了。所以这就是为什么有时候你有一个当时不太明显的观点，然后你可能会错。

Yeah, so I mean I could even start before this like the first idea that we had even like our company name has changed twice now at this point. It was called Exa Function when we first built GPU virtualization technology was that GPU workloads were going to power the world, right? That was like sort of the the mission there. A lot of us at the company had previously worked in autonomous vehicles and ARVR at the company. We had a fairly small team that was actually accurate that GPUs were going to become very popular. Like we were 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, right? We thought a bunch of different model architectures would be run. There were going to be hundreds of different model architectures and we were wrong. All of them ended up being transformers. And 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. But that's some one of those things where you don't know going into the market that that's how the world is going to turn out. Right. And we were just wrong about our hypothesis. And so that's why like sometimes you have a take that is not very obvious at the time and then you could be wrong.

完全同意。问题在于很多人过于执着于自己的论点。这就是为什么我直说了，我讨厌论点驱动的投资者。但很多人热爱自己的想法，他们被告知，真正的勇气和坚持才是区分赢家和输家的关键。你对此怎么看？相比之下，你有一个我很赞同的精彩说法：永远不要过于热爱自己的想法。

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

我认为这是创办公司或建立公司最难的部分，对吧？它需要你头脑中两种几乎相反的信条：非理性的乐观主义，因为如果你完全没有乐观，你什么都不会做，甚至不会起床；以及毫不妥协的现实主义。每一天你都需要问自己：我们有存在的理由吗？如果答案是否定的，你就需要非常快地改变想法，非常快地重新调整整个公司。初创公司有一件奇怪的事：你不会因为把同一件错事做得更久而获奖。告诉你的同事、投资者和朋友说“嘿，我还在做我一直在做的事”可能会感觉更好，但到最后你失败了，没人会在乎。

I think this is the hardest part about starting a company or building a company in the first place, right? It requires these two almost counter beliefs in your head, right? 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, right? And uncompromising realism. Every single day, you need to be asking your question, do we have a reason to exist, right? And 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. Like it might feel better to tell your co-workers, tell your investors, tell your friends that 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? So I'll give you an example. For me as an investor, discipline around portfolio construction. I love the belief of a disciplined investor, the craft of portfolio building. The challenge is in today's world, you have to break most rules. And it doesn't mean that 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?

我想如果凭经验来说，我们每次都过于执着于自己的想法。就像外面的人可能觉得这家公司转型多次是积极的结果，但我希望我们能更快。我仍然自责为什么我们没有早三个月从 GPU 虚拟化转型到代码 AI 公司。我认为我们当时有信号，但我们一直等到合作的客户开始倒闭才真正转型。当时很多客户是自动驾驶公司，正值零利率时代高峰。然后在 2022 年中，当许多公司无法进行下一轮融资时，我们才开始质疑：嘿，市场在变，技术也在变，而且我们未来的客户看起来也无法满足我们的市场。我希望我们能更快。对于像 Windsurf 这样的想法也是如此。我认为我们知道智能体会非常强大，我们本可以早几个月构建 Windsurf，我认为如果可以的话，我们应该那样做。

I think if I was to go empirically, we were too in love with our ideas every time. Like other people outside looking in might have been like this company has pivoted multiple times and that's a positive outcome, but I wished we had done it faster. I still beat myself over the head on why did we not pivot from the GPU virtualization to the code AI company three 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. Right? A lot of our customers at the time were autonomous vehicle companies and it was peak zero era, right? And 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, like the market is changing, the technology is also changing, but also our future customers are not looking like they're going to be able to kind of satisfy our sort of our market, right? And I wish we had done that faster. And the same is also true for ideas like Windsurf, right? I think we knew agents were going to be very powerful and we could have built Windsurf a couple months earlier and I think we should have done that if we could have.

我能问你一个问题吗？我刚刚请了 Fiverr 的 CEO 上节目，他说克隆时间（time to clone）是过去几年变化最大的事情之一。克隆时间指的是别人完全复制你产品所需的时间。我的问题是，如果克隆时间比以往任何时候都短，那么成为第一有多重要？

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 being the amount of time it takes for someone to copy exactly what you have. My question to you, how important is it to be first if time to clone is shorter than ever before?

我认为成为第一有两方面作用。第一，它反映了你如何运营公司。第二，它能让你学得更快。我来详细说说第一点。通常率先进入新范式的公司，都是愿意自我颠覆的公司。它们是那种能够迅速转变、时刻拥抱变化的组织，并且总是投资于非渐进式的技术，甚至愿意打破自身。在软件或代码 AI 这类快速变化的领域，我认为这样的组织是优秀的。这是第一点。第二点，成为第一意味着你能更快地从市场学习，这也意味着你能率先进入下一个想法，因为你看到了赛道里所有的失败案例。我喜欢这样想：如果我们更早推出产品，第一个月学到的东西就能帮助我们构建下一个产品。我认为这会带来随时间累积的复利优势。

I think being first does two things. First, it's a signal of how you're running the company. Second, it allows you to learn faster. Let me 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 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. That's one. Then two, I think it boils down to what it means if you're first: 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. One nice thing I like to think is if we have a product in market earlier, all the things we can learn in the first month enable us to build the next product as well. I think that gives us a compounding advantage over time.

看着别人先走，看他们犯了什么错，然后从他们的错误中学习，利用他们付出的成本，而自己不用承担那些成本，这样不是更有帮助吗？

Is it not more helpful seeing someone else go first, see what they do as a mistake and then learn from their mistakes and leverage the cost that they have and then do it without that cost for you?

我认为软件行业普遍的问题是，他们在研发内部可能犯了很多错误，而我们根本无法看到。从组织层面看，我们公司现在在赛道上积累了大量的智慧，有些想法我们甚至不会去碰，因为我们以前试过，但没成功。这已经融入了公司的 DNA，随着我们持续创新，这种经验从外部是很难看到的。

I think the problem in software in general is they could have made a lot of mistakes internally during research and development that we could never take a look at. Organizationally, our company now has so much wisdom in our category that there are ideas we would not even touch because we've tried them before and they didn't work. That's built into the DNA of the company as we continue to innovate, and that's not easy to see from the outside looking in.

你们以前尝试过哪些没成功、而外界不知道的事情？

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

是的，我们发布过一个测试版产品，但内部用了很长时间。我给你举几个例子。第一个，去年我们实际上发布了一个代码审查的测试版产品，尝试了不同的发布方式。我们做了一个 Chrome 扩展，还在内部建了一个平行网站，试了很多东西，但都不太对劲。几周前，我们发布了一个代码审查产品，感觉好多了，价值也更大。我们之所以能这样发布，正是因为去年所有的失败尝试。第二个例子：我们与 Windsurf 一起发布的代码智能体产品，其实去年年初就有了第一个版本，但由于各种原因效果不好。这让我们回到绘图板，修复了不同环节。我们需要在代码库理解上做得更好，模型也需要改进。一旦模型变好了，我们在代码库理解上的内部研发也足够成熟，就可以发布了。如果我们只是等着别人先做，我们就得在多个维度上追赶才能发布产品。

Yeah, so we shipped a beta version of this product, but we were dogfooding it for a long time. I'll give you a couple examples. First, we actually shipped a beta product for code review last year and tried different ways of shipping it. We had a Chrome extension. We built a parallel website internally and tried a bunch of things, but none felt quite right. A couple weeks ago, we shipped a code review product and it feels much better and provides a lot more value. We shipped it the way we did because of all the failed attempts last year. Second example: for the code agent product we launched with Windsurf, we actually had our first cut of that product at the beginning of last year, and it was not good for a variety of reasons. That enabled us to go back to the drawing board and fix up the different elements. We needed to get better at codebase understanding, and the models needed to get better. Once the models improved, our internal R&D on codebase understanding had progressed enough that we were ready to ship. If we had just waited for the rest of the world, we would have had 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, the experiments you can take? If you raise more, you have more experiments fundamentally. Do you advise that given the experience you have?

我们显然是在 GPU 虚拟化的想法上融了 A 轮；Green Oaks 领投了那轮。他们是否也领投了你们的种子轮？不，他们没有。他们也领投了我们的种子轮，至于他们是否应该投资那个 A 轮，我把这个问题留给观众。但我认为这给了我们信心：如果我们转型，我们仍然有现金去追求一个想法。我们实际上在之前完全免费推出了扩展产品 Kodium。我们能做到这一点，是因为公司内部的基建专长，但也是因为我们有信心，因为我们知道银行里有现金，可以发布这个产品而不必担心细节。所以我同意你的观点。这确实给了你更多的机会，但我认为你需要一个能够快速转型的公司。大多数公司，当有 10、15、20 个人的时候，不愿意完全改变他们的想法。而我们，我和联合创始人决定在一个周末内开始做 Kodium，周一告诉公司，所有人从那个周一开始就投入工作，尽管我们之前的业务已经带来了几百万的收入。

We obviously raised our Series A on the GPU virtualization idea; Green Oaks actually led that round. Whether or not they led your seed as well? No, they didn't. They led our seed too, which whether or not they should have invested in the Series A on that one, I'll leave to the audience. But I think what that gave us was the confidence that if we pivot, we will still have the cash to go out and pursue an idea. We actually launched Kodium, the extension product before this entirely free. We were able to do that because of the infrastructure expertise inside the company, but also we were confidently able to do that because we knew we had cash in the bank to ship this product and not worry about details. 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. Most companies, when they have 10, 15, 20 people, are unwilling to change their idea entirely. We, on the other hand, decided we wanted to work on Kodium over a weekend, me and my co-founder, and we told the company on Monday and everyone started working on it that Monday, despite the fact that we were making a couple 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?

我认为答案是，对于初创公司，我的一个坚定信念是：公司成功不是因为做了很多事做得好，而是因为把一件事做得特别好。就像我说的，有一个好主意对大多数初创公司来说已经是奇迹了。从这个角度看，任何产品都有某种指数增长曲线，每个产品都有一个 R 值。初创公司应该始终专注于 R 值更高的产品。如果两个产品完全不相干，把资源分散到两个不同的指数增长曲线上是毫无意义的。所以当你转型时，我认为正确的做法是放弃过去做的事情，因为过去做的事情很可能与你未来的业务毫无关系。

I think the answer is 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 one thing really well. It's like what I said: having one good idea already is like a miracle for most startups. When you think about it from that perspective, 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 a higher R value. It never makes sense to divert resources to work on two 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 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.

对吧？那个业务的收入倍数看起来完全不像另一个业务的收入倍数。我认为如果你能彻底戒断，真正让你的组织完全投入到新事物上，你更有可能成功。但这很可怕，对吧？你需要告诉人们，告诉你的投资者，告诉你的客户，你不再支持那个了。但我认为一旦你做出艰难的决定，事情就变得简单了。

Right? The revenue multiple on that business is not going to look at all like the revenue multiple of the other business. And I think if you can go cold turkey and actually go and make your organization completely work on the new thing, you're more likely to succeed. But that's scary, right? You need to tell people, tell your investors, tell your customers, 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 one thing really well and it's hard enough to have one thing. You have that, but what thing would you most like to do that you're not doing because you retain that element of focused mindset?

是的，我认为在我们的品类中，也许我可以这么说，我们 Windsurf 的很多用户实际上是非开发者。他们是构建应用的人，并且实际上将其用于生产用例。比如在我们公司内部，有一个非开发者负责合作伙伴关系，他使用了我们的产品，构建了应用来替代大量销售工具的开支，内部节省了超过 50 万美元的销售工具费用。他们编写了价值 50 万美元的代码。是的。他们在公司内部构建了应用，比如合作伙伴门户和报价工具等等，这些在过去每年花费数十万美元的销售工具。现在他们值得加薪，对吧？

Yeah, I think in our category, maybe if I was to just say this, in our category, a lot of our users of Windsurf are actually people that are non-developers. They're people that are building apps and they're actually using it for productive use cases. Like internally at our company, we have someone who's a non-developer who leads partnerships that has used our product and built apps to replace a lot of sales tool spend like over $500,000 of sales tool spend internally. And I think there's a lot of things we can do to make so they they've coded 500,000. Yeah. They built apps inside the company for like a partner portal and quoting tool and so on and so forth that these are sales tools that in the past cost hundreds of thousands of dollars a year. Now the reason they deserve a payrise phone, right?

是的。我的意思是，我们应该考虑一下。

Yeah. I mean, we should we should get we should consider that.

嗯，但之前之所以如此，呃，不跑题了，是因为这些是非常定制的工具，对吧？这些是非常定制的工具，只做单一功能，过去没有哪家公司愿意自己构建这些。但现在软件构建变得如此便宜，比如临时软件或更简单的软件构建成本极低，非技术人员也可以构建这些应用。我认为，Harry，对我们来说一个有趣的途径是如何让这类用户比现在更高效，但这里总是存在一种张力，对吧？如果我们让这类用户更高效，我们可能会放弃让处理大型代码库的开发者更高效的能力。这只是一个专注的游戏。

Um, but the reason why that was the case before um not to go on a tangent was because no one really these are very bespoke tools, right? These are very bespoke tools that do a singular function and no single company wants to build this out themselves, right? in the past, but now with software being so cheap to build, like ephemeral software or simpler simpler software being so cheap to build, um you can now have nontechnical people kind of building these apps. And I think Harry, like 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, right? If we make that user much more productive, we might be giving up the ability to make developers that operate on large code bases much more productive, too. It's just a focus game.

Windsurf 是让工程师效率提升 10 倍，还是让普通人能够成为工程师？

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

是的。所以我认为我们专注于前者。我们专注于前者，而后者是前者的结果，因为底层技术能够做到这一点，但焦点绝对是前者。

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

随着时间的推移，你们会趋同吗？Cursor 和你们会趋同，吃掉 Lovables 和 Bolts，而 Lovables 和 Bolts 也会趋同，试图吃掉你们吗？

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

你知道，我认为这是一个我们经常被问到的问题。我认为那些非常专注于非开发者的工具，比如 Lovables、Bolts，随着时间的推移，它们将需要构建越来越多的可调参数，越来越多的配置产品的方式。但对我们来说，如果我们能深入理解代码，比如大型代码库，那么非技术人员几乎不需要什么努力就能构建应用，这自然会实现。但也许我的观点是，如果我们现在为那个用例构建，我们就会放弃帮助开发者的能力。但我认为随着时间的推移，这两个类别会趋同。就像一个深入理解你代码库的公司，能够用很少的自然语言构建一个与公司现有代码库一致的完整应用。

You know, I think once once and this is uh this is I think a really common question we get which is that I think those tools that are very focused on like the Lovables, the Bolts that are very focused on the non-developer. I think with time they're going to need to build out more and more tunables, more and more ways to configure the product with time. Um but I think I think for us if we can deeply understand code like large code bases it'll naturally fall out that with very little effort non-technical people can build apps. But maybe my point is if we build for that use case right now it's we're we're going to be kind of forgoing the ability to help developers. But I think it will converge it will converge with time uh between both of these categories. Like 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 code bases 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 it. Uh if you had infinite resources is there anything that you would do differently to how you're doing it today?

我认为我们会下更多的赌注。我们会在公司内部下更多的赌注，尝试更多的事情。就像我说的，我们在公司内部尝试的事情中，大概 50%或更多实际上失败了。我们实际上在产品技术上投入了很多，用于未来的事情，而且大部分都失败了。实际上，我希望失败得更多，但初创公司的奇怪之处在于，成功的那一件事会为失败的数百件事买单。在公司内部，我和 Neil Ma 谈过一些事情，我之前必须问你，他说你一定要问他如何构建产品以及他的产品构建周期。你提到内部周期中有 50%失败。你能谈谈你认为重要的、关于内部产品构建的一些非常规方法吗？

I think we would be making many more bets. We'd be making many more bets inside the company like trying many more things. Like as I said probably 50% of the things that we try inside the company or more actually fail right we are actually investing a lot of our product technology on things that are in the future uh and most of it fails actually I would like to fail even more but the weird thing about startups is the one thing that works pays for the hundreds of things that fail uh internally at a at a startup I I spoke to Neil Ma 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 mentioned there 50% fail the internal cycle. Can you talk to me about some unconventional ways that you think about internal product building that you think are important?

是的，我认为有一种传统智慧，从其他人那里你得知，拥有更多工程师的公司就会成功。但这让软件工程和研发感觉像工厂建造过程。我认为正确的看法是，当一个产品或想法还没有站稳脚跟，你正在验证它时，实际上应该只有很少的人在一个想法上工作，对吧？因为实际上，这是一个非常普遍的情况，每个人都会理解。想象一下，10 个人在一个尚未被证明的事情上工作。每个人都有意见，每个人都有想法，而且没有人的想法是错的，对吧？因为没有人证明过任何东西。所以很难达成一致。人们很难朝着一个方向工作而不引起沟通问题。相反，真正好的是，你能让少数有主见的人去验证一个想法，然后问题就是，如果你能从中获得一点价值，这对任何产品来说都是一个难题：你如何知道何时停止？我认为我们建立了一个有趣的智慧，我们公司很多人之前都在硬科技公司工作过，比如自动驾驶汽车公司，那就是当你有一个伟大的新想法时，即使它的粗糙版本也已经很了不起了。它已经证明了一些了不起的东西，对吧？比如，当我们构建 Windsurf 中智能体的第一个工作版本时，即使是粗糙版本也能做到我们八、九个月前无法做到的事情，对吧？我们就觉得，好吧，这东西有潜力。

Yeah, I think there's conventional wisdom and you know from other people that a company with more engineers is just going to succeed. But that sort of kind of makes software engineering and just R&D feel like a factory building process. I think the right way to actually look at it is 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, right? Because actually like this is a very common everyone will understand this. Imagine having 10 people working on something that has not been proven up. Everyone has opinions. Everyone has ideas and nobody's ideas are wrong, right? Because no one has proven anything out. So it's very hard to get alignment. It's very hard for people to work in one direction without causing communication issues. Um instead what is actually really good is can you have a handful of people with an opinionated stance that can go out and prove out an idea and then the question is uh with that if you can if you can go and get a nugget of value and this is like a hard question for any product how do you know when to stop working on it right um and I think there's this interesting like kind of piece of wisdom that that we've built and a lot of us at the company have worked in hard tech before this like companies like autonomous vehicle companies before this is that when you have a new great idea, even the crappy version of that idea is already amazing. Like it already proves something amazing, right? Uh like for instance, when we built the first working version of like the agent in Windsurf, um the even the crappy version of that was able to do things that we were never able to do in the past like eight or nine months ago, right? And we were like, okay, this thing has legs.

在我们继续之前，我能深入探讨几个点吗？你提到了一小群人。那是多少人？你如何为这些新项目组建团队？

Can I just dig in on a couple of elements before we carry on? You mentioned like a handful of people. How many is that? How do you structure these teams on new bets?

大概三四个人。几个工程师和一个设计师。或者如果是纯系统技术，可能就只是纯工程师来构建。我们产品的一个酷点是它是一个开发者产品，所以我们的开发者自己对一个粗糙版本以及它至少作为 v0 能有多有用有一些直觉，因为我们正在为开发者构建产品。

It's maybe three or four people. A couple of engineers and a designer. Or in the case of a pure systems technology, it could be just pure engineers building it out. One of the cool parts about our product is we are a developer product, so our developers themselves have some intuitions on a crappy version and how useful it could be, at least the v0, because we're building a product for developers.

你们会设定预算或时间吗？那是怎么运作的？

Do you set a budget or time? How does that work?

我觉得我们其实没怎么考虑过。部分原因是我们现在处于一个不受约束的市场。能够加速软件开发的伟大技术对我们的客户来说太有价值了，所以我们基本上不考虑特定项目的预算。我们关注的是项目随时间解锁的进展，以及是否应该决定继续前进，把某个东西搁置以后再做。这是公司内部自上而下的过程，不是民主的。

I don't think we actually think about that. Partially because we're in an unconstrained market right now. The value of great technology that could accelerate software development is so valuable to our customers that we largely don't think about the budget of a particular project. What we do look at is the progress we're unlocking in a project over time and whether we should decide to move on and table something to work on later. That is a top-down process inside the company, not democratic.

有没有什么东西是你搁置了，但事后看来希望自己继续做下去的？

Is there anything you've tabled that with hindsight you wish you had kept going with?

有的。一个例子是自动补全体验，那是我们构建的第一个产品。我觉得我们推迟了尽早构建更好产品体验的时机。产品体验不够好的部分原因是我们被困在 VS Code 里，它没有给我们足够的 UI 能力来大幅改进产品。一旦我们有了 Windsurf，我们就能够在这方面投入更多。

Yes. An example is the autocomplete experience, which was the first product we built. I think we delayed building a much better product experience sooner rather than later. Part of the reason the product experience wasn't as good was because we were stuck in VS Code, which didn't give us the UI capability to make it much better. Once we had Windsurf, we were able to invest much more in the capability.

你提到了 VS Code。这让我想到了护城河和防御性的话题。在 AI 的世界里，护城河已死。每个人都说 Cursor、Windsurf，我可以在这两者之间切换。帮我理解护城河，以及你怎么看待这个问题。

You mentioned VS Code. That brings me to the topic of moats and defensibility. Moats are dead in a world of AI. Everyone says Cursor, Windsurf, I can switch between the two. Help me understand moats and how you think about that.

我认为初创公司拥有护城河在大多数情况下通常是有点傻的。传统的七种力量，如果有人读过那本书，我很喜欢，但对初创公司来说还为时过早。你可以拥有世界上最好的工程师，但只有 50 到 100 名工程师，那也只是几百个工程年。别人也能在这个领域构建东西。我认为我们类别中唯一的护城河是速度。就是学习哪里有坑，学习如何积累优势。一个例子是英伟达。每个人都认为 CUDA 是真正的护城河，但那不准确。如果谷歌、OpenAI、Anthropic 没有 CUDA，他们会想办法写汇编来在 GPU 上运行。人们使用它是因为它很棒。他们让它非常擅长低浮点运算，互连很好，算力很快，而且每年他们头上都有一颗定时炸弹：如果他们不把硬件、互连、内存带宽做得更快，他们的利润率就会缩水。AMD 会找他们麻烦。英伟达没有像谷歌那样的公司属性，但它仍然是世界上最有价值的公司之一。

I think startups by and large having a moat is usually kind of silly for the most part. The conventional seven powers, if anyone has read the book, I love it, but it's premature for a startup. You could have the best engineers in the world, but with 50 to 100 engineers, it's still only hundreds of engineering years. Someone else can build something in this space too. I think the only moat in our category is speed. It's learning where the dead bodies are, learning how to compound an advantage. An example is Nvidia. Everyone thinks CUDA is the real moat, but that's inaccurate. If Google, OpenAI, Anthropic didn't have CUDA, they'd find a way to write assembly to run on GPUs. The reason people use it is because it's awesome. They've made it really capable at low floating-point math, the interconnect is good, the compute is fast, and every year they have a ticking time bomb: if they don't make the hardware, interconnect, memory bandwidth much faster, their profit margin shrinks. AMD will be on their case. Nvidia doesn't have the same properties as a company like Google, but it's still one of the most valuable companies.

我完全同意初创公司护城河的观点。但如果其中一家成为像 OpenAI 或 Anthropic 这样大公司的一部分，他们突然就有了分发、品牌和资源，能以无与伦比的规模购买芯片。突然间七种力量变得突出，护城河就存在了。

I agree totally in terms of moats for startups. But if one of them becomes part of a very large company like OpenAI or Anthropic, they suddenly have distribution, brand, and resources to buy chips at scales unparalleled. Suddenly seven powers become prominent and moats exist.

我认为在这种情况下速度仍然重要。为什么初创公司能在重要类别中获胜？为什么谷歌在 2000 年代早期微软已是巨头时获胜？如果一家公司有好的洞察力并能战略性地超越另一家公司，他们就会赢。我会说分发比速度更重要。

I think speed is still important in that case. Why does a startup ever win in an important category? Why did Google win in the early 2000s when Microsoft was a behemoth? If a company has good insights and is able to outexecute strategically another company, they will win. I would argue that distribution is more important than speed.

听着，你是身价数十亿美元的创始人，所以请纠正我，但合作协定的确在早期推动了谷歌。但也是因为他们有最好的产品，所以很多人想与他们合作。也许让我这么说：我们的领域非常非常有价值。

Listen, you're the multi-billion dollar founder, so please correct me, but partnership agreements really propelled Google in the early days. But it was also that they had the best product, so many wanted to partner with them. Maybe let me put it this way: our space is very, very valuable.

但如果你看看那些超大规模云服务商，他们在这个类别里的产品其实并不出色，对吧？尽管他们已经有很大的分发渠道。为什么会这样？我认为实际上是因为很难快速集结人才去执行这个类别。我们这样的公司现在每 1 到 2 周就发布一个重大版本。你能说出哪家大公司能学得这么快吗？为什么在当今市场如此火热的情况下，大公司在开发速度上却如此糟糕？

But if you actually look at a lot of the hyperscalers, their products in the category are not amazing products, right? Even though they have a lot of distribution already. Why is that? And 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?

我认为是生存恐惧，对吧？初创公司有生存恐惧，担心如果发货不够快、学习不够快，他们能否生存。如果我在一家巨头公司，比如亚马逊，而亚马逊现在有我们这类产品。你觉得做这个产品的员工会担心如果发不出好产品，6 个月后还有工作吗？如果我们当初发货的产品质量和那些超大规模云服务商一样，我们一年前就出局了。但他们现在可能还有工作。

I think it's existential dread, right? A startup has existential dread on whether they can survive if they don't ship fast enough, if they don't learn fast enough, right? If I'm inside a behemoth, like I'm inside Amazon, right? And Amazon has a product in our category right now. Do you think the employees working on this are worried if they will 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 be out of the market a year ago. But they probably still have their jobs right now.

每周工作七天又成了硅谷的常态，是吧？我的意思是，我们现在是一家线下公司。是的，我们是一家 100%线下办公的公司。今天你能像硅谷正在回归的那种每周七天线下办公的特殊性一样，高效地远程建立一家公司吗？

It's the seven days a week that's becoming the norm again in Silicon Valley, huh? I mean, we're an in-person company actually right now. Yeah, we're like a 100% in-person company. Can you build a company today remote as efficiently as the in-person 7 days a week Silicon Valley specialness that you're seeing return to the valley again?

我认为只是可能稍微难一点，对吧？我觉得你需要从一开始就是一家更有原则的公司。但我也认为，如果一家公司能让工程师们在同一个房间，必要时每五分钟就能达成共识，那这就是一个不公平的优势。与那些员工在不同时区的公司相比，这在速度上是一个不公平的优势。你不知道什么时候能联系到某人。现在如果是下午 2 点或 3 点，公司里的每个人都可以被叫到同一个房间，所以这大大提高了你的灵活性。在早期，哈里，当我谈到你的第一个想法或想法显然不会准确时，你应该能够非常快速地转向，并尽快调动公司里的每个人。

I think it's just 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 an unfair advantage if a company is able to get their engineers in the same room and on the same page like every five minutes if necessary, right? It's an unfair advantage on speed compared to a company where people are on different time zones. Like 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 and brought into a room at that very moment, so it just makes your flexibility a lot faster. And 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.

你认为在你的类别中，品牌力量重要吗？人们会认同自己是 Windsurf 用户或 Cursor 用户。你认为品牌在其他类别中也有同样的力量吗？

Do you think in your category brand power is important? 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?

你知道，我当然认为拥有一个良好的大品牌是有帮助的。它让你在推出越来越多新产品时，能让更多人使用，而不必从头建立用户基础。但我想提醒大家，大概一两年前，在硅谷，GitHub Copilot 是每个人都在谈论的产品，对吧？那时，如果我在一年前谈论它，实际上一年前多一点是 Devin 的发布。我认为在 3 到 6 个月里，我听到的全是 Devin，对吧？我认为在我们的类别中，我们几乎每天都需要证明自己。如果三个月内我们没有向用户推出令人惊叹的东西，我们就会变得无关紧要，对吧？对很多人来说。如果我们跟不上创新的步伐，我们就会变得无关紧要。所以我认为，如果你能保持并继续以极快的速度创新，品牌肯定是有帮助的，但我不认为品牌给了你作为一家公司放慢脚步的权利。

You know, I would like to obviously I think having a good large brand is just helpful. It enables you as you ship more and more new products for more and more people to be able to use it and not have to build the user base up from scratch. But if I just was to remind everyone, you know, kind of like a year or two ago, probably in Silicon Valley, GitHub Copilot was the product that everyone was talking about, right? At that time and if I was to talk about it a year ago, right, actually a bit over a year ago was the Devin launch. And I think for 3 to 6 months, I was not hearing anything but Devin from everyone, right? And I think it's like in our category, we need to prove ourselves almost every day. If in three months we don't ship something amazing to our users, we will become irrelevant, right? To a lot of them, right? If we don't actually keep up with the pace of innovation, we will become irrelevant. So I think it's a little bit of if you can maintain if you can continue to innovate at breakneck pace, the brand is definitely helpful, but I don't think the brand gives you the right to move slower as a company.

但这些企业难道不应该被内在估值更低或倍数更低吗？如果它们的价值维持能力比以前恶化得更快。正如你提到的，GitHub Copilot，很好的例子。是的。然后突然价值下降得这么快。它们应该以同样的方式估值吗？

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, GitHub Copilot, brilliant examples. Yeah. And then suddenly have a reduction of value so fast. Should they be valued in the same way?

所以，我认为我们公司还有一些我们没有真正谈到的特质，比如拥有大型企业业务，全面覆盖非常大的财富 500 强公司，并且能够为大型团队正常工作，这有固有的转换成本，对吧？不像 Salesforce 等产品那样的转换成本，但我认为我们还没有建立起来。有一个权衡：如果你过于专注于让你的产品难以切换，但如果你也没有足够快地改进产品，人们就会转向更好的产品，尽管你的产品很难切换，对吧？我总是记得看到我的朋友 Tom Blfield 的一条推文。他说：‘我真的不懂这个领域。我以前是 Cursor 用户，我换到了 Windsurf，它更好或者一样好。’或者他为了这个项目换到了 Windsurf。我不知道他是否留下来了。我不是在评论。Tom，别杀我。但我的问题是，你如何看待转换成本和留存，以及在这两者之间切换是否那么容易？

So, I think there are still qualities of our company that we haven't really talked about, like having a large enterprise business, being wall-to-wall at very large Fortune 500 companies, and being able to work properly for large teams which has inherent switching costs for the business, right? Not the same class of switching costs as some of the products like Salesforce, yet I don't think we built that out. There's a trade-off where if you focus so hard on making your product hard to switch off of, if you also don't improve your product fast enough, people will just switch on to the better product despite the fact that it is hard to switch off of your product, right? I always remember seeing a tweet from Tom Blfield 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.' Or like 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. But my question to you was like how do you think about switching cost and retention and is it that easy to switch between the two?

我们需要在功能和产品上足够快地创新，以便为用户构建差异化的体验。这实际上需要很多工作，对吧？正如我所说，我们最终构建的大多数产品都没有成功。尽管我们每几周发布一次版本，但我们发布的一些更复杂的技术，实际上需要几个月才能发布。所以给你举个例子。几周前，我们发布了一个模型，在智能体工作负载上可与一些前沿模型相媲美。我们的模型套件 1 运行速度更快、成本更低，并且能够处理大型代码库。我们通过向用户学习他们如何在内部使用产品来实现这一点，对吧？这对我们来说不是一个月就能完成的事情。我们花了几个月的时间才在内部构建出那个模型。但现在它每天处理数千亿个代码 token。就那一个模型，对吧？而且它运行在我们自己的 GPU 上。但这是那种需要时间来构建这些能力的事情之一。

We need to innovate on features and product fast enough that we're able to build differentiated experiences for folks. That actually takes a lot of work, right? As I was saying, most of our products that we end up building don't end up working. And even though we're shipping releases every couple weeks, some of the more complex pieces of technology that we've shipped, they take months to actually ship. So I'll give you an example. A couple weeks ago, we shipped a model that was comparable to some of the frontier models at the agentic workload. And our model suite 1 is much faster, much cheaper for us to run and capable of operating over a large codebase as well. And we were able to do that by learning from our users on how they use the product internally, right? And that was not a single month kind of experience for us. It took us many months to actually build out that model internally. But these are the kinds of and now it processes hundreds of billions of tokens of code a day. That single model, right? And it's running on our own GPUs. But this is like one of those things that it takes time to kind of build out these capabilities.

你提到了企业业务在你的生意中的优势。目前你们的收入/使用量中，企业客户和自下而上的用户各占多少？

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

嗯，我想说大概超过 50%的总量实际上来自企业客户。

Yeah, I would say probably over 50% of our total is actually enterprise.

企业在购买你们产品时，最关心的问题、教训或事情是什么？

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

我认为有几件事。首先，很多企业和大型公司有很多 Java 开发者。对于 Java 开发者来说，大多数大型公司有大量 Java 代码。他们使用 JetBrains 家族的 IntelliJ IDE。尽管我们有 Windsurf 编辑器，但我们仍然支持所有 JetBrains IDE 的插件，并且功能与 Windsurf 编辑器相同。我们分叉 VS Code 编辑器的原因是我们没有足够的灵活性来构建我们想要的新智能体式体验的 UI。但我们能够通过插件在 JetBrains 中完全实现这一点。例如，我们的客户摩根大通，超过 50%的开发者是 JetBrains 用户。对于这些人，我们可以支持他们所有的开发者。我们不是一个只针对 VS Code 用户的产品。他们可以迁移到 Windsurf。所以这是一个有趣的事实：对于企业来说，有很多 IntelliJ 用户需要我们去满足。当我们进入企业时，我们不想告诉他们只有 40%的用户可以使用我们的产品；我们希望确保他们所有的开发者都能使用。

I think there are a handful of things. The first thing is that a lot of enterprises and large companies have many Java developers. For the Java developers, most large companies have a lot of code in Java. They use an IDE called IntelliJ as part of the JetBrains family. Even though we have the Windsurf editor, we still support plugins into all the JetBrains IDEs, and it has the same functionality as the Windsurf editor. The reason we forked the VS Code editor was because we didn't have enough flexibility to build the UI we wanted for the new agentic experience. But we were able to give that entirely in JetBrains through plugins. For example, JP Morgan Chase, a customer of ours, over 50% of their developers are JetBrains users. For those people, we can support all their developers. We're not a product only for their VS Code users. They can move over to Windsurf. So that's an interesting fact: for the enterprise, there are many IntelliJ users we need to satisfy. When we go into an enterprise, we don't want to tell them only 40% of their users can use our product; we want to make sure all their developers can use it.

你认为 5 年后你的客户会有更多还是更少的工程师？

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

这取决于客户类型，而且“工程师”这个词会变得非常灵活。随着技术越来越好，技术相关的人也会使用 Windsurf，我们已经在一些公司看到了这一点。5 年后的“工程师”是什么意思？如果你回到 50 年前，每个人都在写汇编。然后他们写 C。然后是 C++、Java、Python，现在很多人写 JavaScript。编程的易用性提高了，但很多写 JavaScript 的人完全不知道怎么写汇编。所以我认为会类似：会有人纯粹在自然语言抽象层面操作，AI 工具可以解释软件栈不同组件的工作原理。即使他们在自然语言层面操作，他们仍然可以创造价值。但最终，总会有生产关键型应用。例如，摩根大通构建交易处理系统：你可能不想用“vibe coding”来做这个。对于一个每天处理数百万或数十亿笔交易的系统，你需要有人能深入细节并验证它。所以你会有一个光谱：有人在自然语言层面操作，在公司内部构建能力；也有人能深入细节。需要深入细节的人有多少？可能比今天少。

It depends on the type of customer, and the word 'engineer' is going to become a very flexible word. As the technology gets better, people that are technical adjacent will use Windsurf as well, and we're already seeing this at some companies. What does 'engineer' in 5 years mean? If you go back 50 years, everyone was writing assembly. Then after that, they wrote C. Then C++, Java, Python, and now a lot of people write JavaScript. Ease of programming has gone up, but many JavaScript writers have no idea how to write assembly. So I think it will be similar: there will be people who operate purely on a natural language abstraction, and AI tools can explain how different components of the software stack work. Even though they operate on natural language, they can still be valuable. But ultimately, there will always be production-critical applications. For example, JP Morgan Chase building a transaction processing system: you probably don't want to 'vibe code' that. For a system processing millions or billions of transactions a day, you need someone who can go down to the weeds and validate it. So you'll have a spectrum: people operating on natural language building capabilities inside companies, and people who can go down to the weeds. How many need to go down to the weeds? Probably fewer than today.

5 年后产品经理还有角色吗？

Do PMs have a role in 5 years?

我认为对产品经理的期望不会是“我告诉别人去构建东西”，而是“你也应该自己去构建”。他们需要更多的主动性。但好处是这些 AI 工具会赋予他们这种能力。如果你有一个懂代码、能写代码的技术型产品经理，他们现在比过去更强大。你不需要给他们一个 10 人团队来验证他们的想法。我现在不喜欢产品经理的一点是，他们花太多时间写文档来说服组织，但他们应该直接构建一个他们想要的东西的版本来证明。为什么要花时间像玩《权力的游戏》一样哄着组织？这在未来没有意义。

I think the expectation for PMs is not going to be 'I tell someone to go and build something.' It's going to be 'you should go out and build it too.' There will need to be a lot more agency on their side. But the benefit is these AI tools will give them that capability. If you have a technical PM who understands code and can write code, they are even more deadly now than in the past. You don't need to give them a team of 10 people to prove out their idea. One thing I don't like about PMs nowadays is they spend so much time writing docs to convince the organization, but instead they should just build a version of what they want and prove it. Why spend time babying the organization playing Game of Thrones? It doesn't make sense in the future.

未来我们是否跳过了设计阶段，直接进入原型制作？

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

可能快速制作一个与公司设计一致的原型的能力会快得多。在内部，当我们构建应用时，如果应用可以很快构建出来，我们一开始不会去 Figma。显然，如果它关系到我们的核心产品体验，我们会设计布局并确保符合标准。但快速原型制作现在绝对可以跳过繁琐的设计阶段。

Probably the ability to quickly mock up a design consistent with your company's design and prototype it is going to be much faster. Internally, when we build apps, we don't go to Figma at the very beginning if the app can be built very fast. Obviously, if it's core to our product experience, we'll design the layout and make sure it's to our standards. But rapid prototyping can definitely skip a laborious design stage right now.

正如我们所说，你在中间遇到了 Lovable 和 Bolt，然后 Figma 现在也进来了，实际上是在说“嘿，把设计变成代码”，并且从外部介入。我想知道这种混乱局面在五年后会是什么样子，恕我直言。

As we said, you meet the Lovables and the Bolts in the middle and then the Figs are 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 five years time respectfully, you know.

是的，我认为这是个合理的问题。也许对于外部观察者来说，Lovable 和 Figma 所做的事情只是软件领域的一小部分。最终，大多数软件并不只是一个带有后端的网站。还有复杂的数据库系统、各种软件以及所有基础设施。Google 的大部分都不是前端。想想 Google 有多少工作要做。Google 可能是最复杂的技术之一。它有一个非常复杂的重新排序器，还有一个名为 Spanner 的数据库，这是一个地理一致性数据库，可能有数千万行代码。所有这些，公司内部没有人会用 Figma 来设计修改 Spanner 代码库。但我们希望他们能用 Windsurf 来做这件事。所以我们的看法是，我们不会一直坐着思考其他公司在做什么。我们思考的是软件工程师如何花费时间，以及如何让他们更高效。所以你说得完全正确，我认为设计阶段内部很多事情都会被颠覆。但我想补充一点，这可能只是软件开发者最终所做工作的冰山一角。

Yeah, I think it's a fair question. Maybe one thing is for people outside looking in, the things that Lovable and Figma do is like maybe a very small fraction of what software is. Ultimately, most software is not just a website with some backend attached to it. There are complex database systems, software out there, all of this infrastructure. Most of Google is not the front end. Think about how much work goes into Google. Google is probably one of the most complex pieces of technology. There's a very complex re-ranker. There's this database called Spanner, a geographically consistent database that's probably tens of millions of lines of code. And all of those things, there's no one designing something in Figma for modifying the Spanner codebase inside the company. But we would like it so that they're using Windsurf to actually go out and do that. So the way we look at it is we don't sit and think about what these other companies are doing all the time. We're thinking about what are all the ways software engineers spend their time and how do we make them much more efficient. So you're totally right that I think the design stage a lot of things are going to get disrupted inside. But maybe one point I just wanted to add is that's maybe just the tip of the iceberg on what a software developer ultimately does.

我也看了你的一些推文，你说异步远程智能体将会出现，我想先深入探讨一下。你能详细说明你的想法以及哪些任务会首先被自动化吗？

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

关于异步远程智能体的想法：如果你看像 Windsurf 这样的产品，它实际上是一个本地智能体，可以执行非常长时间运行的任务，比如将整个代码库从一个版本迁移到下一个版本，并且一旦你指示它，它应该能够做到这一点而无需你触碰键盘，这非常强大。但能够异步执行这个想法也非常强大。你可以想象从手机上发出指令，它为你生成一个拉取请求。但我认为在我们这个类别中构建产品的复杂性之一是，有三件事非常重要：延迟，即获得响应所需的时间；质量，即正确性；以及可纠正性，即你能多快做出修改。人们有点觉得如果技术真的很好，他们可以忽略这些事实，但这非常重要。如果你构建一个异步体验，需要 10、20、30 分钟甚至几个小时来构建一些东西，人们对输出的期望会非常高。你的质量必须非常高。如果质量不高，它最好容易纠正。但纠正并不容易。在人们构建软件的工作流程中，如果我在最后只创建一个 GitHub 上的拉取请求，这是人们审查代码的最终方式，即使其中 20%是错误的，更不用说 10%了。它必须至少 90%正确。人们说它需要 99%正确，我认为他们可能是对的，因为即使只有 10%是错误的，人们也会对产品失去信心，因为他们等了几个小时才得到结果，然后需要把它带回本地，修改一个 90%正确的东西并不容易，因为你还需要理解那 10%的错误，这也需要时间。那时你仍然受限于人类的时间。所以我的大致感觉是，异步远程完成的任务将是那些足够简单以至于能正确完成的任务。复杂的任务短期内仍然会在 Windsurf 中完成，因为复杂且需要大量快速迭代的事情，你不太可能异步进行，等 30 分钟，去 GitHub 上看，然后发现不正确再带回来。那时反馈循环太慢了。

So the idea of async remote agents: if you look at a product like Windsurf, Windsurf is actually a local agent that runs locally and it can do very long-running tasks, like 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, which is very powerful. But 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 there are three things that are really important: latency, how long it takes to get the response back; quality, what is the correctness; and correctability, how quickly can you make a change. People kind of feel like if the technology is really good, they can ignore these facts, but it's really important. If you build an asynchronous experience and it takes 10, 20, 30, maybe a couple hours to go out and build something, people's expectations on 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. In the workflow of how people build software, if all I do at the very end is create a pull request on GitHub, which is the final way people review the code, and even 20% of it is wrong, let alone 10%. It has to be at least 90% correct. People say 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 because they waited hours to get the result and they need to bring it back locally and modify something that is 90% correct is not that easy because you need to understand the 10% that is wrong, which takes time too. You're still human time-limited at that point. So my rough feeling is that what will be done asynchronously remotely are tasks that are so easy that it can actually get them done properly. Complex tasks are still going to get done in Windsurf in the short term, just because 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 look at it in GitHub, and then decide it's not correct and bring it back. The feedback loop is too slow at that point.

你发现用户对延迟的关心程度如何？

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

非常非常关心。我给你举个例子。即使是一个标签产品，10 毫秒——这个产品不仅提供自动补全，还在用户输入时提供自动重构——每 10 毫秒都会影响产品的接受率几个百分点。当我们考虑这些必须响应极快、必须可纠正的异步远程智能体时，它们采用什么形式？我们之前提到过，比如只是发送一条消息。你如何设想正确的形式以及需要什么？

Very very much. I'll give you an example. Even for a tab product, 10 milliseconds, which is the product that gives you not only autocomplete but automatic refactors as the user is typing, every 10 milliseconds affects percentage points in acceptance rate for the product. When we think about these async remote agents that have to be incredibly responsive, that have to be 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 that will take?

是的，我认为这不太明确。可能正确的形式是你需要从 IDE 中触发，因为人们在 IDE 中处于工作状态。现在的问题是，人们想从手机上触发任务的用例有多常见？如果确实如此，它是否可以在 Slack 上完成？人们是否想在手机上持续与某物对话？我认为答案可能是否定的，因为如果我收到数千行代码更改，我不知道如何在手机上有效地审查代码。在这种情况下，我不想在手机上反复与某物交互。所以也许我愿意在手机上做一次性交互，然后它最好 100%正确，然后我回到笔记本电脑上，确认它正确，然后盖章、批准并合并代码。所以这里有很多权衡。

Yeah, I think it's not super clear. It's possible that the right form factor is you need to fire this off from your IDE because people are in their work state in their IDE. Now, the question is how common is the use case that people want to fire things off from their mobile phone? And then 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. So maybe I'm game to do one-and-done interactions on my phone, and then it better be 100% correct, and I'll go back to my laptop and be like no it's correct and then stamp it and approve it and merge the code. So there are a lot of trade-offs here.

当我们谈论这些远程异步智能体的正确形式时，这让我想起了 Satya 说过的话，我确实记下来了，因为我想确保引用正确，不想错误引用 Satya，但他基本上说，显然应用程序将崩溃为智能体，并变成只有业务逻辑的数据库。你在这方面同意他吗？Salesforce 变成了一个智能体爬来爬去的数据库，HubSpot 也一样，你基本上把它们的效用价值降低到了只是数据库。

When we talk about the right form factor for these remote async agents, it kind of makes me think about something that Satya said, and I did write it down because I wanted to make sure that I got it right because I didn't want to misquote Satya, but he essentially said that obviously 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, a HubSpot the same, and you basically have their utility value reduced to just databases.

嗯，我在想为什么我觉得这不完全正确，但你说得对，任何公司的整个状态都可以归结为一个数据库。我不完全相信短期内像 Salesforce 和 Workday 这样的复杂应用会被另一家只建一个数据库并在其上运行智能体的公司完全取代。我认为很多复杂的工作流都是围绕使用 Salesforce 构建的。举个例子，当我们建立销售团队时，每个人都已经知道如何使用 Salesforce，现在我们又在 Salesforce 内部构建了自定义工作流。你说得对，这些都是数据库操作，但它们影响了人类使用软件的方式。我认为 Salesforce 不太可能被一家只有数据库和智能体的公司取代。构建这些复杂工作流的公司惯性太大了。最后一点：我认为现在的智能体还不够好，无法让它们直接在数据库上操作并自动写入，而无需人工监督任意工作流。目前，这些智能体大多只是从数据源读取，而不是大规模修改。这只是因为我们还不够信任这些系统。

Yeah, I mean I'm trying to think about why I think that's not exactly true, but you're totally right that for any company, their entire state could be distilled down to a database. I don't know if I completely buy that in the short term, these complex applications like Salesforce and Workday get completely 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. So, I'll give you an example. When we built our sales team, everyone already knows how to use Salesforce, and now we built custom workflows inside Salesforce. And you're right, those are all database transitions, but they affect the way humans operate with software. It's very unlikely to me that 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. And maybe here's the final piece: I don't think agents are good enough today that you can just let them operate on top of a database and write to the database automatically without human supervision for some arbitrary workflow. Right now we're still in the stage where these agents are mostly reading from data sources. They're not modifying things at scale. That's just because 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 care about today is agents. Do you think we are overly optimistic about where we are?

这可能是最明显的说法，但我认为人们认为这些系统比实际能力要强得多。很多投资者可能相信它们比今天更强大。举个例子，我不是要贬低什么，但我记得去年三月 Devin 发布时，每个人都对软件工程被取代的想法兴奋不已。一群投资者说，‘哦，再也没有理由雇佣初级开发人员了。你会拥有这个。’而现在我们离那还很远。当时，我们离用异步 AI 智能体取代初级开发人员还很远。但我认为人们不明白的是，即使技术还没到位，他们也没有意识到指数级改进的速度有多快。六个月后，这些模型的能力将与今天大不相同。人们很难理解这一点。就像我刚才说的，智能体很擅长大规模读取系统，但人们不信任它们大规模写入内部数据库。这可能在六个月内就会改变。八九个月前，人们还没有大量使用智能体。所以，是的，我认为人们低估了这些东西改进的速度。

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 about the idea of software engineering 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 now. At the time, we were very far from actually replacing a junior developer with an asynchronous AI agent. But I think what people don't understand is even if the technology is not there yet, they don't grasp how quickly the exponentials are improving. In six months, what these models are capable of is going to be very different from what is capable today. And it's very hard for people to understand that. Like what I just said about agents being really good at reading systems at scale, but people don't trust them to write to internal databases at scale. That will probably change in six months. Eight or nine months ago, people were not using agents a ton. So yeah, I think people underestimate the speed at which these things improve.

你认为 12 个月后，哪些我们今天没有的东西会变得疯狂？就像你说的，模型在这么短的时间内快速改进。如果想想我们今天认为疯狂的事情，12 个月后将成为现实，你认为会是什么？

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

我认为很多事情。也许我更了解软件开发领域。这些工具的发展方式会让人震惊。我认为现在最大的问题之一是这些工具主要帮助代码编写体验。它们没有帮助软件开发生命周期的许多不同方面：软件设计师设计软件、部署软件、审查软件、构建、导航、调试、测试，他们做很多不同的事情。之所以主要局限于一个或两个领域，是因为当你查看软件工程师在公司的工作时，他们会查看许多不同的数据源：日志系统、数据库等等。我认为这些智能体将能够访问所有这些数据，包括你的浏览器数据。然后，调试非常复杂的任务将成为可能。设计系统将成为这些智能体比今天提供更多杠杆的事情。我认为那种认为 AI 不会触及软件工程中某些太难的部分的想法是错误的。我认为每个方面都会变得高效 10 倍。

I think a lot of things. Maybe I understand the software development landscape a lot better. The way these tools are going to be will be shocking to people. I think right now one of the biggest problems is these tools 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, deploy software, review software, build, navigate, debug, test, they do a lot of different things. The reason why it's mostly been siloed to one or two areas is actually when you look at a software engineer's job at a company, they look at a lot of distinct data sources: a logging system, a database, all these other things. I think these agents are going to access all of this data, including your browser data. And 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 are today. And 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.

我能问一个很难的问题吗？你提到了 Devin。如果看看 Cursor，他们做对了什么让你学到了？你认为他们可能犯了什么错误让你学到了？

Can I ask you a really hard one? You mentioned Devin there. If you look at say a 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?

我不知道有什么错误，但我认为他们采取了非常好的方法来构建高质量的 UI/UX。这实际上证明了人们真的很喜欢。我认为他们能从一开始就做到这一点非常令人印象深刻。这其实不是我们最初的直觉。我认为他们执行得很好。

I don't know about a mistake, but I think for them, they took a really good approach on building high quality UI/UX. And that actually proved to be what people really loved. 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 they executed well.

你这是什么意思？你并没有把重要性放在最初的 UI/UX 无缝上。

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

是的，我认为对于我们来说，去构建 Windsor，我们实际上觉得我们需要一个巨大的技术突破，比如真正的新产品体验。我认为这是我们决定去构建自己的 IDE 的唯一原因。如果我们不这样做，我们不是那种仅仅为了默认更好的体验就去构建 UI/UX 的公司，除非我们有很好的技术。我喜欢把自己看作一家技术公司，我们发布产品是为了最大化用户能够高效消费的技术量。我们想要不损害人们体验我们产品的 UI/UX。

Yeah, I think for us to go out and build Windsor, we actually felt that we needed a massive technical breakthrough, like actually a new product experience. And I think that was the only reason why we decided to go out and build our own IDE. If we didn't do that, we're the type of company that would not just go out and build UI/UX for a much better experience by default unless we had great technology. I like to think of ourselves as a technology company, and we ship product to maximize the amount of technology that our users can consume productively. We want UI/UX that is not harming people's experience of our product.

你的客户体验质量在多大程度上取决于你创造的软件、UI、UX，而不是底层的模型进步，比如 OpenAI、Anthropic？

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 Open AI, Anthropic?

是的，我认为你不能低估后者的重要性。前沿模型的能力越来越强。每一项新能力都可能解锁过去无法实现的新产品体验。但我认为两者兼而有之。坦率地说，我们是第一个推出智能体式 IDE 体验的公司，也就是 Windsurf。我们绝对是第一个。现在这个想法已经成了共识，是显而易见的事情。但像 Sonnet 这样的模型已经存在了相当长一段时间，实际上我们花了不少功夫，利用这些模型以及我们内部的模型，结合 UI 打造出可用的体验，让人们能够快速审查所有软件，然后这个产品体验才真正起飞。所以我认为两者都有，但我不想低估模型对人们从这些体验中获得的价值的影响。

Yeah, I think you can't downplay the fact that the latter is very helpful. The frontier model is getting more and more capable. Every new capability unlocks maybe a new type of product experience that wasn't capable 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 consensus, it was the obvious thing to do. But these models like Sonnet had existed for quite a while, but it actually took us some work to put together using these models but also using our own models internally to make this a usable experience with the UI, to be able to review all the software very quickly before people actually this product experience took off. So 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.

人们经常将模型格局与云格局进行比较。我觉得这有点问题，因为云服务你通常会固定使用一家。你用了 AWS，就不会在 AWS、Google 和其他之间切换。你认为模型格局会在多大程度上像云一样，你与某个 AWS 或 Anthropic、OpenAI 建立优先关系，而不是实际上在多个模型提供商之间切换，根据不同功能选择不同模型？

People often compare the model landscape to the cloud landscape. The thing I find challenging about that is cloud you generally stick to. You're on AWS, you're not switching between AWS and Google and anyone else. To what extent do you think 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 you just work between many different model providers and you switch between them for different functions.

我认为你说得对。这个领域还很早期，所以这些类别的切换成本并不高。从一个模型提供商切换到另一个，最终切换成本很低。顺便说一句，这是因为这些模型大多没有状态。所以大多数情况下，这几乎就像 Twilio 的体验，你发送一条短信，但你可以用很多不同的应用发送短信。但我不认为这是个很大的缺点。我认为这意味着我们还在这个类别中演进。未来，你可以想象模型实际上可以在内部保存大量关于用户的状态，关于他们公司内部的所有数据，关于他们在本地使用的所有数据。如果你看看很多大型代码库，它们实际上有数十亿个 token 的代码。如果这是有状态的东西，你可以从特定的模型提供商那里注入和弹出上下文呢？我相信随着技术越来越好，他们肯定有办法提高切换成本。但我认为归根结底是这样的，Eric？在一个发展如此迅速、模型改进如此之快的类别中，过度投资于提高切换成本实际上对他们不利。这没有意义，因为假设他们这么做了，但他们错过了模型的下一个改进，比如他们没有做测试时计算之类的，他们就会落后，那么提高切换成本也就无关紧要了。所以我认为你与云提供商的类比目前并不准确。它们没有相同的属性。现在不是同一种业务。但未来会吗？我认为有可能。

I think you're right. The space is very early, which is why the switching cost of these categories is not very high. Moving from one model provider to the next has very low switching costs ultimately. And by the way, that's because there's no state in these models for the most part. So for the most part, it is almost like a Twilio-like experience where you send a text message, but maybe you could send text messages with a lot of different applications. But I don't take that as a big negative. I think what that means is 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 look at a lot of large code bases, they are actually getting to billions of tokens of code. What if that's 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. But I think this is what it comes down to, Eric? In a category that is evolving so quickly and when the models are improving so quickly, it is actually bad for them to overinvest in ways to increase switching costs. That just doesn't make sense because let's suppose they did that but they missed the next improvement in the model, like they didn't do test-time compute or something, they would be behind and then it wouldn't matter that they increased the switching cost. So I think ultimately your 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.

如今模型确实具有非商品化的特性。例如，Anthropic 通常被认为更适合开发者，这是最基本的。我们在多大程度上会看到完全的商品化？我的意思是，中国有 12、13 个不同的提供商，它们比以往任何时候都竞争得更快，并将达到某个渐近的效用点，所有模型都达到相同水平，我相信美国也会一样。我们在多大程度上会达到那种状态，还是说 Anthropic 是开发者的首选，X 是其他用途的首选？

Today models do have non-commoditized properties. Anthropic is often hailed as being better for developers for example, just as a most base one. To what extent do we actually see the complete commoditization? I mean there are literally 12, 13 different providers in China who are racing faster than ever and will reach some asymptotic utility point where all of them hit the same level, and I'm sure the US will be the same. To what extent do we hit that versus no, Anthropic is the one for developers, X is the one for whatever else.

我认为短期内，如果一个类别非常有价值，不太可能有一个模型提供商能在这个类别中独占鳌头。我认为这种情况不太可能发生。我确实相信缩放定律之类的东西，也就是说，规模越大，你就能构建出越来越好的模型，而如果你在这个类别中资本较少，你就会束手束脚。这就是目前游戏的本质。但我认为我们远未达到有人能成为定义性的领导者，拥有一个伟大的模型，而其他人在几年内都无法企及的地步。也许原因在于，六个月后如果出现新技术，而其他人发现了这项技术，他们最终能够以更高效的方式实现。如果他们能以更高效的方式实现，那就意味着如果你错过了，还在应用之前的技术，你就会落后。所以，几乎除非你相信某一家公司能获得世界上所有的资本，而其他人永远得不到，并且一家公司垄断了所有好主意，否则短期内不太可能有人能独占鳌头，这样说你能理解吗？

I think it is 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. Now I do believe in things like the scaling hypothesis, which is to say with more scale you are able to build better and better models, and you do have your hands tied if you're operating with less capital in the category. It's just the nature of the game right now. But I don't think we're anywhere near the point where you're going to have someone who is the defining leader of having a great model and no one else can touch it for years. And 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. And 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. So it's almost like unless you believe that one company is going to get all the capital in the world and no one else is ever going to get the capital in the world, and one company has a monopoly on all great ideas, it is unlikely that you're going to have someone that is able to run away with something in the short term, if that makes sense.

鉴于模型层的商品化以及没有人能独占鳌头，模型提供商在多大程度上必须进入应用层，才能在 API 方面实现某种形式的差异化？

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

我认为有很多方法可以为许多不同的应用构建更好的 API。这有点像你可以专注于你支持的应用。举个例子，假设你与像我们这样的公司合作，我们使用某个模型提供商。当我们输出代码时，可能很多代码看起来与现有代码相似，你可以从延迟角度进行优化，以帮助我们的工作负载，而不是针对图像的其他工作负载，这样你就能成为比另一家公司更好的供应商。所以，你可以在不同维度上实现专业化，以提供更好的体验。但正如你所见，这些模型公司实际上也在向应用层进军，无论他们觉得哪些应用有价值。所以我认为两者兼而有之。

I think there are lots of ways you can build better APIs for a lot of different applications. And it's kind of like maybe you can focus on the applications you do support. An example of this is like 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, and you can be a much better vendor to us than another company. So 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 are valuable to them. So I think you're seeing a little bit of both.

达里奥在某个活动上说，到 2026 年我们无疑会有单人十亿美元公司。你同意吗？

Dario was talking at some event and he said by 2026 we'll have solo billion-dollar companies without doubt. Do you agree?

不，我不相信。单人十亿美元公司意味着没人在乎。我们生活在有竞争的资本主义市场。如果你能一个人做成某事，除非你比别人聪明一千倍，否则两个和你一样聪明的人很可能实现你的想法，这会压缩你的利润、品牌和客户获取成本。一个人在没有持续投入的情况下很难做出十亿美元的产品。这暗示没人在乎，但你却神奇地成功了。

No, I don't believe in that. A solo billion-dollar company would imply no one else cares. We live in a capitalist market with competition. If you can do something with one person, unless you're a thousand times smarter, someone with two people as smart as you will probably do your idea, compressing your margins, brand, and customer acquisition cost. It seems very hard for a single person to run away with a billion-dollar product without continued investment. The implication is that no one else cares but magically you do well.

相信这一点的人错在哪里？

What do people who believe this get wrong?

我从来不明白单人建立十亿美元公司的想法。公司是未来现金流折现的总和。你需要人，或者如果 AI 好到不需要人，那你贡献了什么？而且其他人也能用同样的 AI，竞争压力更大。

I've never understood the idea of a single person building a billion-dollar company. A company is the sum of discounted cash flows over time. You'll need people, or if AI is so good you don't need people, then what are you contributing? And everyone else has access to the same AI, increasing competitive pressure.

你经历过多个商业周期。什么时候你最怀疑自己对它的热爱？有没有一段时期你并不受鼓舞？

You've been through multiple business cycles. When did you question your love for it most? Was there a period you were not inspired?

每次我们需要战略转型时，转型前是最焦虑的，因为你感觉可以做得更好却没有行动。当我们从 Exopunction 转向 Codium 时，转型后是我感觉最自由的，因为我已经接受我们可能会失败，但至少是在我们相信的事情上。最焦虑的是当我们相信可以做得更好，但惰性阻碍了我们。开始做正确的事，即使成功概率低，也是最自由的体验。

Every time we needed to make a strategic pivot, before the pivot is the most anxiety-inducing because you feel something could be much better but you aren't acting on it. When we pivoted from Exopunction to Codium, post-pivot was the freest I've ever felt because I had written off that we'd likely fail, but at least in something we believe in. The most anxiety-inducing is when we believe we could do much better but there's inertia preventing us. Starting to work on the right thing, even with low probability of success, is the most freeing experience.

你说你会等到在某个角色上快撑不住了才招人。但董事会成员通常提前六个月指出需要招聘。你怎么调和这两种看似矛盾的观点？

You said you wait until you're drowning in a role before hiring for it. But board members often highlight hires needed six months ahead. How do you reconcile these opposing ideas?

我们有案例表明那是一种反模式。在招聘销售副总裁之前，我们没有销售人员就签下了几个大企业客户。这向候选人证明了我们是一家很棒的公司。领域专家很厉害，但如果公司内部无法取得 1%或 10%的成果，那可能还不是招聘的时机。初创公司失败不是因为内部一团糟，而是因为没有把正确的事情做好。只要你做好了让产品成功的基本事项，就可以按需招聘。最糟的是招来一个人，第一天就不重要，然后他们自己制造工作。

We had cases where that's an anti-pattern. Before hiring our VP of sales, we closed some very large enterprises without any salespeople. That proved to the hire that we were an awesome company. Domain experts are awesome, but if you can't get 1% or 10% of the outcome inside the company, it's probably not the right time to hire. Startups don't fail because they look like messes inside; they fail because they don't do the right thing well enough. As long as you do the basic things to make your product successful, you can make hires as necessary. The worst thing is to hire someone who isn't important on day one and then they manufacture work.

在管理方面，你曾经相信什么，后来改变了看法？

What did you believe on management that you've changed your mind on?

我请来了朱利安，他在欧洲领导工作场所 10 年。我曾傲慢地以为读本书就能学会管理。但他从 15-20 年领导团队中带来的智慧和经验非常细致入微。我每天从他身上学到很多。这从书里学不到。我改变了看法。

I brought in Julian, who led workplace in Europe for 10 years. I arrogantly thought I could read a book and know how to manage people. But the wisdom and experience he brought from 15-20 years leading teams is so nuanced and granular. I learn so much from him 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?

也许我最大的观念转变就是你最初说的：团队规模并不等于产出。实际上，只有 ruthless focus（极致专注）才重要。你可以有很多人，但如果这些人没有极致专注于一件事，你会非常非常不成功。运营一个专注的公司，只有一件事重要，比运营一个同样营收但有五件重要事、五个不同优先级的公司要容易得多。回想起来，这总是显而易见的，但在像我们这样的初创公司，有太多事情可以做，总有一些光鲜亮丽的东西。你打开 Twitter，就会看到 X 解决了，Y 解决了，Z 解决了。但实际上，能够对事情说不，并专注于那件重要的事，让很多人一起极致优化它——这非常难。但当你真的做对了，就能创造奇迹。

Maybe the biggest change of mind I did have was what you originally said: how large your team is is not a function of output. Actually, ruthless focus is the only thing that matters. 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 not successful. It is much easier to run a company that is focused, that has only one thing that matters, than to run a company with the same amount of revenue with five things that matter, with five 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 shiny things. You can always open Twitter and it's like X is solved, Y is solved, Z is solved. But actually, being able to say no to things and to focus on the one thing that matters with many people and ruthlessly optimize that—it's very hard. But when you can actually get that right, you can make magic happen.

我可以和你聊一整天。我想来个快问快答，我有一些很棒的问题。我先从一个我加的问题开始。Neil Mehta，我很喜欢他作为大使，我也是大使。所以我看到的 Neil M 和你看到的不一样。作为创始人，你觉得他有什么特别之处？

I could talk to you all day. I do want to do a quickfire and I have some great quickfire questions for you. So, I'm going to start with one that I'm adding. Neil Mehta, I love him as an ambassador and I'm an ambassador. So I don't see the same Neil M that you see. What makes him so special for you as a founder?

我认为他分析公司的能力和智力上的灵活性非常出色。他对各种不同业务的知识广度，以及理解它们成功的原因、改进的方法以及如何应用到我们身上，这真的很棒。而且他非常慷慨地分享时间。你会以为，鉴于他与这么多公司合作，他不会有太多时间，但他对时间极其慷慨。

I think 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 to understand what makes them work, what are some of the ways they could improve and how that could be applicable to us, is actually very awesome. And he's a very kind person 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?

我其实很想让像 Scott Cook 这样的人加入我们的董事会。他是非常成功的软件公司的 CEO 兼创始人。我和他有过几次交谈，每次离开时都对竞争动态以及经营一家持久、长期成功的企业所需的条件有了深刻理解。

I actually 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 just what it takes to run a very enduring, long-term successful business.

老兄，这主意真棒。我以前没想过这个。

Dude, that is a great shout. I haven't had that before.

如果明天你必须把 Windf 开源，你会怎么想？你会做什么来取胜？

If you had to make Windf open source tomorrow, how would you feel and what would you do instead to win?

我认为如果必须开源，影响不会很大，因为大部分工作就像我之前说的。谷歌有前端，但前端只是一个框。如果他们把谷歌的前端开源，我不认为世界会有什么改变。那个框，它的用户体验，并不是什么大事。我知道 Copilot 这么做了，但我们的逻辑最终大部分在后端。所以我不认为会有太大变化。我也不认为它会改变我们产品的采用率。大部分差异化与前端是否开源无关。

I don't think it would affect much if we had to make it open source, because most of the work is kind of 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 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 actually open source or not.

你有一个 18 岁的兄弟姐妹，他们问你：我应该上大学吗？应该学什么？如何最好地为这个新的工作世界定位自己？你会给他们什么建议？

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?

专注于解决问题。如何分解问题？做一个高能动性的人。我认为计算机科学在很大程度上就是研究解决问题。所以也许重要的不是你学了 X 语言还是 Y 语言，而是你是否能把问题分解成不同的部分，并实际去执行。这可能是最重要的事情。

Just focus on problem solving. 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. So maybe what doesn't matter as much is did you learn X language or Y language, but can you break apart a problem into its distinct pieces and actually go out and execute on them? That is probably the most important thing.

你认为 OpenAI 做错的一件事是什么，你从中吸取了教训？

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

哦，也许是命名。我们就说命名吧。

Oh, maybe naming. Let's go with naming on that one.

你可以改变 CEO 生涯的一个方面。你最需要改变什么？

You can change one aspect of your CEOship. What do you need to change most?

我认为可能有一些细节我不应该深究，它们对公司的长期成功根本不重要，但我是一个很神经质的人，我喜欢了解内部发生的一切，比如我们在什么层面上花钱，这可能并不重要。我只是在脑子里浪费了本可以更好利用的精力。

I think there are probably some details I shouldn't be looking at very deeply that fundamentally don't matter about the long-term success of the company, but I'm a person that'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.

你可以因对人类的一个影响而被铭记。你希望后代说什么？Varun，我的祖父，他做了 X。

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

我认为我们公司的使命非常令人兴奋。我不说只是我，而是团队——我们希望将构建技术所需的时间减少 99%。如果我们能在未来如何实现这一点中发挥有意义的作用，我会非常兴奋。

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 are able to play a meaningful role in how that could shake out in the future, I would be extremely excited about that.

太棒了。听着，正如我所说，我从 Lee Murray、Neil 那里听到了很多。我非常期待这次访谈。你太棒了。非常感谢你忍受我基础的知识水平，我非常感激，老兄。

Brilliant. Listen, as I said, I heard so many things from Lee Murray, 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.