Building a magical AI code editor used by over 1m developers in 4 months: Inside Windsurf

发布时间 2025-04-20 11:00:07    来源
以下是翻译后的中文版本: Windsorf(前身为 Codium)的联合创始人兼首席执行官 Varun Mohan 讨论了他的公司从 GPU 基础设施提供商到领先的 AI 编码工具的演变过程。 四年前,Codium 最初专注于构建 GPU 虚拟化和编译器软件,旨在简化深度学习应用程序的开发。 尽管实现了数百万美元的收入并管理着数千个 GPU,但强大的生成式 AI 模型的出现导致了一次重要的重新评估。 Mohan 和他的团队意识到生成式 AI 将变得无处不在,因此转向构建 AI 驱动的编码应用程序。 他们认为,价值将从基础设施转移到应用层,在那里他们可以为开发人员创造更好的用户体验和工作流程。 这促使了 Codium 的诞生,这是一款免费的编码工具,集成到流行的 IDE 中,如 VS Code 和 JetBrains。 该公司后来扩展到企业解决方案,专注于为大型公司提供安全和个性化的产品。 现有 IDE(尤其是 VS Code)的局限性促使 Codium 开发了 Windsorf,它自己的 IDE,以充分利用 AI 的能力。 Mohan 认为,未来 AI 将编写超过 90% 的代码,从而将开发人员的角色转变为审查和改进 AI 生成的代码。 Windsorf 旨在提供定制的界面和审查流程,以适应这种新范式。 Windsorf 已经获得了显著的吸引力,在其推出后的四个月内吸引了超过一百万用户。 Mohan 强调了在 AI 领域保持敏捷性和适应性的重要性。 他强调需要不断挑战现有的假设,并在必要时愿意进行转型。 他鼓励初创公司的创始人对他们的想法既要“非理性地乐观”,又要“现实地批判”。 对话深入探讨了工程的未来,Mohan 预测将从编写代码转向优先考虑业务问题和做出技术决策。 虽然计算机科学学位因其解决问题的原则和对计算机系统的理解仍然具有价值,但他指出,“能动性”(agency)——独立构建解决方案的动力和主动性——变得越来越重要。 他分享了 Windsorf 独特的招聘方法,专注于寻找那些对公司使命充满热情并愿意努力工作的人。 他提倡“脱水式”的组织结构,即只有当现有团队真正不堪重负时才引入新员工。 这有助于实现无情的优先级排序,并防止产生不必要的工作。 Mohan 将 Windsorf 与竞争对手(如 Cursor)进行了对比,强调了 Windsorf 在理解大型代码库方面的优势,这得益于其与企业客户合作的经验。 Windsorf 对支持多种 IDE(包括 JetBrains)的承诺也使其与众不同。 企业级的安全性和合规性(如 FedRAMP)是其他的关键区别因素。 现场演示展示了 Windsorf 如何使用提供的图像将一个基本的 React 应用程序转换为一个狗狗 Airbnb 网站。 它演示了 IDE 如何分析代码、进行编辑并适应用户驱动的更改。 此外,Mohan 分享了使用该工具的技巧,包括保持耐心、具体描述和了解其功能。 该公司强调利用 AI 来加速工程效率,而不是取代工程师。 对于技术上限较高的公司来说,通过 AI 实现的效率提升甚至可以证明雇用更多工程师是合理的。 Mohan 最后强调了持续创新的重要性。 公司必须准备好每六到十二个月“蚕食”其现有产品,不断重塑自我以保持领先地位。 他鼓励个人积极尝试 AI 工具,并探索增强其生产力和贡献的新方法。 通过利用这些工具,人们可以成为其组织内的“力量倍增器”。

Varun Mohan, co-founder and CEO of Windsorf (formerly Codium), discusses the evolution of his company from a GPU infrastructure provider to a leading AI coding tool. Starting four years ago, Codium initially focused on building GPU virtualization and compiler software, aiming to simplify deep learning application development. Despite achieving millions in revenue and managing thousands of GPUs, the emergence of powerful generative AI models led to a critical reassessment. Recognizing that generative AI would become ubiquitous, Mohan and his team pivoted to building AI-powered coding applications. They believed that the value would shift from infrastructure to the application layer, where they could create better user experiences and workflows for developers. This led to the creation of Codium, a free coding tool integrated into popular IDEs like VS Code and JetBrains. The company later expanded to enterprise solutions, focusing on secure and personalized offerings for large corporations. The limitations of existing IDEs, particularly VS Code, led Codium to develop Windsorf, its own IDE, to fully leverage AI capabilities. Mohan believes that AI will write over 90% of the code in the future, shifting the developer's role towards reviewing and refining AI-generated code. Windsorf aims to provide a custom interface and review flows that cater to this new paradigm. Windsorf has gained significant traction, attracting over a million users within four months of its launch. Mohan stresses the importance of agility and adaptability in the AI landscape. He emphasizes the need to continuously challenge existing assumptions and be willing to pivot when necessary. He encourages startup founders to be both "irrationally optimistic" and "realistically critical" of their ideas. The conversation delves into the future of engineering, with Mohan predicting a shift from writing code to prioritizing business problems and making technical decisions. While a computer science degree remains valuable for its problem-solving principles and understanding of computer systems, he notes the increasing importance of "agency" – the drive and initiative to build solutions independently. He shares Windsorf's unique approach to hiring, focusing on finding individuals who are deeply passionate about the company's mission and willing to work hard. He advocates for a "dehydrated" organizational structure, where new hires are only brought in when the existing team is truly overwhelmed. This fosters ruthless prioritization and prevents the creation of unnecessary work. Mohan contrasts Windsorf with competitors like Cursor, highlighting Windsorf's strength in understanding large codebases, thanks to its experience working with enterprise clients. Windsorf's commitment to supporting multiple IDEs, including JetBrains, also sets it apart. Enterprise-grade security and compliance, such as FedRAMP, are other key differentiators. The live demo shows Windsorf transforming a basic React app into an Airbnb for dogs website using a provided image. It demonstrates how the IDE can analyze the code, make edits, and adapt to user-driven changes. Also, Mohan shared tips for using the tool, including being patient, being specific, and being aware of its capabilities. The company emphasizes leveraging AI to accelerate engineering productivity rather than replace engineers. For companies with high technology ceilings, the increased productivity achieved through AI can justify hiring even more engineers. Mohan concludes by emphasizing the importance of continuous innovation. Companies must be prepared to "cannibalize" their existing products every six to twelve months, constantly reinventing themselves to stay ahead. He encourages individuals to actively experiment with AI tools and explore new ways to enhance their productivity and contributions. By taking advantage of these tools, people can become "force multipliers" within their organizations.

摘要

Varun Mohan is the co-founder and CEO of Windsurf (formerly Codeium), an AI-powered development environment (IDE) that has ...

GPT-4正在为你翻译摘要中......

中英文字稿  

A lot of the bets we're making inside the company are for things that are not, you know, three, four weeks away. We should be cannibalizing the existing state of our product every six to twelve months. Every six to twelve months it should make our existing product look silly. It should almost make the form factor of existing product look dumb. How do you know when it's time to hire someone? I want the company to almost be like this dehydrated entity. Every hire is like a little bit of water and we only go back and hire someone when we're back to being dehydrated.
在公司内部,我们做出的很多决策并不是为了短期的三四周之后,而是着眼于更长远。我们的目标是每六到十二个月就对现有产品进行一次革新,让之前的产品看起来逊色。现有产品的形态应该显得过时。至于什么时候该招聘新员工,我希望公司的状态就像一个干涸的实体,只有在我们确实需要时,才去招聘,就像给这个干涸的实体加一点水。

Other skills you think people should be investing more in with the rise of AI building more and more of our products. The engineers are now able to produce more technology. The ROI of building technology has actually gone up. This actually means you hire more. The best thing to do is just get your hands dirty with all of these products. You could be a force multiplier to your organization in ways in which they never even anticipated.
随着人工智能在越来越多的产品中应用,你认为人们应该更多投资于哪些技能。工程师们现在能够生产出更多的技术,技术研发的投资回报率实际上是增加了。这意味着你需要更多地招聘人才。最好的做法就是亲自去体验和操作所有这些产品。你可以为你的组织带来前所未有的巨大发展动力。

Today my guest is Varun Mohan. Varun is the co-founder and CEO of Windsorf, which has quickly become one of people's favorite AI coding tools. It's basically the main competitor to cursor with over one million users four months in. In conversation, Varun shares what makes Windsorf unique. Why they decided to invest heavily in enterprise sales, very early in their history, why agency is going to be the most important skill for engineers and product builders to build.
今天我的嘉宾是Varun Mohan。Varun是Windsorf的联合创始人兼CEO。Windsorf迅速成为人们喜爱的AI编程工具之一,基本上是Cursor的主要竞争对手,在短短四个月内拥有超过一百万用户。在对话中,Varun分享了Windsorf的独特之处,他们为何在公司历史的早期阶段就决定大力投资企业销售,以及为什么主动性将成为工程师和产品开发者最重要的技能。

Also the story of how they started out as a GPU infrastructure company and realized there was a much bigger opportunity of the stack and the two pivots that got them to where they are today. He also gives a live demo advice for being successful Windsorf and so much more. There's so much to learn about where things are heading for engineers and product builders in general. In this conversation, I'm really excited to bring it to you. Thank you to everyone on LinkedIn and Twitter and my newsletter community for suggesting great questions to dig into with Varun.
这篇文章讲述了他们最初是如何作为一家GPU基础设施公司起步,并意识到在技术堆栈中有一个更大的机会,而进行了两次重大转型,从而达到今天的成就。他还提供了一个现场演示,分享了关于如何在Windsorf取得成功的建议,还有更多的内容可供学习。在这次对话中,我们可以了解到工程师和产品开发人员未来的发展方向。很高兴能将这次对话带给大家。感谢LinkedIn、Twitter上的朋友们以及关注我新闻通讯的社区,提供了很好的问题建议,让我们可以深入探讨与Varun的对话。

If you enjoy this podcast, don't forget to subscribe and follow it in your favorite podcasting app or YouTube. Also, if you become a yearly subscriber of my newsletter, you get a year free of perplexity pro, notion plus linear, granola and superhuman. Check it out at Lenny's newsletter.com. With that, I bring you Varun Mohan.
如果你喜欢这个播客,别忘了在你喜欢的播客应用或YouTube上订阅和关注。此外,如果你成为我新闻通讯的年度订阅者,你可以免费获得一年Perplexity Pro、Notion Plus Linear、Granola和Superhuman的使用权。请访问 Lenny's newsletter.com 查阅详情。现在,我为大家介绍 Varun Mohan。

This episode is brought to you by Brex. The financial stack used by one in every three US venture-backed startups. Brex knows that nearly 40% of startups fail because they run out of cash. So they build a banking experience that focuses on helping founders get more from every dollar. It's a stark difference from traditional banking options that leave a startup's cash sitting idle while chipping away at it with fees. To help founders protect cash and extend runway, Brex combined the best things about checking, treasury and FDIC insurance in one powerhouse account.
本节目由Brex赞助。Brex是美国每三个风险投资支持的初创企业中就有一个在使用的财务体系。Brex了解将近40%的初创企业因为资金耗尽而失败。因此,他们打造了一种全新的银行体验,专注于帮助创始人从每一美元中获得更多收益。这与传统银行选择形成鲜明对比,后者通常让初创公司的资金闲置,同时通过各种费用逐渐消耗资金。为了帮助创始人保护资金并延长资金使用时间,Brex将支票账户、资金管理以及FDIC保险的最佳功能结合在一个强大的账户中。

You can send and receive money worldwide at lightning speed. You can get 20X the standard FDIC protection through program banks. And you can earn industry-leading yield from your first dollar while still being able to access your funds anytime. To learn more, check out Brex at Brex.com slash banking dash solutions. That's BREX.com slash banking solutions.
您可以以闪电般的速度在全球范围内收发资金。通过合作银行,您可以获得相当于标准 FDIC 保护20倍的保障。从第一美元开始,您就可以获得行业领先的收益率,同时仍然可以随时访问您的资金。想了解更多信息,请访问Brex官网:Brex.com/banking-solutions。

This episode is brought to you by Product Board, the leading product management platform for the enterprise. For over 10 years, Product Board has helped customer-centric organizations like Zoom, Salesforce and Autodesk build the right products faster. And as an end-to-end platform, Product Board seamlessly supports all stages of the product development life cycle. From gathering customer insights, to planning a roadmap, to lining stakeholders, to earning customer buy-in, all with a single source of truth.
本集由Product Board赞助,这是一个面向企业的领先产品管理平台。十多年来,Product Board帮助了像Zoom、Salesforce和Autodesk这样以客户为中心的组织更快速地开发出合适的产品。作为一个端到端的平台,Product Board无缝支持产品开发生命周期的各个阶段。从收集客户洞察、规划路线图、协调利益相关者到赢得客户的认可,这一切都在一个可信的资源平台上完成。

And now, product leaders can get even more visibility into customer needs with Product Board pulse. A new voice of customer solution, built-in intelligence helps you analyze trends across all of your feedback, and then dive deeper by asking AI your follow-up questions. See how Product Board can help your team deliver higher impact products that solve real customer needs and advance your business goals. For a special offer and free 15-day trial, visit productboard.com slash Lenny. That's productboard.com slash LENNY.
现在,产品负责人可以通过Product Board Pulse更深入地了解客户需求。这个新的客户之声解决方案内置了智能分析功能,帮助你分析所有反馈中的趋势,并可以通过向AI提问进一步深入研究。了解Product Board如何帮助你的团队开发出更具影响力的产品,满足真实的客户需求并促进业务目标的实现。访问productboard.com/Lenny,获取特别优惠和15天免费试用。网址是productboard.com/LENNY。

Varun, thank you so much for being here and welcome to the podcast. Lenny, thanks for having me a long time listener. Oh, I really appreciate that. I'm so excited to have you here. I feel like just you guys have become this overnight success, which is definitely not an overnight success. But I feel like I've been hearing about Windsorf more and more as people's favorite AI tool. And I just don't think people know the story behind Windsor, behind Codium, the company that you built.
Varun,非常感谢你来到这里,欢迎参加我们的播客。Lenny,谢谢你邀请我,我一直以来都是节目的忠实听众。哦,我非常感激能够参与其中。我很高兴你能来。我觉得你们好像一夜之间就获得了成功,但实际上这绝不是一夜之间的成就。我最近越来越常听到人们提到Windsorf作为他们最喜欢的AI工具。我认为大家不太了解Windsor背后的故事,还有你创建的公司Codium。

So I thought it'd be good to maybe just start there. And have you just briefly shared the history of Codium and how Windsorf emerged out of Codium? Yeah, so the company was actually started close to four years ago. As you know, AI Coding was not a thing four years ago. Chat GPT was not out four years ago. At the time, we actually started out building GPU virtualization and compiler software. Right. Before this, I worked in autonomous vehicles, my co-founder, who had known since middle school, worked on ARVR at Meadow. And for us, we believed deep learning would touch many, many industries. It wouldn't just touch, like sort of autonomous vehicles with touch financial services, defense, healthcare. And we believed these applications were hard to build these deep learning applications. So we made it possible for you to effectively run these complex applications on computers without GPUs.
所以我觉得从这里开始会比较好。您可以简要分享一下Codium的历史,以及Windsor是如何从Codium中崛起的吗?好的,公司实际上是在大约四年前成立的。大家知道,四年前人工智能编程还不存在,Chat GPT也没有推出。当时,我们实际上是从构建GPU虚拟化和编译器软件开始的。在这之前,我在自动驾驶领域工作,而我的联合创始人,从中学就认识的朋友,则在Meadow工作,专注于AR/VR技术。对我们来说,我们相信深度学习会影响许多行业,不仅仅是自动驾驶汽车,还包括金融服务、国防、医疗保健等。我们认为这些深度学习应用程序很难构建,因此我们让您可以在没有GPU的计算机上有效运行这些复杂的应用程序。

And we would handle all the complexity of being able to actually run the workload on the GPUs for you. We were able to optimize these workloads a ton. And then the middle of 2022 rolled around. And we had a couple million in revenue. We were managing upwards of 10,000 sort of GPUs. We had eight people at the time. We were free cash flow positive. But I think what we felt was when once these generative models started to get very good, we sort of felt a lot of what we built was not as valuable. And this was like a very, very hard moment for us at the company. We were only eight people at the time. But we felt, hey, would people be training these very bespoke sentiment classifier models? Any more that were like very, very custom models for would they just ask GPTN is to say positive or negative sentiment? Probably is going to be the latter, right?
我们会帮您处理在GPU上运行工作负载的复杂性,并且成功地进行了大量优化。到了2022年中期,我们的收入已经达到了几百万美元,管理的GPU数量超过了10,000个。当时我们只有8名员工,现金流为正。然而,当这些生成模型开始表现出色时,我们感到自己所构建的许多东西似乎不再那么有价值了。对于我们公司来说,这是一个非常艰难的时刻。我们只有8个人,但我们意识到,人们是否还会去训练那些非常定制的情感分类器模型呢?还是他们会直接问GPT这样的模型来判断是积极还是消极的情感?可能会是后者吧,对吗?

And in a world in which everyone was going to run generative AI models, why would an infrastructure company be a differentiator? Because everyone is going to run the same kind of infrastructure down the one. So instead what we decided to do was we believe generative AI was almost going to be like the next internet. And in that case, what we should go out and do is build the next great apps like Google, like Amazon. And we vertical integrated and actually took our infrastructure or inference infrastructure to go out and build code at the time. And at that time, we were early adopters of GitHub co-pilot. And we thought the coding space was going to get tremendously disrupted in the next coming years. So we actually took our infrastructure.
在一个每个人都将运行生成式人工智能模型的世界中,为什么一个基础设施公司会成为差异化因素?因为大家将使用相同类型的基础设施。所以,我们决定采取另一种方法,我们相信生成式人工智能几乎会成为下一个互联网。在这种情况下,我们要做的就是创建下一个伟大的应用程序,比如谷歌和亚马逊。我们进行了垂直整合,实际上是利用我们的基础设施或推理基础设施来开发代码。在那时,我们是GitHub Copilot的早期采用者。我们认为在未来几年中,编码领域将会发生巨大的变革。因此,我们实际上利用了我们的基础设施。

We ran our own models and massive scale. We even trained our own models. In the very beginning, it was very, very simple as purely an autocomplete sort of model, right? Which basically means that as the user was typing, we'd complete the next one or two or three or four lines of code. But we provided the product entirely for free in all the IDEs that developers coded, right? That meant VS code, JetBrains, Eclipse, Visual Studio, VIM, EMAX. And the reason why we were able to build it for free was because of our infrastructure background. We were able to optimize these workloads a ton. And I guess very quickly after that, some large businesses also wanted to work with us. And we built out the kind of this enterprise motion to work with these large companies like Dell, JP, working Chase.
我们运行并大规模测试了我们自己的模型,甚至自行训练了这些模型。起初,这些模型非常简单,只是一个自动补全类型的模型。也就是说,当用户在输入代码时,我们会自动补全接下来的一到四行代码。而且,我们完全免费地在所有开发者使用的集成开发环境(IDE)中提供这个产品,包括VS Code、JetBrains、Eclipse、Visual Studio、VIM、EMACS。之所以能够免费提供这些服务,是因为我们在基础设施方面有很强的背景,能够大幅度优化这些工作负载。很快,一些大企业也愿意与我们合作,我们于是开发出了一套企业运行模式,来与这些大公司(如戴尔、摩根大通等)合作。

And for them, the bigger thing wasn't just, hey, could be autocomplete code or could we chat with the code base? It was, could you offer us a secure offering that was also personalized to all the private data inside the company. So we took our infrastructure and made it so that we invested a ton in making sure that we deeply understood these large companies' code bases. Right? And that's what we were working on until six months ago. And it's not that we've stopped working on that. But basically what we realized six months ago was we were getting limited by the IDEs that we were already working in. So VS code, which is a very popular ID, had a ceiling for the AI capabilities we could showcase our users.
对于他们来说,更重要的不仅仅是“可以自动补全代码”或“可以与代码库聊天”。他们需要的是一种既安全又能个性化处理公司内部所有私人数据的方案。因此,我们对我们的基础设施进行了调整,投入大量精力以确保我们能够深入理解这些大型公司的代码库。这就是我们六个月前一直在努力的事情。并不是说我们已经停止了这方面的工作,而是我们六个月前意识到,我们使用的集成开发环境(IDEs)限制了我们的发挥。在非常流行的VS Code这一IDE中,我们能向用户展示的AI功能达到了一个上限。

And because of that, we decided to go out and fork VS code and build our own ID with some of these new, agente capabilities. And over time, in the last couple of years, the model capabilities have also been growing exponentially year over year. That's sort of where we are right now. Like I skipped a lot of pieces there, but that's what we've blended. There's so many interesting threads there. One is just, there's always this question of just where value will accrue in AI. And it's so interesting you guys started almost at the bottom layer of infrastructure GPUs. And then you went to what people call GPC wrapper, not actually, but so I guess any, just like lessons there, just thoughts on just where you think value will end up in the world of AI and the stack of AI tools.
由于这个原因,我们决定对VS Code进行分叉,然后构建我们自己的集成开发环境(ID),并加入一些新的智能代理功能。在过去的几年中,模型的能力也在以每年成倍的速度增长。这就是我们目前所处的阶段。虽然我省略了很多细节,但这就是我们融入的内容。这里有很多有趣的线索,其中之一就是关于AI领域价值将积累在哪里的问题。你们从基础设施的底层——GPU开始,然后进入到了所谓的GPC包装器(虽然并非实际如此),这里面有很多值得分享的经验和思考,尤其是在AI世界和AI工具栈中,价值将最终流向何处。

Maybe I can start by just saying like one thing about startups that I think are like really true. It's very unlikely the first thing that you believe you should go work on is going to be the right thing, which is like a very hard thing to kind of wrangle with being a startup founder. Right. You need to kind of be irrationally optimistic that what you're going to do is going to be differentially important. Because otherwise, why would you go out and do what you're doing? And if it's obvious, then a bigger company would have already done it. Right. But then you also need to be really, really realistic because most ideas that are that are I guess non-conventional are usually bad ideas. Right. So it's this weird kind of tightrope you need to kind of balance on top of where you're kind of pushing for a future that you believe is true. But all the while you're getting new information, you need to kind of kill the beliefs that you had.
也许我可以从谈论我认为关于初创企业的一个非常真实的方面开始。作为创业者,你最初认为应该投入精力去做的事情,很可能不是正确的方向。这是一个很难处理的问题。你需要不切实际地乐观,坚信你要做的事情会与众不同并且重要。因为否则,你为什么要去做这件事情呢?如果事情是显而易见的,那么大公司早就已经做了。但同时,你也必须非常现实,因为大多数非传统的想法通常是糟糕的主意。这是一种奇怪的平衡,你需要在推动你相信的未来的同时,不断获取新信息,并且勇于放弃你原有的信念。

And if I were to start with the infrastructure piece, we first went in with the assumption that model architectures were going to be really, really heterogeneous. Working from an autonomous vehicle background, there were many different types of model architectures out there. There were convolutional neural networks, graph neural networks, recurrent neural networks, LSTMs, sort of lighter neural nets with frustram point networks. Right. And there were maybe like tens of architectures we were dealing with. And at that point, we were like, the complexity of this is so high that it's very clear if someone offloaded the complexity, there would be a lot of value. Fast word to the middle of 2023, everything looks like it's going to be a transformer. So now our hypotheses are just wrong. So at this point, then most of the value is probably not going to accrue at purely they at least this is our belief at the infrastructure layer. It's going to accrue somewhere else.
如果要从基础设施这部分开始谈,我们最初假设模型架构会非常多样化。在自动驾驶汽车领域,有许多不同类型的模型架构,比如卷积神经网络、图神经网络、递归神经网络、LSTM,还有比较轻量的神经网络和截锥点网络。当时我们可能处理了几十种架构,这种复杂性非常高,显然如果有人能简化这些复杂性,那将会很有价值。然而,到了2023年中期,一切都好像变成了Transformer架构。所以我们的假设现在显然是错误的。因此,我们认为大多数的价值可能不会仅仅体现在基础设施层面,它会出现在其他地方。

Where is the layer that you can actually differentiate on? And we believe the application layer is a very, very deep layer to go out and differentiate on. Right. What are the number of ways we can build better user experiences, better workflows for developers. We think there's effectively no ceiling on that on how much better we can make the lives of developers basically. You touched on the second thread that I thought was really interesting here is just how you guys pivoted from ideas that were working. Like you were making money. People loved it. You said you had millions of dollars of ARR revenue. And then you just like, no, we're going to completely change the business. So the question is just like, how do you, what have you learned about knowing with to follow and one thing I heard there that was really interesting is just once your assumptions change about that you built your idea on.
你可以在哪里真正实现差异化?我们相信应用层是一个可以深度开展差异化的层面。我们可以通过很多方式来构建更好的用户体验和更好的开发者工作流程。我们认为在这方面几乎没有上限,可以极大地改善开发者的生活。你提到的第二个话题也很有趣,就是你们如何从已经成功的业务中转型。你们当时业绩不错,客户也很喜欢,还实现了数百万美元的年度经常性收入。但你们却决定彻底改变业务模式。问题是,你们在如何判断需不需要坚持某个方向上学到了什么?一个很有趣的观点是,一旦支撑你们想法的假设发生变化。

It's time to rethink this idea and maybe try something else. You know, I think the way we sort of think about this is, you know, even when we're working right now, we just accept that we're going to get a lot of things wrong. We're just going to get a lot of things wrong. Obviously, that's a very big moment because that was a bet the company moment in the sense that we basically said to older investors, hey, we're making money on this. We had already raised 28 million dollars of capital. And we were just like, hey, we're just going to pivot entirely from this. And we did that overnight, right? This wasn't this thing where we just said, hey, maybe a quarter or one or two quarters because one of the things we knew that's very important for startups is focus.
是时候重新考虑这个想法,或许尝试一些其他的东西。你知道的,我觉得我们的思考方式是,即使我们现在正在工作,也接受我们会犯很多错误的事实。显然,这是一个非常重要的时刻,因为这对公司来说是一个关键决策的时刻。我们基本上跟之前的投资者说,我们在这个项目上赚钱了。我们已经筹集了2800万美元的资金,然后我们果断地完全转向另一个方向。我们是立刻行动的,不是说过一两个季度再决定,因为我们知道,专注对于初创公司来说非常重要。

And if you're, if you're trying to do another thing that you think is big and you're focused on something that you don't believe is valuable, your guarantee going to fail is the thing you think is going to be big. Right? So that's like a, that's a very obvious thing there. But I think once you go in with the assumption that a lot of your hypotheses are going to be wrong. But you will do the most concentrated work possible to go out and validate these hypotheses. And you won't be in love with your ideas. Like I think ideas, it's awesome when you have a great idea, but you should never be too in love with your ideas. And you have an organization that is very true seeking. I think a lot of people at the company have had their ideas tested over and over again.
如果你尝试去做一件你认为很大的事情,但同时却专注于一个你自己都不觉得有价值的东西,你注定会在这件你认为很大的事情上失败,对吧?这一点其实很明显。不过,我认为当你开始时,你就要做好思想准备:许多假设可能是错误的。然而,你需要尽可能集中精力去验证这些假设,并且不要对自己的想法过于迷恋。我觉得当你有一个好想法时,很棒,但你永远不要过于沉溺其中。你需要一个真正追求真相的组织。我认为公司的许多人都经历了多次的想法验证。

Even just building Windsor that is not a complete company pivot, but that's a big decision that we made at the company. You kind of need to make some bets and sometimes you're wrong and sometimes you're right. But if you have an organization that comes out and you feel like morale is not going to be low if you made the wrong decision. That that's the best, right? That means you have optionality for the rest of time. And Lenny, one thing that I try to tell the company about this is this year, the total amount of engineering output we'll have is much larger than that. And it's much larger than the engineering output we we've had since the beginning of the company's creation till now. So that almost means every year is a new lease on life for us, right? It's almost a new way for us to test out an entirely new set of hypotheses. And maybe we were wrong about our original hypotheses like in the in the first place. What what makes us more smart than everyone else to be right, you know, more times than that. That's so empowering.
即使只是创建Windsor,这并不算是公司完全的转型,但对公司来说,这已经是一个重大的决定。你需要进行一些赌注,有时候会错,有时候会对。但如果你的组织在做出错误决定时士气依然不低落,那就是最好的情况,对吧?这意味着你在未来始终保有选择的余地。此外,Lenny,我常常告诉公司的一点是,今年我们在工程上的总产出将大大增加,比公司创立以来到现在的所有工程产出加起来还要多。这几乎意味着每年都是我们的重生机会,这让我们可以测试一整套全新的假设。也许我们最初的假设本来就是错的,我们有什么理由一定比别人聪明呢?这种思维方式真是令人振奋。

It makes me think about or really Venus on the podcast, defender ways. And he has this phrase that he was on a shirt as book is called this fall in love with the problem, not the solution. And I feel like that's exactly what you're describing. Okay, so let's talk about Windsorff. What's the simplest way for people to understand what is Windsorff? Yeah, so Windsorff is an ID, right? It's an application to go out and build software and build applications. The crazy thing is a lot of people who use the product don't even probably know what an ID is, which is, which is crazy. And we'll get into that in a second. But why did we go out and build Windsorff? And what is Windsorff? Maybe. Why couldn't we have just done this on top of conventional IDs like Visual Studio Code? So maybe just to get into this a little bit, as we saw that AI was getting more and more powerful, the way people go out and build technology, we thought the interface for that was going to change remarkably.
这让我想起了维纳斯在播客中的一个观点,他提到的一个短语写在他的书《爱上问题,而不是解决方案》的衬衫上。我觉得这正是你所描述的。好了,让我们谈谈Windsorff。什么是让人们理解Windsorff最简单的方法?Windsorff是一个集成开发环境(IDE),它是一个用于开发软件和应用程序的工具。有趣的是,很多使用这个产品的人可能甚至不知道什么是IDE,这挺不可思议的,我们稍后会深入讨论这个点。但为什么我们要创建Windsorff呢?或者说Windsorff是什么?为什么我们不能基于像Visual Studio Code这样的传统IDE来实现这些呢?也许可以这样解释,当我们看到人工智能越来越强大时,我们觉得开发技术的方式、界面将会有显著的变化。

It was not going to be a conventional pure text editor where the user is writing a handful of lines of code or most of the code. And the IDE provides like maybe some basic feedback on what the user is doing right or wrong. And the basic feedback to be, hey, there's a bug in your software or a compiler error in your software. It could do much more, right? It could actually go out and modify large chunks of code. And one of the key pieces that we recognized was with this new paradigm with AI, AI was probably going to write well over 90% of the software, in which case the role of a developer and what they're doing in the IDE is maybe reviewing code. Maybe it's actually like a little bit different than what it is in the past. And we'll see this very soon with Windsorff.
这将不会是一个传统的纯文本编辑器,用户只是在其中编写几行代码或大部分代码。而且,IDE可能只会提供一些基本的反馈,告诉用户哪些地方做得对,哪些地方做错了,基本的反馈可能是你的软件中有一个错误或编译器错误。它可以做得更多,对吧?它实际上可以出去修改大段代码。我们认识到的一个关键点是,在这一新的人工智能范式下,人工智能可能会撰写超过90%的软件,这种情况下,开发者的角色可能会变成在IDE中审查代码。也许这与过去的做法有所不同。我们很快就会在Windsorff中看到这一点。

Maybe when you're using the product actually a good chunk of the user's time is actually reviewing what the AI is opening. So we need to build custom review flows into the IDE to actually make it so that it was easier to actually go out and do that right because the developer is not spending all their time writing code. And this is the fundamental premise on why we built the product. We thought we were going to get limited a ton if we had very, very basic UI out there. And I'll give you even a simple example here. We have this autocomplete product that completes a handful of lines of code. Now we've actually launched this offering called Windsorff tab that basically shows you refactors as well. And these refactors are almost in line refactors.
或许当你使用这个产品时,用户实际上会花大量时间来审核AI提供的内容。因此,我们需要在集成开发环境(IDE)中构建自定义审核流程,以便让这一过程更加简便,因为开发人员并不是将所有时间都花在编写代码上。这就是我们构建这个产品的基本原则。如果仅仅是非常基础的用户界面,我们认为会受到很多限制。我可以给你一个简单的例子:我们有一个可以自动补全几行代码的自动补全产品。现在,我们已经推出了一项名为Windsorff Tab的服务,它基本上也会展示重构建议,并且这些重构几乎是内联的重构。

And we were able to build a custom UI for that in Windsorff. But in VS code we needed to because of the access to the API is we needed to dynamically generate images right alongside the user's cursor because we just have access to the capabilities to showcase and edit properly. So what we realized is immediately by porting over to Windsorff our acceptance rate tripled. Same ML models, it just tripled. So what that I just gave us confidence in is, yeah, like you could argue technology is very important. And I think technology is very important. But if our users are getting very little value from the technology we're sort of building you need to really clarify maybe we do need to build a new surface and interface and that's what wind surface.
我们能够在 Windsorff 中为此构建一个自定义用户界面。但是在 VS Code 中,由于需要访问 API,我们需要动态生成图像,以便在用户光标旁边显示,因为我们具备展示和编辑能力。因此,我们意识到,一旦转移到 Windsorff,我们的接受率立即增加了三倍。使用相同的机器学习模型,只是三倍增加而已。这让我们确信,技术确实非常重要。当然,您可以说技术非常重要。但如果我们的用户从我们构建的技术中获得的价值很小,那么我们需要真正弄清楚,也许我们需要构建一个新的界面,这就是 Windsorff 的作用所在。

You took there just to make the super clear is you were initially working with an existing ideas that everyone is familiar with. And then it was like this isn't going to get us where we need to go. We're going to try to convince people to switch to something completely new because it's going to be so much better. It's our own ID. I think the I think maybe people may not recognize just how risky that is convincing engineers to use something completely new. That's a huge deal. Yeah, yeah, no, of course.
你这样做的目的是为了明确说明,你最初是基于大家都熟悉的现有理念来工作的。然而,后来发现这种方法无法达到我们的目标,于是决定尝试说服大家转向一种全新的东西,因为它会更好。这是我们自己的理念。我认为人们可能没有意识到,要说服工程师使用一个完全新的东西是多么冒险的一件事。这是个大事情。对,对,当然。

And one of the key key pieces that I just maybe Lenny that would be important to share is we a lot of our developers do use Visual Studio code. But there are lots of people that write in languages like Java, sort of C++ and so on and so forth. And they might use the jeopardy and family of IDs that are like IntelliJ. And for us, we're actually still committed to building on those platforms. Right. We just felt though that one of the dominant IDs, which was Visual Studio code was limiting the sort of user interface that we could give to our actual customers.
其中一个重要的方面,也许可以和 Lenny 分享一下,就是我们的许多开发人员确实使用 Visual Studio Code。但是也有很多人使用 Java、C++ 等语言,他们可能会使用像 IntelliJ 这样的开发环境系列。对于我们来说,我们仍然致力于在这些平台上进行开发。我们只是觉得,作为其中一个主要的开发环境,Visual Studio Code 在某种程度上限制了我们能够提供给客户的用户界面。

What is the current state of traction for Windsor fear all these crazy numbers about all the competitors in your space. What can you share there for folks just to know. Yeah, so maybe a handful we launched the product like a bit over four months ago. And in that period of time, over a million developers have tried the product and obviously we have many hundreds of thousands of monthly active users right now. I love how like these days like a million. No big deal. Like if it's just the numbers are absurd these days. Like we're just getting used to just 100 million are here. A million users in four months there. It's just like, oh, of course, how could you not have that. But that's absurd. It's just like an insane time right now.
当前温莎在市场中的竞争情况如何?如何看待这些对手的惊人数据?有哪些信息可以分享给大家?我们大约在四个多月前发布了产品。在这段时间里,有超过一百万名开发者尝试了我们的产品,并且现在我们每个月都有几十万的活跃用户。我喜欢现在的这种趋势,听到上百万用户都觉得理所当然。仿佛一亿用户就在哪里,上百万用户在四个月内尽在掌握。这确实让人觉得不可思议,现在真是一个惊人的时代。

You touched on something that I wanted to get you later, but it may as well bring it up now. The question of just how engineering will change in the future. You throw out the stat that like 90% of code is going to be written by AI in the future, Dario from the topic recently said the same thing. You guys have a really interesting glimpse into just how things will look in the future. So I guess the question just how do you think coding specifically will look in the next few years. How different will it be from today.
你提到了一件我本来打算稍后再问的话题,但我们不如现在就讨论吧。就是关于未来工程会如何变化的问题。你提到一个统计数据,说未来90%的代码将由人工智能编写,Dario最近也表达了类似的观点。你们对未来的情景有着非常有趣的洞察。所以我想问的是,你认为未来几年编程会是什么样子的?它与今天会有多大不同?

I think when we think about what is an engineer actually doing it probably falls into three buckets right. What should I solve for. How should I solve it and then solving it. And I guess like everyone who's working in this space is probably increasingly convinced that solving it, which is just the pure. I know how I'm going to do it and just going and doing it. AI is going to handle vast majority of not all of it. Right. In fact, it probably actually with some of the work that we've done in terms of deeply understanding code bases.
我认为,当我们思考工程师实际上在做什么时,大致可以分为三个部分:确定要解决的问题、选择解决问题的方法以及最后解决问题。我想,在这个领域工作的人可能越来越相信,解决问题这个部分,也就是当我们知道该怎么做然后去执行时,AI将会处理绝大多数,甚至可能是全部的工作。其实,基于我们对代码库的深入理解所做的一些工作,这个可能性更大。

How should I solve it is also windy it closer and closer to getting done. Right. If you deeply understand the environment inside an organization, if you deeply understand the code base, how you should solve it, give invest practices when the company also gets all. So I think what engineering kind of goes to is actually what you wanted engineers to do in the first place, which is what are the most important business problems that we do need to solve. What are the most important capabilities that we need our application or product to have.
如何解决这个问题?事情快要完成了。对吧。如果你深入理解一个组织内部的环境,并深入了解代码库,那么你就知道该如何解决这个问题,并给出投资的实践经验。当公司成熟时,我认为工程方面的重心实际上是你最初希望工程师们去做的事情,即我们需要解决的最重要的业务问题是哪些?我们需要我们的应用程序或产品具备哪些最重要的功能?

And actually going and prioritizing those and actually going and making the right technical decisions to go out and doing it. Right. And I think that's where engineering is probably heading towards now does that mean that no one needs a CS degree. I think I think that's maybe a little bit overplayed. A little bit just because, you know, maybe, maybe here's here's maybe my argument for that. A lot of developers nowadays that build full stack applications, at least until like a handful of years ago, they probably went to college and took an operating system course.
实际上,我们需要去优先考虑这些事情,并做出正确的技术决策来实施它们。我认为这可能是工程发展的趋势。那么,这是否意味着不再需要计算机科学学位呢?我觉得这个观点可能有点被夸大了。有一点是值得考虑的:很多现代的全栈开发人员,至少在几年前,他们可能上过大学,并且修过操作系统课程。

Right. In theory, they're not really like playing around with the operating system, like the kernel scheduler, like very frequently, but do those principles help them in understanding why their applications are slow. Do they help them in understanding why why some design decisions are better than the other. Yeah, that makes them a much better engineer than than another engineer. And I think that idea and the understanding of what's going on at the bottom will make a good engineer even better.
好的。从理论上讲,他们并不会经常去摆弄操作系统,比如内核调度程序之类的东西。但是这些原理是否能帮助他们理解为什么他们的应用程序变慢?能否帮助他们理解为什么有些设计决策比其他的更好?是的,这些确实让他们成为比其他工程师更优秀的工程师。我认为,这种想法和对底层工作原理的理解会让一个优秀的工程师变得更出色。

Right. But also the same time it empowers a bunch of people that never understood all those things. How to actually build as well, which is another remarkable sort of thing that fell out through this whole process. I don't know if you have kids, but just like say you had kids or you had knee certain FU going to college, let's say, would you suggest they do software, do computer science, or would you suggest like you're not going to have a good time if that's the career issues right now.
好的。但同时,这个过程也让一群从未理解过这些东西的人获得了力量。他们学会了如何实际去构建,这也是整个过程中出现的一个显著结果。我不知道你有没有孩子,但假设你有孩子,或者你有亲戚朋友要上大学,你会建议他们学习软件或计算机科学吗?或者你会说如果选择这个职业,现在可能不会有好时光。

Yeah, I think, you know, maybe I think back a little bit. So I went to MIT, a lot of us at the company went to MIT together on the engineering team. And I think like when I think about what we learn the most that I had on for engineering or computer science, it was not exactly like how do you write code. That's maybe that is like almost a given that you can you can kind of write code after going to college. It's more like the principles of how you think about a problem and how you break it down, right. And how you solve it in an interesting way.
我想,或许我可以稍微回忆一下。我曾就读于麻省理工学院,我们公司里工程团队的很多同事都曾在MIT一起学习过。我认为当我们回想在MIT学到的工程或计算机科学方面的知识时,最重要的并不是如何写代码。也许在大学毕业后会写代码是理所当然的。更关键的是,我们学到了解决问题的思维方式,如何把问题分解,以及如何用一种有趣的方式去解决问题。

So an example that of a class that I really enjoyed was our distributed systems class and there you're kind of reading through literature and understanding how some design decisions were kind of made. And I think it's more like a problem solving kind of course, right. And a major, it's a major of how you solve problems, given some constraints of how, you know, how computers today function, right. Like here's the speed at which memory sort of operates. Here's the speed at which you know, here's how much computation you can do in one one cycle or one second.
我非常喜欢的一门课是我们的分布式系统课。在这门课上,你会阅读一些文献,并理解某些设计决策是如何做出的。我认为这更像是一种解决问题的课程。它主要教你在一定的约束条件下,如何解决问题,比如今天的计算机是如何运行的。举例来说,这里是内存运作的速度,这里是每秒或者每个周期你可以进行的计算量。

And based on that, you can make some tradeoffs and solve a problem. So I don't know if if I would say that you shouldn't go get a computer science degree. I think computer science is almost synonymous with problem solving. In that case, I think it's pretty valuable is everything you learning your computer science degree useful. I'd say a lot of things that I learned in my computer science degree are not useful. I'll give you an example. I took a parallel computing class in Julia. And I don't think Julia is a very popular programming language anymore. Am I very sad that I took the class? No, the principles of parallel computing are still very useful.
基于这些,你可以进行一些权衡并解决问题。因此,我不敢肯定地说你不该去获取一个计算机科学学位。我认为计算机科学几乎和解决问题是同义的。在这种情况下,我认为它是非常有价值的。计算机科学学位中所学的一切都实用吗?我可以说我在计算机科学学位中学到的很多东西都不实用。我来举个例子,我曾在Julia语言中上过一门并行计算的课程,我认为Julia现在已经不是一个很流行的编程语言了。我为上了这门课而感到遗憾吗?并不感到遗憾,因为并行计算的原理仍然非常有用。

I would say today. So what I'm hearing is skills that you still want to build, whether it's computer science or maybe some version of computer science is kind of like building the mental model of how computers and systems work. Parallel processing, memory hard drives, Internet, things like okay. And then there's just like problem solving skills being able to solve interesting problems. Is there any other skills you think people should be investing more in with the rise of AI building more and more products?
我想说的是今天。因此,我听到的是,你们仍然希望培养的技能,无论是计算机科学或某种形式的计算机科学,都有点像构建计算机和系统工作原理的思维模型。比如并行处理、内存、硬盘、互联网等。然后就是解决问题的能力,能够解决有趣的问题。随着人工智能不断研发出更多产品,你认为还应该在哪些其他技能上投入更多?

I think one of the things that's maybe a little bit undervalued is this kind of agency piece. And I think about this a lot, which is, you know, you have a lot of people they could go through college and go through school. And they're basically told exactly what to do on a piece that and you know they're giving these very, very, I would say well defined paths that they need to take. And I think I think maybe in society and just school, we don't prioritize. How do you how do you make sure you get people with real agency that want to build something right.
我认为有一点可能被低估了,那就是人的自主性。对此我思考了很多,因为很多人在学校和大学都只是按照既定的道路前进,他们被明确告知要做什么。学校和社会给他们设定了非常清晰的路径。我觉得在这个过程中,我们并没有重视如何培养人们的自主性,好让他们真正想去创造一些东西。

Like their goal is not just to maybe graduate from college and then get a job at a big tech company where they're told exactly what to do or where to put the pixel on, you know, for this one website. And I think that's maybe a skill set that is undervalued. Just right now probably in the last, you know, maybe 10, 10 years or so. And I think that's going to be really, really important. You know, a skill for us for start up, obviously, these are skills that we just look for.
他们的目标并不仅仅是可能从大学毕业后找到一家大科技公司工作,在那里他们被告知要做什么,或者要为某个网站的像素放在哪里。我认为这种能力可能是被低估的,尤其是在过去的十年左右。而我认为这种能力将变得非常重要。对于我们这样的新兴公司来说,这些都是我们非常看重的技能。

We look for people that are really high agency because we just recognize that by default, if we don't innovate and do crazy things, we're going to die. The company is just going to die. So we just look for this, right. But I would say like for most software engineering jobs, that's probably not the case. Right. Just think about, you know, big company X and what they're hiring for on the average software engineering interview. It probably doesn't look like that.
我们寻找具备高度主动性的人,因为我们意识到,如果不进行创新和尝试一些疯狂的事情,公司就难以存续。公司最终可能会消亡。所以我们在招聘时特别看重这一点。然而,我要说,对于大多数软件工程职位来说,这可能并不是一个常见的要求。想象一下那些大公司在一般的软件工程面试中所招募的人才,可能并不需要具备这样的特质。

And I'm going to phrase that if we don't do crazy things and innovate, we're going to die. Yeah. That would be a great title for this podcast episode. And I think I know it's 100% true. There's just a lot of crazy things happening and a lot of innovation happening. And if you can't keep up, you will die. So let's talk about hiring. You have a really interesting approach to hiring. There's a few questions I have here.
如果我们不做一些疯狂的事情和进行创新,我们就会走向灭亡。是的,这可以成为这个播客节目的一个很好的标题。我确信这句话是完全正确的。现在有太多疯狂的事情在发生,同时也有大量的创新涌现。如果你不能跟上步伐,你就会被淘汰。那么让我们来谈谈招聘吧。你在招聘方面有一个非常有趣的方法,我有几个问题想问。

One is just how do you, I mean, you try to stay really lean. That's a common theme across all the AI start ups these days. How do you know when it's time to hire someone? I love the idea of being a lean company, but I don't idolize it in the way that hey, like it is a dream to be a 10% or 20% company that's making, you know, 50, 100, 200 million in revenue. That's like not, I think what we idolize inside the company.
一个问题是,你如何保持精简?在如今的所有人工智能初创公司中,这都是一个普遍的主题。你怎么知道什么时候该招聘新员工?我喜欢精简公司的理念,但我并不崇拜这种想法,就像把公司控制在10%或20%的规模,然后赚取五千万、一亿甚至两亿的收入。这并不是我们公司内部所崇拜的目标。

I think what we idolize is be the smallest company we can be to satisfy our ambitions. Right. That's what the goal is. And maybe the way I would sort of put that out there is. If I told you, hey, I'm going to build an autonomous vehicle. And I said our team is 10 people. You should rightfully say, Hey, Varun, you're not serious. And you'd be right. I'm not serious at that point.
我认为我们的理想是成为一个能满足我们抱负的小公司。对,这就是目标。或许我可以这样说,你想象一下,如果我告诉你:"嘿,我要造一辆自动驾驶汽车,我们的团队有10个人。"你可能会说:"嘿,Varun,你不是认真的。"你说得对,那时候我肯定不是认真的。

So I think the answer is, what is the minimum number of people to go out and build the crazy ambition project that you have. And I think the project we are trying to go out and do, which is completely transformed the way software gets built. We've mentioned this in the company. Our goal is to reduce the time it takes to build apps and technology by 99%. Right. It is a tremendously sort of ambitious goal.
所以,我认为问题的答案是,需要最少多少人来实现你们那个极富野心的项目。我们的目标是彻底改变软件开发的方式。在公司里,我们提到过这个目标:将开发应用和技术所需的时间缩短99%。这个目标非常雄心勃勃。

It's not possible for us to be a 10, 20, 30, 40 person engineering team in the long term and actually satisfy that goal. We think there's a very, very high ceiling. So that's maybe the first key piece there. It's like actually, you know, if we can crack actually being a fairly sizable company, but still operate as if we're a startup. That's the dream.
从长远来看,我们无法作为一个由10、20、30甚至40人组成的工程团队实际实现那个目标。我们认为这个目标的潜力非常非常大。这是其中一个关键点。理想的状态是,即便我们成为一家相当规模的公司,依然能像初创公司一样高效运作。那就是我们的梦想。

Right. That's that's the, that's the dream. In terms of hiring philosophy, the way we sort of think about things is we only hire for a role if we're actually underwater for that function. So let's say we're going on and building inference technology. Unless we are underwater there, we will not go out and hire hire someone to go on and work work for that. Right. And the reason for that is actually think this is like this is the, this is a feature. Right. When when you hire for a role and you already have enough people there, what you know, you get a lot of weird politics that ultimately ends up happening.
好的,这就是理想状态。关于招聘理念,我们的思考方式是,只有当某个职能真正紧缺时,我们才会招聘。因此,比如说我们正在开发推理技术,除非我们在这方面已经力不从心,否则不会去招聘新员工。之所以这样做,是因为我们认为这是一个优势。如果你在某个岗位上人员已经足够,还继续招人,就可能会引发很多奇怪的政治问题。

And it's not because people are bad people. I don't, I think most people are really well intention. But what happens when you have people that join a company and in reality, you didn't really need them. They will go out and manufacture some other thing that they should go work on. Right. They should they will go out and figure out something else to work on. And realistically, it's not that important, but they will go out and try to convince the rest of the organization that it is important.
这并不是因为人们本身不好。我认为大多数人的意图其实都是善意的。但问题是,当一些人加入公司,而实际上公司并不真正需要他们时,他们就会试图去创造一些他们认为应该工作的事情。他们会去找一些其他的事情来做。而实际上,这些事情可能并不那么重要,但他们仍会努力去说服组织里的其他人,让他们相信这些事情很重要。

Right. And I just think as a start of we don't have the bandwidth to go out and deal with that. Right. For me, I would like to see everyone just almost like to be like raising their hands of being like, I'm dying. Like we need we need one more person and that's when we got in and hire someone. And one of the analogies I like to give is we I want to the company to almost be like this dehydrated entity. Right. And every hire is like a little bit of water. Right. And we only go back and hire someone when we're when we're back to being dehydrated. I love this metaphor so much.
好的。我认为,我们目前没有精力去处理这个问题。对我来说,我希望看到每个人就好像在举手说,我快撑不住了,我们需要多一个人,这时候我们才会去招聘。我喜欢用一个比喻来形容,我希望公司就像一个缺水的实体,而每次招聘就像补充一点水分。只有当我们再次处于干涸状态时,我们才会去招聘。我非常喜欢这个比喻。

And it sounds it sounds painful. It sounds painful that you need to be underwater and raising your hand. I'm about to die and dehydrated. But I also know that it's a really exciting way to work. Like it sounds hard. But if you're in it, it's just like I just talk about just that side because I think it could sound like this is terrible. I don't want to work this way. You know what I actually think when he it's it's really good for a handful of reasons, which is that a lot of the we respect and trust the people that work at the company.
听起来似乎很痛苦。听起来很痛苦,因为你需要在水下举手。我快要死了,还脱水。但我也知道,这是一个非常刺激的工作方式。听起来很难,但如果你身处其中,我只是想谈谈这一方面,因为可能听起来很糟糕,让人不想这样工作。实际上,我认为这种方式有很多好处,我们非常尊重和信任公司的员工。

So this forces ruthless prioritization. You know, you have a team that's going out and doing something they will never ask to work on something that's not important. In fact, if there are two things that they're working on, they're just going to just tell me, hey, there are two things on the plate. I just don't have the ability to do to I can only do one. And they will pick the one that's most important. And this actually goes back to one thing that I think is true about startups and just companies in general.
这会迫使我们进行无情的优先排序。你知道,当你的团队在执行某项任务时,他们绝不会要求去做不重要的事情。事实上,如果他们手上有两项任务,他们会直接告诉我,“我们现在有两件事要做,但只能选择其中一个。”他们会选择最重要的那个。这其实反映了我认为关于创业公司甚至所有公司的一个普遍真理。

You don't win by doing, you know, 10 things kind of well. You win by doing like one thing really well. And maybe you fail nine things. This is the thing that I've told the company. This is very different than school, right. In school, you optimize for your total GPA. But for companies, I just need to get an A plus and the one class that matters. And then I can get an F and all the other classes. And an F and all the other classes doesn't mean you know being, you know, just doing illegal things that basically means you just deep prioritize things that don't matter.
你不会通过做十件事都做得还不错来取得成功。你是靠把一件事情做到非常出色来赢得成功的。可能你在其他九件事情上会失败。我告诉公司的是,这与学校的情况很不同。在学校,你需要优化整体的GPA,但在公司,我只需要在重要的那门课上拿到A+,其他的课就算拿F也没关系。这里拿F并不意味着你在做违法的事情,而是指把不重要的事情放在次要位置。

You know, that actually forces this organizational prioritization that is just really, really good. Right. And you know, Douglas and I Douglas being my co-founder, we can tell the company these are the two things that are the most important. And if we go out and tell these are the two things that are the most important to the company. And then we put the company has 20% more people than necessary. What is this? What's going to ultimately happen?
你知道,这实际上迫使组织进行优先级排序,这真的非常好。对吧。而且,你知道,道格拉斯和我——道格拉斯是我的联合创始人——可以告诉公司,这两件事情是最重要的。如果我们出去告诉大家这两件事情是公司最重要的,然后公司的人力资源超出需求20%,那么最终会发生什么呢?

Right. It's almost a forcing function for ruthless prioritization to have fewer people or people that just that are just underwater internally at the company. Everyone listening that works at a big company knows exactly what you mean when you describe when there's just too many people they were all fine work to do. And they will all be pitching ideas. You know, they all want to show impact they want to do well in their performance. Reaves. It is just the nature of too many people at a company.
好的。这几乎是一种强制机制,让公司内部人手更少或员工纷纷感到焦头烂额时,进行无情的优先排序。每一个在大公司工作的人都知道,当公司里人太多时,你在形容的是什么情况,这些人都在寻找要做的工作,并且不断提出各种想法。因为每个人都想展示自己的影响力,都希望在绩效考核中表现出色。这就是公司人太多时的本质。

And so I think this all really resonates to even getting even deeper on just what it looks like when someone's underwater to tell you it's time to hire. Is it just someone coming to you? Varune, we need I need someone on this team. This is just not possible. Like what does that look like even more practically. Yeah, I think it's basically along those lines. It's that there's some pressure to get something done in a short period of time.
所以我认为这一切都让人更深入地思考,当有人忙得不可开交时,他们来告诉你是时候雇人了,这具体是什么样子的呢?是否就是有人来找你说,"Varune,我们需要,我在这个团队上需要人手,这样下去是不行的。" 更实际一点来说,这看起来是什么样子呢?是的,我认为基本上就是这样,就是在短时间内有完成某件事的压力。

By the way, one of the things that we do believe though for software. If you want to do great things, it's not possible to just say, hey, I want to get it done in one month. If it is like because you have to think about it from this perspective, if a software project could get built in two to three weeks, what does that really mean about like the true complexity and differentiation of what you built? Like it's probably not very high unless you believe you are way smarter than everyone else, but I think that's hubris. Right. I think we actually have a very exceptional engineering team, but also at the same time, I don't think our engineering team is so exceptional that we can do things in three weeks that the rest of the world can't do in like six to nine months. That's kind of stupid to believe that.
顺便说一下,我们对于软件开发有一个信念:如果你想要做出伟大的作品,仅仅想着一个月内完成是不现实的。要从这个角度思考,如果一个软件项目能够在两到三周内完成,那这意味着你所构建的东西在真正的复杂性和差异化方面可能并不高,除非你认为自己比其他人聪明得多,但我认为那是一种自负。我确实认为我们有一个非常出色的工程团队,但同时,我也不认为我们的团队能在三周内做到其他团队需要六到九个月才能完成的事情。相信这一点是非常愚蠢的。

So I think basically comes down to that person coming out and being like, hey, look, like I don't have enough time to do X. I'm also having a conversation to be like, okay, what can you do then? And if the answer is I can only do less than that, then maybe we make a decision actually, oh, wow, that's great. Maybe we actually should deprioritize why? Because this is actually also another thing that's very hard, even for people like me and my co-founder, it's that we also want to do a lot of things, right? There's an urge to do a lot of things. But if you if we are forced to make a decision constantly on like we cannot do X, it's very clarifying. It's very clarifying because our engineering interview process is also like extremely low acceptance rate.
基本上,我觉得问题归结于那个人出来说,嘿,看,我没有足够的时间去做某件事。这时我会和对方沟通,问问他能做到什么。如果对方的回答是只能再减少,那么我们可能需要做出一个决定,可能会想,哇,这其实是个好机会,我们或许应该将某些事情的优先级降低。甚至对于我和我的联合创始人这样的管理者来说,这也是一件很难的事情,因为我们也常常想做很多事情。我们有一种想做很多事情的冲动。但如果我们被迫不断地做出决定,比如不能做某一件事时,这会让事情变得更清晰明了。因为我们的工程面试流程的通过率也非常低,所以必须慎重地选择优先事项。

So it's not very easy for us to very quickly spin up people and have them join the company really, really quickly either. So I think I think it's clarifying for everyone. It's clarifying for the person that wants more people. We can just tell them, hey, like look, we don't believe you should be doing this other thing. And it's also clarifying for us because we can also get on the same page with them, right? And sometimes we just kind of agree, hey, like our teams are very flexible that hey, actually we do need to get something done.
所以,我们很难快速招聘人员,让他们快速加入公司。因此,我认为这对每个人来说都是一种澄清。对于希望增加人员的人,我们可以直接告诉他们,我们不认为你应该去做其他事情。这对我们也有帮助,因为这样我们可以达成共识。有时我们会同意说,我们的团队其实很灵活,如果真的有必要,我们也确实需要完成某些事情。

And one of the things that we've kind of tried to make sure is true on our engineering team is people's value to the company does not have anything to do with the size of their team. There are projects inside the company. There are directly responsible individuals for these projects inside the company. And if we feel like one project is very important, then people can move from one project to the next. There's no notion of someone owning people at the company that is a very bad and gnarly idea. In fact, the person that is the most valuable at the company is the person that can do the most crazy sort of project out there with as few people as possible. And that's what you should be rewarding internally.
我们在工程团队中尽力保证的一件事是,公司员工的价值不应该与其团队规模挂钩。公司内部有许多项目,每个项目都有直接负责人。如果我们认为某个项目非常重要,员工可以在项目之间灵活调动。在公司里,没有人拥有“属下”的概念,这种想法非常不妥。实际上,公司里最有价值的人是那些能以最少的人手完成最具挑战性项目的人,这才是应该在内部给予奖励的。

How many people do you have at Cody at this point? So we have we have close to 160 people on the engineering team is over 50 people. Awesome. What is the other bigger functions? So we have go to market. We have a yeah. Oh, right. Okay. I want to talk about that. The sales learning that you guys had. Okay. Well, let's close out this hiring conversation. So we talked about what you look for to tell you the same to hire. What do you look for in the people that you interview and hire?
你们现在在Cody有多少人?我们大约有160人,工程团队有超过50人。太棒了!还有哪些重要的职能部门?我们有市场推广部门。哦,对了。我想谈谈你们在销售方面的学习。好的,那我们先结束招聘这部分的讨论。我们谈到了你们在招聘时看重哪些方面。你在面试和雇佣人时,看重哪些特质?

One of the key pieces that we look for we have a very high technical bar. So assuming that they actually need the technical bar. I think we sort of look for people that are really, really passionate about the mission of what we're actually trying to solve. And people that are willing to work very hard. I think one of the things that we don't try to do is convince people, hey, look, we are, you know, we're a very chill company and it's great to work here. I think no, this is a very exciting space. It's very competitive. You should expect us to lose if the people at the company are not, you know, kind of, they're not working very hard.
我们在招聘时非常看重技术实力,这是一项关键的考量标准。在满足技术要求的前提下,我们希望找到对公司使命充满热情的人,以及那些愿意努力工作的人。我们不会试图让大家觉得我们是一家轻松的公司、工作起来非常惬意。实际上,这是一个充满挑战和竞争的行业。如果公司里的员工不努力工作,我们很可能会失败。

And I think one of the biggest dog muscles I sort of hear is when I ask people like how hard are you willing to work? People actually ultimately say, hey, I work very smart. And I basically ask them a question. If we have many smart people at our company that also work hard, what's the differentiate are going to be? Are you just going to pull them down? Right. Because I think one of the things that's true about companies is it's like this massive group project. And I think the thing about a person that is is not pulling their weight that's bad is not it's not the productivity.
我认为一个常见的误解是,当我问人们“你愿意多努力工作”时,他们常常回答说自己工作很聪明。我通常会问他们一个问题:如果我们公司里有很多聪明又努力的人,那你的区别在哪里?你是否只是会拖他们的后腿呢?因为我认为关于公司的一个事实是,公司就像个大型团队项目。而对于不尽力的人来说,问题不在于他们的产出。

Right. At some point when the company becomes many hundreds of engineers, I'm not going to be thinking about the one engineer that's not pulling their weight. It's the team of people they work with that are almost basically saying, is this the bar internally at the company? Is this the expectation? And I guess Lenny, if I told you you have a team of five people and, you know, the four other people you're working with just don't care. How much are you going to feel like you should care? Not too much. Exactly. So for us, for us, I think that's what we more care about. Right. We have a culture where it's like it's very collaborative. It's it's not an individual sport, but people feel like they can rely on other people to get complex sort of tasks done.
好的。当公司拥有几百名工程师时,我不会只关注一个贡献不够的工程师。考虑到他们所在的团队,他们几乎会说:“这就是公司内部的标准吗?这是我们的期望吗?” 我打个比方,如果告诉你,你所在的团队有五个人,而另外四个同事都不在乎,那么你会觉得有多大动力去在乎呢?大概不会有太大的动力,对吧?所以对我们来说,我们更关注的是这种氛围。我们有一种非常注重协作的文化,这不是一个个人秀场,而是大家感觉可以依靠其他人共同完成复杂任务的工作环境。

So the question you asked there just basically is how hard are you willing to work? How hard do you want to work? And I know some people there, there's a whole group of folks that are just like work like balance. I don't want to how dare you ask me to work crazy hours. And I love just the filter of front of if you work here, you will work really hard work work work a lot of hours. It's a crazy. It's a crazy space to be in and we will win by working smart and also really hard. Yeah.
所以你刚才提到的问题其实可以简化为:你愿意多努力工作?你想付出多少辛苦?我知道有些人注重工作与生活的平衡,不愿意接受工作时间过长的要求。他们可能会觉得被要求疯狂加班是不可接受的。我很喜欢这种直截了当的表达:如果你选择在这里工作,你就需要非常努力地工作,而且常常需要长时间地工作。这是一个很疯狂的环境,我们将通过聪明地工作和非常努力地工作来赢得胜利。

You said at some point earlier that your engineering pass rate is you said it was like 0.6% of candidates. I'm like that. Yeah, it's probably posted at take home. It's probably that actually so the take home itself filters probably another 10 15 X on top of that. Here's a question that I've been hearing more and more is just how do you do interviews these days with tools like we'd serve that solve all your problems. We're okay with people using the tools because I think one of the worst things is like if someone comes here and doesn't like using these tools like we believe they're massive productivity improvements. We do bring people like into the company like on site so we can actually like see how they think through problems on a on a white board and all these other pieces.
你之前提到过,你们工程岗位的通过率大概是0.6%。就这个样子,对吧?可能这个比例是在考核作业之后的,通过考核作业后,这大概还要再过滤掉10到15倍的人。有个问题我最近听到得越来越多:在有那些能够解决所有问题的工具的情况下,你们现在是怎么进行面试的?我们对使用这些工具的求职者没有问题,因为我们认为,拒绝使用这些工具可能是件很糟糕的事情,因为它们能极大地提高生产力。我们确实会邀请求职者来到公司现场面试,以便我们能真正了解他们如何在白板测试和其他环节中解决问题。

So so we do want to see how they think on their feet and hopefully they're not just like taking what we're saying putting in a voice translator and sticking it into chat to be seeing the answer up. So there is a way to do this. My viewpoint on this is is the tools are really really important but I do think we still look for some problem solving ability. Right, like if the only way you can solve a hard problem is like put it into chat to you. I think I think that's like a concern to us.
所以,我们确实希望看到他们在快速反应情况下的思维方式,希望他们不是简单地把我们说的内容放进语音翻译器,然后再粘贴到聊天软件里找答案。因此,我们有一种方法来应对这种情况。我的观点是,这些工具确实非常重要,但我认为我们仍然看重一定的解决问题的能力。换句话说,如果他们只能通过在聊天工具中查询来解决难题,那对我们来说是个问题。

Today's episode is brought to you by Coda. I personally use Coda every single day to manage my podcast and also to management community. So I put the questions that I plan to ask every guest that's coming on the podcast. So I put my community resources. It's how I manage my workflows. Here's how Coda can help you imagine starting a project at work and your vision is clear. You know exactly who's doing what and where to find the data that you need to do your part. In fact, you don't have to waste time searching for anything because everything your team needs from project trackers and OKRs to documents and spreadsheets lives in one tab all in Coda.
今天的节目由 Coda 提供赞助。我个人每天都使用 Coda 来管理我的播客和社区。我会把计划问每位来宾的问题放在里面,也把社区资源整理在一起,这就是我管理工作流程的方式。Coda 可以这样帮助你:想象一下,在工作中开始一个项目,你的目标很明确,你知道谁在负责什么,需要的数据在哪里可以找到。实际上,你无需浪费时间去搜索任何东西,因为你团队需要的一切,从项目追踪、OKR到文档和电子表格,都汇总在 Coda 的一个标签页中。

With Coda's collaborative all in one workspace you get the flexibility of docs, the structure of spreadsheets, the power of applications, and the intelligence of AI. All in one easy to organize tab. Like I mentioned earlier, I use Coda every single day and more than 50,000 teams trust Coda to keep them more aligned and focused. If you're a startup team looking to increase alignment and agility, Coda can help you move from planning to execution in record time. To try it for yourself, go to Coda.io slash Lenny today and get six months free of the team plan for startups. That's C-O-D-A.io slash Lenny to get started for free and get six months of the team plan. Coda.io slash Lenny.
使用Coda的协作一体化工作空间,您可以享受到文档的灵活性、电子表格的结构、应用程序的强大功能以及人工智能的智能化。所有这些功能都集中在一个易于组织的标签页中。正如我之前提到的,我每天都在使用Coda,并且有超过50,000个团队信任Coda来帮助他们保持更好的一致性和专注力。如果您是一个希望提高一致性和敏捷性的初创团队,Coda可以帮助您在创纪录的时间内从计划到执行。要亲自体验,请访问Coda.io/Lenny,您将获得6个月的初创团队计划免费试用。就是C-O-D-A.io/Lenny,免费开始并获得6个月的团队计划。Coda.io/Lenny。

OK, let's talk about this good market sales experience you guys have. We started without, obviously, like most people started building without sales team and then you realized from what I hear that that was a huge mess and a big opportunity to talk about there because that's really unique I think. You guys have a large sales team and go to market team. Yeah, we actually made this decision pretty early in the company's history I would say. Like we hired our VP of sales over a year ago actually and the go to market team is now over 80 people inside the company.
好的,我们来谈谈你们这段良好的市场销售经验吧。像大多数公司一样,我们一开始没有销售团队,然后,很明显,你们意识到这是一个巨大的混乱局面,也发现了其中蕴藏的巨大机会,这点我觉得很独特。你们现在有一个庞大的销售团队和市场团队。事实上,我会说,我们在公司成立初期就做出了这个决定。在一年多前,我们就聘请了一位销售副总裁,现在公司的市场团队已经有80多人了。

Yeah, maybe a little bit of a backstory here. So when we started the company, actually we had a handful of angels that actually were operators go to market operators. So an example of one was Carlos Dela Torre who used to be the CEO of MongoDB. And I think for us, we never viewed enterprise sales and sales as like a very negative thing. I think this is like an interesting thing that technical founders sometimes don't really like. They think sales is like a very negative sort of part of the process. Everything should be product and growth. And I think it's not that black and white like I think enterprise sales is really valuable.
当然,这里需要一点背景介绍。当我们创办这家公司时,我们实际上有一些天使投资人,他们实际上是负责市场运营的。例如,Carlos Dela Torre,他曾是MongoDB的CEO。对我们而言,我们从未将企业销售和销售视为一种非常负面的事情。我认为这是一个技术创始人有时不太喜欢的有趣观点。他们认为销售是一个过程中的负面部分,认为一切都应该依靠产品和增长。我认为情况不是那么非黑即白,我认为企业销售是非常有价值的。

But maybe when we were a GP virtualization company and we were an infrastructure company, the reason why we never hired a salesperson is I didn't know how to scale the function. I was the one who was selling the product. So ultimately speaking, if it was hard for me to sell the product incrementally, I didn't know how we could make that into a process that we could then go and scale. If I couldn't do one, I didn't know how we could take the revenue of the business from a couple million to hundreds of millions. And I let alone even tens. So if I didn't know how to do that, how could I go out and hire someone and make them scale it out?
也许当我们是一个GP虚拟化公司和一个基础设施公司的时候,我们从未招聘销售人员的原因是我不知道如何扩大这个职能。我是那个销售产品的人。所以说到底,如果我自己都很难逐步提高产品的销售量,那么我不知道我们如何能将其转变为一个可以扩展的过程。如果我一个人都做不到,我不知道该如何将公司的收入从几百万提高到数亿,甚至数十亿。所以如果我不知道怎么做,我又怎么能出去招聘一个人,并让他们去扩大这个业务呢?

On the other hand, for code, very quickly, a lot of large enterprises sort of reached out to us. And from that alone in the middle of sort of 2023, we started, I guess me and a handful of other folks at the company started selling the product. And we were doing tens of pilots concurrently with large enterprises. And we were very quickly able to understand that there was a large enterprise motion that needed to be built in this space. So by the end of 2023, we actually hired our VP of sales and very quickly after that scaled sales team. And yeah, I mean, look, if you want to sell to the Fortune 500, it is very hard to do that purely by swiping a credit card.
另一方面,对于代码方面的问题,很快就有很多大型企业主动联系到我们。从2023年年中开始,我和公司里的几个人就开始销售这款产品。我们同时与多家大型企业进行试点项目,很快就意识到需要在这个领域建立一个面向大型企业的业务架构。因此,到2023年底,我们正式聘请了一位销售副总裁,并且很快扩展了销售团队。是的,如果你想向《财富》500强企业推销产品,仅仅依靠刷信用卡是很难做到的。

Let's talk about cursor. I don't want to spend too much time on competitors, but that's what everyone's always thinking about when they think of you guys. You guys are kind of the leading players, I think, in the space. Also, there's co-pilot, but that's different. So what's the simplest way to understand how you guys are different from cursor and also just how you think you win in the space long term. So I think maybe, maybe a handful of things that I could share. So on the products side, I think we've invested a lot in making sure code based understanding for very large code bases is really high quality. And that's just because of where we started, right?
我们来聊聊Cursor。我不想花太多时间谈论竞争对手,但每个人在想到你们的时候,总是会想到他们。我觉得你们其实是在这个领域的领导者。当然,还有一种叫做"co-pilot"的东西,但那是不同的。那么,最简单的方式来理解你们与Cursor的区别是什么,同时你们认为在这个领域长期获胜的策略是什么? 关于产品方面,我觉得我们投入了很多精力确保对大型代码库的理解达到很高的质量。这实际上与我们最初的起点有关,对吧?

We work with some of the world's largest companies like Dell, JP MarketJays. Companies like Dell have singular code bases that are over 100 million lines of code, right? So being able to understand that really, really quickly to make large-scale changes is something that we've spent a lot of time doing. And that requires us like actually building our own models that can consume large chunks of their code base in parallel across thousands of GPUs and almost rank them to be able to find out what the most important sort of snippets of code are for any question that are asked about the code base. Right.
我们与像戴尔(Dell)和JP MarketJays这样的全球大型公司合作。像戴尔这样的公司,其代码库超过一亿行,对吧?因此,能够快速理解这些代码并进行大规模的调整,是我们花费大量时间研究的内容。这需要我们建立自己的模型,能够在成千上万的GPU上并行处理这些代码库的大量部分,并对它们进行排序,以找出在代码库中回答任何问题时最重要的代码片段。对吧。

So we've gone out and built large distributed systems based on infrastructure background to go out and do that. That's maybe one. Let me actually follow that thread because I think people may miss under estimate just how big of a deal that is. So when we talk about we had the founders of Bolt and lovable on the podcast. So those products, they built something from scratch. They built, they write the code for you. So that versus just loading say Windsorf on your million flying code base say it or being the Aruba like it understanding what the hell you have and how works and where to go change things without breaking it is insanely hard.
我们已经开发了基于基础设施的大规模分布式系统来实现这一目标。这可能只是其中之一。我想继续谈谈这个话题,因为我觉得很多人可能低估了这件事的重要性。例如,当我们在播客中和Bolt以及Lovable的创始人交谈时,他们开发的产品是完全从头开始构建的。他们为你编写代码。相比之下,把类似Windsorf的软件加载到你庞大的代码库中,或者像Aruba那样弄清楚你已有的系统运作模式、了解它如何运行,并在不破坏的情况下更改那些地方,这是非常困难的任务。

And so what I'm hearing is that's kind of a big differentiators. You guys started there actually. And then Windsorf is now building up that advantage. That's right. Yeah. So we that's like a big thing that we spent a lot of time on, which is just understanding sort of what the what the code base is doing. And actually like one of the other things is what are all the user interactions with respect to the code base and happy to show that also in a bit here. Awesome.
所以我听到的重点是,这是一个非常大的区别点。你们最初就是从这个方面着手的,而现在Windsorf正在巩固这种优势。没错。我们花了很多时间在这上面,主要是理解代码库的运作方式。另外,还有用户与代码库的所有交互关系,我们也很乐意稍后展示一下。太好了。

The second key piece probably is we're not only tied to the to Windsorf actually this is probably like a weird statement given even we are talking about Windsorf, which is that actually we're pretty focused on supporting ideas like Jetrix. Right. You know, JetRains or IntelliJ has over 70 to 80% of all Java developers code in in JetRains based IDs. Right. The reason why we don't feel as big a need to almost build a competing product to JetRains is JetRains is actually a very sort of extensible product in a way that the S code is not.
第二个关键点可能是我们不仅仅与Windsorf有关,尽管我们正谈论Windsorf,这听起来可能有点奇怪。实际上,我们非常专注于支持像Jetrix这样的想法。你知道的,JetBrains或IntelliJ的开发环境中,有超过70%到80%的Java开发者在使用JetBrains的工具。我们觉得没必要去开发一个与JetBrains竞争的产品,因为JetBrains的产品非常具有可扩展性,而S代码则没有。

The S code is not very extensible. So I think for us our goal here is not only just to satisfy a subset of users that can actually switch on to our ID. But we want to give this agent experience to every developer out there. And if that means there are Java developers that write in JetRains, that's fine. We work with a large lot of large enterprises that have 10 plus thousand developers were over 50% of the developers are on JetRains. Right. It's a very large large product. And by the way, that company itself is a privately held company that makes many hundreds of millions of dollars a year. Right. So it's a very, very large company.
S代码的可扩展性不强。因此,我认为我们的目标不仅是满足能够转向我们集成开发环境的一部分用户。我们希望为每位开发者提供这种代理体验。如果这意味着有Java开发者在使用JetRains,那也没问题。我们与许多大型企业合作,这些企业有超过一万名开发者,其中50%以上的开发者都在使用JetRains。这是一个非常庞大的产品。顺便提一下,那家公司本身是一家私人控股公司,每年赚取数亿美元。因此,这家公司非常非常大。

So for us, that's another key piece. We actually like want to meet developers sort of where they are. And if they if they use a different platform, we'll work on that too. The third key piece and this probably sounds in other key piece for enterprises is we work in like a lot of very secure environment. Right. We have fed RAM compliance. Right. We have which means we can sell to like very large government and these.
对于我们来说,这是另一个关键点。我们实际上希望能在开发者所在的平台上与他们对接。如果他们使用不同的平台,我们也会为此进行调整。第三个关键点是,尤其对于企业来说,我们在许多非常安全的环境中工作。我们符合联邦风险及授权管理计划(fedRAMP)的合规要求,这意味着我们能够向非常大型的政府组织等出售我们的产品。

We have a hybrid mode of actually using the product, which means that all the code that lives that is like indexed actually lives on the tenant of the user. Right. Code is one of the most important IP pieces of IP for the company. So I think just if you were to look at it from like a big company perspective, there are many reasons why like over the years of just like building an enterprise product. We've handled a lot of complexities that large companies want to see. But that's part of it is because of the history of how we got here in the first place.
我们采用了一种混合模式来使用该产品,这意味着所有被索引的代码实际上存储在用户的租户中。代码是公司最重要的知识产权之一。因此,从大公司的角度来看,多年来我们在构建企业产品时处理了许多复杂的需求。这是因为我们的发展历程使我们今天能够提供这样的功能。

Okay, everyone enough teasing. Let's do a live demo of when surfs of folks can see what it's like and then I'm just going to ask you a bunch of questions as we're going through it. So I'll let you pull up a little shared screen where you have when surf pulled up. Great. So some context. This is a very basic react project. There's nothing in it right now. So if you were to open any sort of files, it's the default react app project. And I have this basic image here. You can pass windsurf images of what you'd like the project to kind of look like of what I would like an Airbnb for dogs website to kind of look like beautiful, beautiful mockup. By the way, I love that this is like all you need. This is all you need. This is all you need.
好的,各位,玩笑就到此为止吧。现在我们来做一个现场演示,让大家看到它的实际使用效果。我会在过程中问大家一些问题。所以,我让你们打开一个共享屏幕,展示你们的项目运行情况。好的,先来一点背景介绍。这是一个非常基础的 React 项目,目前里面是空的。如果你打开任何文件,都是默认的 React 应用项目。我这里有一张基本的图片,你可以将这张图片导入,用来展示项目的样子,比如我想做一个类似狗狗版 Airbnb 网站的样子。非常棒的设计图,顺便说一句,这就是你所需要的,仅此而已。

So basically what we're going to do is we're going to say, hey, one of the cool parts about windsurf is it can actually work in an existing project already. Right. So I can basically say, hey, change this react app to show an Airbnb for dogs website based on this image and preview it. So now it'll just go out and start executing code reading through the repository. Obviously doesn't know what the current code base actually looks like. And it'll go out and analyze the code base to actually find out the set of changes necessary. So we'll go out and wait and see what it's see what it's going to do. But while we're doing that, let's let's continue the conversation.
所以基本上,我们要做的是展示一个风帆冲浪(windsurf)的酷炫部分:它实际上可以在现有的项目中运作。换句话说,我可以让它把一个 React 应用程序改造成一个基于某个图像的“狗狗Airbnb”网站,并预览结果。 这样一来,它就会开始执行代码,读取整个代码库。当然,它并不知道当前代码库的具体样子,不过它会分析代码库以找出需要做出的改动。我们会等一会儿,看看会发生什么。不过在这期间,我们可以继续聊。

Awesome. Okay. So first of all, the you kind of start. So you open up windsurf. You had a boilerplate react project ready to go. And when serve it never really seen this code before you ask it to do stuff on your code base, which is just like change this to Airbnb for dogs using this design. That's right. That's exactly right. Yeah. Okay. Cool. So we'll let it run and we'll talk.
太好了。好的。那么首先,你得先开始。你启动了 windsurf,已经准备好了一个样板 React 项目。对于 windsurf 来说,它从来没有见过这个代码,你让它在你的代码库中执行一些操作,比如按照这个设计把某部分改成适合狗狗的 Airbnb。没错,完全正确。好的,很好。那么我们就让它运行,然后再聊。

So let me ask you this question that I've been asking everyone that comes on that is building a product that helps engineers build products and product management products and designers. So you could sit next to every single user that opens up windsurf and whisper a couple tips in their ear to help them be successful with the product will be a couple tips each year. Tip number one is just be a little bit patient and both patient and explicit right when you ask the application to go out and make some changes. It could actually go out and make many irrelevant changes right and one of the things that I think prevents this the most is just be really really explicit or as explicit as possible.
让我来问你一个我常问那些开发产品帮助工程师、产品经理和设计师的人一个问题。假设你可以坐在每一个使用Windsurf产品的用户旁边,悄悄给他们一些建议,帮助他们更好地使用这个产品,你会给出哪些建议呢? 第一个建议是要有点耐心,而且在操作时既要耐心又要明确。当你要求应用程序去做一些更改时,它可能会进行很多无关的更改。我认为,防止这种情况的最佳方法就是尽可能明确地表达你的要求。

And one of the things I sort of ask people to do is in the beginning start by making smaller changes. If there's a very large directory don't go out and make it refactor the entire directory right because then if it's wrong, it's going to like basically destroy 20 files. And I think from there, one of the key pieces I think that it comes from the users that use the product is they sort of learn what the hills and valleys of the product are. And the analogy I like to give are kind of similar to autocomplete right when you use a product like autocomplete you would think a product that is suggesting things but only getting septic 30% of the time would be really, really annoying.
我通常建议人们从小的改变开始。例如,如果有一个非常大的目录,不要直接重构整个目录,因为一旦出错,可能会影响到20个文件。我认为,从用户使用产品的过程中,他们会逐渐了解产品的优缺点。我喜欢用自动填充来打比方:当你使用一个如自动填充的产品时,你可能会认为一个只能在30%的情况下准确建议内容的产品会非常烦人。

But the reason why it's not very annoying is actually because you've actually learned that hey 70% of the time I don't eat except this or and the times that I do I know how to get value from it right and you also know beforehand if a if a if a sort of command that you write. Is very complex you just expect a like the autocomplete is not going to work for it right so I think it's almost like a like understand what the hills and valleys of the product are the crazy thing is every three months that kind of gets changed and reevaluate.
但这并不是特别烦人的原因实际上是因为你已经学会了,大多数时候(70%的时候)我除了某些情况外是不吃东西的,而当我真的吃的时候,我知道如何从中获得价值。另外,如果你事先知道所写的命令很复杂,那么你就能够预料到自动完成功能可能不会对此起作用。我觉得这就像是理解产品的起伏。而令人惊讶的是,每隔三个月,这种情况都会改变和重新评估。

It almost becomes the case that that it becomes materially better than it was in the past so I think I think maybe patients and being explicit or maybe to important key pieces that would tell users. And I think something that was kind of between the lines there is like get a gut feeling of what the model is capable of like how specific to be versus abstract you can be and there's kind of this like gut feeling you start to build over time that's right yeah and with that it feels like we have a actual preview.
这几乎变成了一种情况,即事情在物质上比过去更好,所以我认为,耐心和清晰表达可能是告诉用户的两个重要关键点。我觉得其中隐藏的一层含义是,要培养对模型能力的直觉感受,了解应该具体到什么程度,或者可以多抽象。随着时间的推移,你会开始形成一种直觉,对吧,有了这种感觉,我们仿佛能看到一个真实的预览。

Guess what we have a nice you dogs a nice dog app and one of the cool parts is that we've also done beyond just just modifying code is actually being able to point to different pieces and I guess I could just kind of say I could point to different elements and say hey like make the background. This is not great great design but I could basically say if I took this element make this background read right and just take a particular element and just change it and make it read and it should go out and be able to go out and do this the preview aspect of the product of being able to showcase the app while it's getting built helps in that now actually you can live entirely an app app world right you don't even maybe even need to look at the code right this looks hideous but.
你猜怎么着?我们有一个很棒的狗狗应用程序,其中一个很酷的功能就是我们做的不仅仅是修改代码而已。实际上,我们可以指定不同的部分来进行调整。我可以指向不同的元素,比如说:嘿,把这个背景变成红色。这可能不是很好的设计,但我基本上可以说,如果我选中了这个元素,就让它的背景变成红色。这样,应用程序就能够相应地进行更改。 产品预览功能在应用程序构建过程中非常有帮助,现在你可以完全在一个应用程序的世界中工作,不必一定查看代码。虽然说起来有点不完美,但的确可以这样操作。

But in some ways if I wanted to I could go out and do that right this is what happens when there's no more designers like yeah when there's no more. Designers like maybe the answer the answer is like when you ask me what's your people be doing they should study great taste having great taste because I think taste is also very very hard right but maybe the other key piece learning that I wanted to showcase here is like Obviously you could keep going here like I could take different components and kind of change them you know like we have like a lot of plans here that are beyond just like point and click changing components but one of the cool pieces is the AI there's like an AI review flow as well right which is kind of like what I was saying the goal of the eyes now change a lot in that it is now modifying large chunks of code for you and the job of the developer now is to is to actually review a lot of the code that the AI is generating and graduate right now during this during this part of the day.
但在某些方面,如果我愿意,我现在就能出去做这件事。这就是当没有设计师时会发生的情况。是的,当没有设计师时,也许答案是这样的。当你问我人们应该做什么时,他们应该学习拥有良好的品味,因为我认为品味很难掌握。不过我想在这里展示的另一个关键点是,显然你可以继续走下去,比如我可以采用不同的组件并进行调整。我们有很多计划,不仅仅是简单的点击和改变组件。一个很酷的部分是人工智能,它有一个AI的审核流程,就像我之前说的,现在AI的目标发生了很大的变化,它现在可以为你修改大块的代码,而开发者的工作就是审核AI生成的大量代码并提高它。在今天的这个过程中,就是这样。

I'm not going to review all the code that's getting get ready but let's say I want to go out and modify some of this code right and this is where if you're an actual developer that actually wants to go modify maybe I don't like my variable name being called title I want it to be called title spring right instead like this and if I wanted to go out and make that change and make the change to go out and say title spring right and that's what I'm going to do I'm just going to tell the ad to continue.
我不打算审核所有正在准备的代码,但假设我想要修改其中的一些代码。如果你是一个真正的开发人员,并且想要进行修改,比如说我不喜欢我的变量名被叫做“title”,我想把它改成“titleSpring”。如果我想做出这个改变,并且让它成为“titleSpring”,我会这样做。我只是会告诉广告继续。

And the cool part about this is when sir not only kind of knows about what the agent has done it also knows everything that the user is done like our goal here is to have this almost flow like state where everything the user is done the AI also knows. And it's able to predict the intent and as you can see it said I noticed that the interface property title was changed to title spring and then it now has gone out and modified all the locations within the app from title to title spring.
很酷的一点是,系统不仅了解代理完成的所有操作,还能掌握用户做过的一切。我们的目标是让系统处于一种几乎是“心流”的状态,用户做的每件事情,人工智能也都知道。这个系统能够预测用户的意图。正如你所看到的,它识别到“界面属性名称”被更改为“spring标题”,于是就自动在应用的各个地方将“标题”改为“spring标题”。

And now it no longer says that so this is where like even if I'm writing software and I want to go and make point changes the air can go out and quickly make these changes for on the user's path imagine doing a refactor or migration and you just change one part of the code you can just tell the ad to continue the rest. And because it deeply understands the code base it should go out and find all the corresponding places to go out and make the change and obviously now when I reload my app there's no no bug in the app rate still loads properly.
现在它不再这样显示了,所以即使我在编写软件并想做一些小改动时,AI也可以快速地为用户路径上的这些部分做出更改。想象一下进行代码重构或迁移时,你只需更改代码的一部分,然后告诉AI继续完成剩下的工作。由于AI对代码库有深入的理解,它能够找到所有需要更改的相关地方。而且显然,当我重新加载应用程序时,应用仍然可以正常加载,没有任何错误。

I can obviously tell it to do even cooler things like make the app retro right I don't know what that means but I guess I can do that and it should go out and make the change correspondingly for me but yeah that's maybe the high level sort of parts there where the AI is not only kind of able to operate entirely in app space. But also on the code on the code space of the user is going out and modifying code and to bridge the gap between the two so it should add leverage not only on developers that are just purely building apps but also developers that are just hands on keyboard to amazing that by the way it's if you're not on YouTube you can't see that you can just select any element of the page and then reference that in your ask of here's what I want changed.
我显然可以让它做一些更酷的事情,比如让应用程序变得复古。我不知道这具体意味着什么,但我觉得我可以做到这一点,它应该会相应地为我进行更改。但这可能只是比较高层面的部分,AI 不仅能够在应用程序空间中操作,还能在用户的代码空间中操作,修改代码以弥合两者之间的差距。因此,它不仅对那些纯粹构建应用程序的开发人员有帮助,对那些直接编写代码的开发人员也有帮助。顺便说一下,如果你不在 YouTube 上,你就看不到这些;你可以直接选择页面上的任何元素,然后在你的更改请求中引用它。

I didn't know that was a feature that is extremely cool so interestingly so having just looked at lovable and bolt and replant and apps like that it's basically doing all the things those apps do oh wow there's the retro version that's good. I like that it built on your red and made it really nice actually the red looks way better now yeah a little green button this is great okay so so I don't think people realize this about apps like Windsor it could actually do a lot of agentic work for you where you just tell it here. I want you to do this versus it's auto completing code for you the big differences you need to start it with some code base you have this kind of boiler plate react project is there a reason you guys aren't taking math step and just doing that automatically for you is it because you're targeting engineers and they don't need that or you know any interesting thing is like the base app that you saw for this was also generated by Windsor the reason why we sort of didn't generated is installing all the dependencies takes like three or four minutes and for the demo I didn't want to wait.
我不知道那是一个功能,太酷了。在查看了 Lovable、Bolt、Replant 以及类似的应用后,我发现它基本上实现了这些应用的所有功能。哦哇,还有复古版本,真不错。我喜欢它在一开始的红色基础上做得更好,现在红色看起来好多了。还有一个小绿按钮,很棒。我觉得很多人不了解像 Windsor 这样的应用,它实际上可以为你执行很多智能工作,只需要告诉它你想做什么,而不是简单的自动补全代码。主要的区别在于你需要从一些代码库开始,比如一个标准的 React 项目。你们有没有理由不自动为用户启动这些过程呢?是因为你们的目标用户是工程师,他们不需要这种帮助吗?有趣的是,你看到的这个基础应用也是由 Windsor 生成的。我们没有自动生成它的原因是安装所有依赖项需要三到四分钟,而在演示时我不想等那么久。

But totally actually most of the users within within of the product probably zero to one build these apps and if I can say one interesting thing is when we launched Windsor actually we test everyone under a company to go out and build an app with Windsor that included our go to market team and our sales team and there was a crazy stat that I think people would find surprising but we saved over half a million dollars of of SaaS products we were going to buy because our go to market team has now built apps instead of buying like our head of partnerships instead of going to buy. And then we actually built our partnerships instead of buying a partner portal product has actually built his own partner portal right and that was that you know he had never built software in the past.
大多数产品用户实际上都是从零到一地构建这些应用。如果可以说一件有趣的事,那就是当我们推出Windsor时,我们让公司里的每个人都尝试用Windsor开发一个应用,这包括我们的市场拓展团队和销售团队。有一个让人惊讶的数据是,我们节省了超过五十万美元的SaaS产品成本,因为我们的市场拓展团队自己开发了应用,而不是去购买。例如,我们的合作伙伴关系负责人本来准备购买一个合作伙伴门户产品,但他实际上自己构建了一个,即使他此前从未开发过软件。

So and we've actually come up with ways inside the company to deploy these apps easily in a secure way and we're actually now like building very very custom software for a company to operate more efficiently which is I would not have expected this probably six months ago. So it's incredibly interesting you don't need to name company names but I guess what's the space your least bullish on they think is going to have the most problem here with company people building their own version of these sorts of products. You know I think maybe my viewpoint are these very very verticalized niche products I think are going to get they're going to get competed down a ton and I think sales products are an example of one of these things right.
我们公司内部已经找到了方法,可以轻松且安全地部署这些应用程序。目前,我们实际上正在为公司开发非常定制的软件,以提高运营效率,这在大约六个月前是我没有预料到的。所以,这非常有趣。你可以不必提公司名称,但我想知道你对哪个领域最不看好,认为公司自制这种产品会面临最大的问题。我的观点是,那些非常细分的垂直市场产品可能会面临大量竞争,销售类产品就是其中一个例子。

And maybe this is a I don't want to be like very negative but it's very hard inside a company like ours to task our best engineers to build a best from class sales product there's not enough interest to do that. Or to build a best in class legal legal software product or finance software product it's very very hard for us to right and actually that's a very big moat for these companies that they were that built these products that they were able to come out having opinion it stands on how to do this higher good enough engineers to go on build the software. Our company is unwilling to do that so previously we would go out and buy the technology right because there would be no alternative but now one of the crazy things is that is that the domain specialists now have access to build the tools that they ultimately wanted right which is actually crazy right if you think about why why were these software companies able to exist these vertical software companies the reason is because they had many features the kitchen sink of features worked for a lot of companies but each individual company only one a 10% of the features.
可能我不想表现得很消极,但在我们这样的公司里,让我们最优秀的工程师去打造一流的销售产品是很难的,因为对这类项目的兴趣不足。同样,要打造顶尖的法律软件产品或财务软件产品,我们也面临很大困难。那些成功打造这些产品的公司拥有强大的护城河,因为他们能够提供深入的见解,并招募优秀的工程师来开发软件。我们的公司不愿意这样做,所以过去我们会去外部购买技术,因为别无选择。但是现在令人惊讶的是,各个领域的专家可以自主构建他们理想的工具。仔细想想,这有点不可思议——为什么这些垂直软件公司能够存在?原因在于它们提供了很多功能,而这些功能可能适合很多公司,但每个公司实际上只需要其中的10%。

The problem is each individual company was not capable of maintaining a piece of software or building the custom piece of software for 10% of the features but that has now changed entirely now they can and there's always yeah there's always been a story like why would I spend any time building my own software if I could just but now it's like five minutes of time like it's five minutes and maybe even more custom to your system right like how many times if you bought a piece of bought a software and you build your almost like why is there no integration to X and I actually use X how annoying is that that actually makes the software.
问题在于,以前每个公司都无法维护一款软件或为软件的10%功能开发定制模块。不过现在情况完全改变了,他们能够做到这一点。一直以来都有这样的讨论:如果我能直接购买软件,为什么还要花时间自己开发?然而现在只需要五分钟的时间,甚至能更好地定制符合你的系统需求。比如,你买了一款软件,自己开发之后常常会发现:“为什么没有集成到某个功能,而我实际上在用这个功能。”这种情况是多么令人烦恼,这正是让软件变得不理想的原因。

It's less useful to you so I think what's cool is that when you go back if someone zooms back to the beginning of when you started the demo it's basically a PM talking to an engineer hey build me a Airbnb for dogs here's a stupid mark that I made like with some box like that's that's almost like a bad PM talking to an engineer and it just actually works that's what's insane about this and so that's why this example you're sharing of go to market folks building their own things it's like they don't need to know and I'm going to do it.
这对你来说可能不太有用,但有趣的是,当你回头看的时候,如果有人回到你开始演示的时候,那基本上就是一个产品经理在对工程师说:"嘿,给我做一个狗用的Airbnb,这里有个我画的草图,就像一个方框一样"。这听起来像是一个不太称职的产品经理在跟工程师谈话,但却真的能实现。这就是这件事的奇妙之处。这也是为什么你分享的例子中,说市场团队自己构建东西,这么有意思的原因,他们不需要再去了解技术细节就能完成任务。

So I'm going to do a lot of things about product building it's just describe it in some ridiculous way and draw a couple boxes of what you want to look like and it makes something for you shows that agencies what matters if you have a product manager that has an idea there's no reason for why that idea cannot be like more well fleshed out right like how many times do you ever product manager that just but it just feels like they are extremely unsure on how to execute on it they just want to say things for the sake of taking things but for the people that have ideas and a lot of I guess agency they can go out and like prove out what they want without any sort of external resources.
所以,我打算在产品构建方面做很多事情,就是用某种荒谬的方式描述出来,然后画几个方框来展示你希望它是什么样子的,这样一来它就能为你创建一些东西,并向代理机构展示什么是重要的。如果你有一个产品经理,他有一个想法,那没有理由不把这个想法更加完善吧。多少次你遇到过这样的产品经理,他们似乎对如何执行感到非常不确定,他们只是为了发言而发言。但是,对于那些有创意并且有很多自主性的人来说,他们可以在没有任何外部资源的情况下验证自己的想法。

I think even more acutely for product folks listening to this it's the sales person coming to you being like hey I want this thing it's going to help me with my sales team and you're like I don't have a million things to build I don't have time for this. And so that problem goes away which I think will make a lot of product leaders are really happy. The model that this is sitting on is it sonnet yeah so just to break down how it ultimately works we have a model that does planning and I would say right now son it is a really really good planning model I think opening eyes GPT four is also good but the crazy thing is what we try to do is we try to make the anthropic base model or sonnet model try to do as much of the high level planning is possible.
我认为,对于那些从事产品工作的朋友们来说,这种情况尤为明显:销售人员来找你说,他们需要某个东西来帮助他们的销售团队,而你却在想着自己有一大堆事情要做,根本没有时间为他们开发这个功能。不过,这个问题的解决将让很多产品负责人感到非常高兴。这个模型是基于Sonnet的,它是一个出色的规划模型。当然,OpenAI的GPT-4也很不错。我们试图让Anthropic的基础模型或Sonnet模型尽可能多地承担高层次的规划任务,这听起来有些疯狂,但确实是我们的目标。

And then what we try to do internally is run all the models necessary to do high quality retrieval for the agent as you could see the agent needed to understand what the rest of the code base ultimately did. We actually make sure we run models to actually chunk up the entire code base and understand the code base so that obviously it would not be a good idea if we had a hundred million line code base to send that entire code base to a topic first of all you couldn't do that that's over 1.5 billion tokens of code right so obviously that would be three orders of my three or four or just a mic to larger than the largest context lungs right now.
然后,我们在内部尝试执行所有必要的模型,以便为代理实现高质量的信息检索。正如你所看到的,代理需要理解代码库的其他部分实际在做什么。我们实际上会运行模型,来分块整个代码库并理解它。显然,如果我们有一个一百万行的代码库,把整个代码库发给一个主题是不明智的,因为首先你根本做不到,这会超过15亿个代码标记。所以,这显然比当前支持的最大上下文长度大出好几个数量级。

But you also wouldn't want to do that from like a cost and latency standpoint to so that's like one and the second piece that you saw was the models able to very quickly make edits to the to the software as well we have cost of models that we built that are post-craned on top of popular open source models that can make these edits really really quickly to the code base and the reason why you would want to do that is it's a faster and be also that model can actually have more of the code base in context to so it can be better at applying changes than even after a lot of the time.
但是,从成本和延迟的角度来看,你也不希望那样做。所以这是一个方面。此外,你会看到模型能够非常快速地对软件进行编辑。我们建立的模型成本较低,这些模型是在流行的开源模型基础上进行后训练的,能够非常快速地对代码库进行编辑。你之所以愿意这样做,是因为这样速度更快,并且模型可以在更大的代码上下文中进行操作,从而更好地进行更改,通常效果甚至比手动修改要好。

Then even a drop it's model to so I think the way we like to think about it is our only goal is how do we build the best product possible right how do we build the best product possible and how do we how do we make the ceiling as high as possible and we will go out and build models and train models wherever necessary but we're not going to be good at good at a task and we think the open source better or at the office better we'll just use the open source or at the office and so the models you guys are building those are built on open source models that people are really yeah interestingly the one that does retrieval is actually completely pre trained in house that actually does that but.
然后,即使是一个小小的变化,也可以成为一个模式。所以我认为我们的思考方式是,我们唯一的目标就是如何打造最好的产品。我们要想办法将产品做到最好,并将潜力推到最大。我们会在需要的地方构建和训练模型,但是如果我们擅长的领域,开源模型或公司内部的解决方案更好,我们就会使用这些更好的资源。因此,你们正在构建的那些模型实际上是基于人们已经很了解的开源模型。不过有趣的是,负责检索的那个模型是完全由我们内部预训练的。

Yeah for for a lot of different pieces it's based on open source for interestingly for the one that does that does the edits and autocomplete that is also in house. Like as you're typing we actually do some autocomplete related stuff i'm happy to show that but i think a lot of users are familiar with that capability. So i think the way we like to look at it is like what could we be best at and we will go out and train but if we're not going to be best at it we should not just for the sake of ego go out and trade something.
是的,对于很多不同的部分,我们使用的是开源技术。有趣的是,用于编辑和自动补全的部分是我们自己开发的。当你输入内容时,我们会做一些与自动补全相关的操作。我很乐意展示这个功能,但我想很多用户已经熟悉这个功能了。我们希望以这样的方式来看待问题:在我们能够做到最好的领域,我们会去训练相关技术;但如果我们不能做到最好,就不应该为了所谓的自尊而去训练。

This may be getting too technical but just is there anything interesting around what you train on yeah so one of the one of the interesting things that we have from our users and this is like where we try to think like why would we be any better it's 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 users typing right imagine you're typing typing some code in a code base. The code is 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 get up. But we have a lot of data that looks like this so we're 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 are the frontier models of consume very little code that looks like this.
关于偏好数据的问题,偏好数据看起来很奇怪,它不像你在互联网上找到的数据。更像是用户在输入时生成的数据。想象一下你正在代码库中编写代码。当你输入时,代码是不完整的,对吧?它不会是一个完整的版本,不像你在GitHub上看到的那样完备。但是我们拥有大量这样的数据,因此我们在构建可以在代码不完整时完成代码的优秀模型方面具有独特的优势。而目前市面上的一些前沿模型很少使用这种形式的代码数据。

So for that case we're like hey we can go out and do a much better job potentially right and we'll go out and train models on all the preferences that we have the same as kind of true on retrieval right there's a way to find out are we retrieving the right data right that the user accepted code change after that was the retrieval actually good retrieval signal that we can get. So basically the way we like to look at it is if something is just purely like code planning there's not a great reason why we would be the best event right I think that would that would not be a 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 is very gnarly and here are some changes that need to get made and we we know the evolution of the code where we've seen the evolution of code across millions of users we feel like we can do a great job.
对于这种情况,我们会想,嘿,我们可以做得更好,对吧?因此我们会根据已有的偏好进行模型训练。同样的道理也适用于检索,我们需要找到方法来确定我们是否检索到了合适的数据,比如用户是否接受了代码更改,这其实就是一个很好的检索信号。因此,我们比较喜欢的角度是,如果只是简单的代码规划,我们并没有很好的理由说自己一定是最佳选择。我认为没有连贯的理由支持这一点。但是,如果涉及到一个复杂的代码库,我们需要进行一些改变,而我们了解代码随着时间的演变,因为我们观察到数百万用户的代码演化,这方面我们认为自己能够做得很好。

I think it's interesting about this is this is another differentiator slash mode for companies that end up winning in the spaces 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 like we like the zero to one up building product space. I think it's really it's like 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 as a company. As it feels like it might get like competitive in a way that it's not clear like where you would continue to differentiate over and over with time.
我认为有趣的是,这是公司在竞争中获胜的另一个区别或模式:你拥有的数据比其他公司更多。如果你领先的话,这就是为什么我们可能会喜欢从零到一的产品开发空间。从高层次看,这是一个很好的产品领域,但最终,你需要对代码有深入的理解。否则,你可能会陷入过于高层次的思考,无法清楚地知道为什么你能比其他公司做得更好。随着竞争的加剧,如果你无法明确知道自己如何能够不断保持差异化,公司就很难持续占据优势。

I see because if they're just sitting on top of sonnet and just doing whatever other sonnet wrapper is doing there's not a lot of differentiation or or it depends on how you do it. But maybe if I was to say this if you're if the inputs you're consuming are just web elements like extremely high level web elements then the interface might be like high level enough that it's it's hard to maybe get better than maybe what the frontier models are doing just across the board you were just better off just plugging in some it for everything.
我明白了,因为如果你只是简单地使用Sonnet(一个工具或框架)并且只是效仿其他Sonnet包装器做的事情,那么就没有太多差异化。或者这也取决于你使用的方式。但如果我换个角度说,如果你使用的输入只是一些非常高级的网页元素,那么接口可能已经足够高级,以至于很难比当前最前沿的模型做得更好。在这种情况下,你可能还不如直接使用Sonnet来处理所有事情。

Got it awesome one thing I wanted to come back to that I wrote down that I think is really important for people to understand you talked about how with windsurf it's not necessarily there's like a boilerplate code base that you want to start with because it's actually because it's not abstract is your one up builder it's a actual ID you are coding in. And you talked about how I asked and solve dependencies which is kind of a painful thing and the reason has to do that is because it's running locally on your machine versus in the cloud like say lovable and replete and all these guys although I think both runs in your browser in this really cool way. So that's an important distinction this is like you're running this locally in a machine and as all the all the libraries you need to actually run it.
好的,我明白了。有件事我想回到我记下来的内容上,我认为这对于人们了解这一点非常重要。你之前提到,在使用Windsurf时,并没有一个可供开发者使用的模板代码库可以直接开始,因为它并不是一个抽象的构建器,而是一个实际的集成开发环境(IDE),你是在其中进行编码的。此外,你还谈到了依赖关系的问题,这有时会让人感到痛苦,其原因是因为它是在你的本地机器上运行的,而不是像在云端运行的Lovelace或Replete那样。不过,我认为它们都是以一种非常酷的方式在浏览器中运行的。所以,这是一个重要的区别:Windsurf是在本地机器上运行的,并且包含了运行所需的所有库。

No, I think that's important I think we believe a lot of people sort of build software and what are called code spaces and things in a remote machine. I just think it's that a lot of developers like building locally for what you said like if you're doing things that are more than just full stack applications you might have dependencies on your machine that are just like system dependencies that are just gnarly to install let's imagine you're building a GP based application and the Nvidia drivers are necessary. You just want to give people the flexibility to build where they can build and I think you know the IDE and building locally has been I think that people have done for you know decades so probably it's not going to go away in the next couple years.
不,我认为这是重要的。我认为我们相信很多人会在所谓的代码空间和远程机器上构建软件。不过,我认为很多开发者更喜欢在本地进行构建,就像你提到的,如果你在做的不仅仅是全栈应用程序,你可能会在你的机器上有一些依赖项,比如一些难以安装的系统依赖项。假设你在构建一个基于GP的应用程序,并且需要Nvidia的驱动程序。我们希望给人们灵活性,让他们能够选择在哪里构建。我认为,使用IDE和在本地构建已经是开发者们做了几十年的事情,所以它可能不会在未来几年内消失。

I love that your sales folks now are running like a lot of servers and well with the browser previews it's easier right you kind of just like open it up on the side yeah yeah oh my god okay a few more questions just about how you think and operate at podium. So you guys are kind of at the forefront of how product teams are going to operate like you are seeing the future every day. And so I'm curious if there's ways you guys have structured your teams engineers product design that might be different from other companies are doing it or tried stuff that has worked really well or tried stuff that hasn't been a huge disaster.
我很喜欢你们的销售团队现在运作如同许多服务器一样,通过浏览器预览功能,这一切变得更加简单,只需在旁边打开即可。太棒了!我还有几个问题想问,关于你们在Podium的思维方式和运营方式。你们似乎站在产品团队运营的前沿,每天都在展望未来。所以我很好奇你们是否在团队架构上,比如工程师、产品设计等方面有与其他公司不同的方法,或者尝试过一些非常成功的做法,或者避免了一些可能导致巨大灾难的尝试。

You know one interesting decision that we kind of have for core engineering is that we don't have pure product managers for for the core engineering side of the company and by the way that's purely because we build for developers and our product is is built by developers so I think the intuition from our own developers are is hopefully hopefully valuable if not we might be hiring the wrong type of people. So I think like our developers are in some sense flexing to be like more product conventional product managers now in the other 90 who are building something that looked more like Uber or the persona was very different and we didn't ourselves understand it I think we would not be the organization wouldn't look the way it looks.
我们在核心工程方面采取了一个有趣的决定:我们没有专门的产品经理负责公司的核心工程。这主要是因为我们的产品是为开发者而建的,并且是由开发者打造的。所以,我认为我们自己开发者的直觉应该是有价值的。如果不是这样,那可能意味着我们招错了人。就某种程度而言,我们的开发者现在需要具备传统产品经理的能力。另一方面,如果我们在做一些类似于Uber的产品,目标用户完全不同,我们自己也不了解这个市场,那么我们的公司的运作大概就不是现在这个样子了。

For the enterprise side of the company because we do work with a lot of large enterprises where the requirements are not something that like our engineers would automatically understand right I don't think our engineers wake up and they're like we need fed ramp right. Like this is probably something that a lot of customers come to us and tell us we have people that kind of like flex in this product strategy role that understand kind of what the what the customer wants and understands the technical capabilities that we have to under the best kind of build a product that would that would sort of help them at scale.
对于公司的企业方面,因为我们与许多大型企业合作,这些企业的需求不是我们的工程师一眼就能理解的。我不认为我们的工程师醒来后就会想到需要符合联邦风险与授权管理计划(FedRAMP)的要求。事实上,很多客户会主动过来告诉我们他们的需求。我们有一些人在产品战略角色中灵活地工作,他们了解客户的需求,并结合我们现有的技术能力,以最佳方式构建一款能够大规模帮助他们的产品。

So I think I think we have an interesting organization in this regard but mostly I would say because we are a developer based product right I would say that's true. And then also kind of like what you said for the engineering team itself we are you know the team structure is it's fairly flat we try to go with two pizza teams teams that are fairly small just because I think the problem is when a team gets too big the person leading the team is no longer able to get in the weeds of the technology itself.
所以我认为,在这方面我们有一个有趣的组织,但主要来说,这是因为我们是一个以开发者为中心的产品,我会这么说。另外,正如你所提到的,我们的工程团队结构相对扁平化,我们采用“两份披萨”的团队规模,也就是团队较小。因为我认为,当团队过于庞大时,负责领导团队的人就很难深入参与到技术细节中。

And I think in a space that's moving this quickly I think it's dangerous to have leaders that don't understand the technology deeply and are like I'm not building it's very very dangerous because there's too much like armchair quarterbacking. And so so I think I think that's like maybe maybe maybe like one other decision we made and then teams are very very flexible so if we decide something is a new priority we're very quick to kind of like change the way a team looks and it's very centrally planned in this regard.
我认为在一个发展如此迅速的领域中,拥有不了解技术核心的领导者是很危险的。如果这些领导者只是指挥,而不亲自参与构建,那就会有太多的纸上谈兵。因此,我觉得我们可能做出的另一个决定是确保团队非常灵活。这意味着如果我们确定某件事是新的优先事项,我们可以迅速调整团队的构成,并且在这方面我们是高度集中规划的。

The two pizza team concept I saw a tweet long ago or someone from India was like there's always talk about two pizza teams but pizzas in India are much smaller. And so the teams end up being smaller like like can we build as much of these teams in the hands. Oh man. Okay so how many PMs do you have so you said you have 150 employees something like that yeah we have so in terms of like the product strategy function we have we have a we have three people in that role right now. I see so it's like product it's like they're in their title is like this product strategy not yeah product manager that's right that's just thing and then 50 engineers you said ADS sales folks. Yes that's right and then obviously we have functions like recruiting you know parts of GNA like finance right we have marketing at the company right so some other some other functions internally as well.
我曾在推特上看到关于“两块披萨团队”概念的讨论,某个来自印度的人指出,尽管总是有人谈论两块披萨团队,但印度的披萨要小得多,所以团队也相应更小。这样,我们是否能够建立同样多的团队呢?哦,天哪。所以你有多少产品经理?你提到你有大约150名员工?是的,我们的产品战略部门目前有三个人。我明白,也就是说他们的职称是产品战略,而不是产品经理。对,没错。然后你有50名工程师和广告销售人员?是的,没错。此外,我们公司还有招聘、行政和财务等职能,还有市场营销和其他内部功能。

It's interesting and then this is something you hear all the time with companies like Dario for example from Anthropic talking about 90% of code is going to be written by AI but all at the same time all you guys are hiring engineers like crazy. Yeah is there is that contradictory. It's that contradictory will there be an inflection point of like all right now we don't need them anymore you know I think it really comes down to do you get incremental value by adding more engineers internally like I'm going to take first of all you know maybe just to set the records rate if AI is writing over 90% of the code that doesn't mean engineers are 10x as productive right engineers spend more time than just writing code the review code test code debug code design code deploy code right navigate code there's probably like a lot of different things engineers do.
这很有趣,这种讨论经常出现在公司中,比如Anthropic的Dario就提到过,未来90%的代码将由AI编写。然而与此同时,你们公司却在疯狂地招聘工程师。这是否自相矛盾呢?会不会有一个转折点到来,让我们决定不再需要这么多工程师呢?我认为这关键在于,增加更多工程师是否还能为公司带来额外的价值。 首先需要澄清的是,即使AI编写了90%以上的代码,这并不意味着工程师的生产力是以往的十倍。工程师不仅仅是写代码,他们还要审查代码、测试代码、调试代码、设计代码、部署代码、浏览代码等等。实际上,工程师的工作内容非常多元化。

There's this one famous law and parallel computing. It's called Omdol's law I don't know if I don't know if you've heard about it but it basically says if you have a graph of tasks and you have this critical path and you take any one task and paralyze it a ton which is make it almost take zero amount of time there's still limit of the amount of how much faster it made the whole process go. So maybe put simply let's say you have 100 units of time and only 30 units of time is being spent writing software and it took the 30 and made it three I only took the 100 and made it 73 it's only 27% improvement right in the grand scheme of things.
这有一个著名的法则和并行计算有关,它叫做阿姆达尔定律。我不知道你有没有听说过,但它基本上是说,如果你有一张任务图,并且有一条关键路径,如果你把其中任何一个任务并行化很多次,也就是让它几乎不耗费时间,那么即便如此,整个过程加速的程度还是有一个上限。简单来说,比如你有100单位的时间,其中只有30单位时间用在编写软件上,你把这30单位时间缩短到3,那么整个过程总共只从100缩短到73,这样看来总的提升也不过是27%,对不对?

So I think look we're definitely seeing over 30 maybe close to 40% productivity improvements but I think for the vision that we're solving for I think like you know even if I were to say the company in the long tail had 200 engineers probably be too low still at that point. So the question is like how much more productivity do you get per person you know actually maybe just to even say one other thing for some of these large companies let's say you took the CIO of a company like JP work and chase right. Her budget on software every year 17 billion dollars and you there's over 50,000 engineers inside the company right and you told her hey like each of these engineers are now able to produce more technology that's effectively what you've done right.
我认为,我们确实看到了超过30%甚至接近40%的生产力提升。不过,我觉得对于我们要实现的愿景来说,即使我说公司长期来看有200名工程师,这个数目可能仍然偏少。所以问题在于,每个人还能提升多少生产力。以一些大公司为例,比如像摩根大通这样的公司,如果你告诉他们的首席信息官,他们每年在软件上的预算是170亿美元,同时公司有超过5万名工程师。而现在,这些工程师每个人都能生产出更多的科技产品,这就是你实际上所做到的。

The right calculus that JP more in chase or any of these companies will make is the RY of building technology has actually gone up. So the opportunity cost of not investing more into technology has gone up means that you should just invest even more and maybe in this work from you have even more engineers right now that's not true across the board there are some companies that are happy with the amount of technology they're building and there's a ceiling on the amount of technology they want to build for for companies that actually have a very high technology technology ceiling. This doesn't mean you stop this actually means you hire more.
JP摩根或类似公司需要计算的一个关键点是,建设技术的投资收益率(RY)事实上增加了。所以,不增加对技术投资的机会成本也提高了,这意味着你应该投资更多,甚至可能需要更多的工程师。当然,这并不适用于所有公司。有些公司对其技术建设的现状非常满意,并且技术发展的潜力也有限。但对于那些有着很高技术潜力的公司而言,这并不意味着停止投资,反而应该聘请更多的工程师来发展技术。

This is a great bullcase for engineers I feel like there's like the canary in the coal mine for the engineering profession is when companies like yours to slow down on a year years. Yeah that's good. See I think it's also I agree. Yeah everyone is so I think that's really promising I think if you're in college still makes sense to get into engineering at this point.
这是一个对工程师职业前景的很好的案例。我觉得对于工程行业来说,有些公司像您这样的企业,当它们放缓发展时,就像煤矿中的金丝雀一样,预示着一些变化。是的,那很好。我也同意这一点。每个人都这么认为,所以我觉得这真的很有前途。我认为如果你还在上大学,现在选择进入工程领域仍然是有意义的。

Yeah. Okay let me ask you this question as a kind of a final question maybe what's maybe the most counter intuitive thing you've learned about. Building AI products building windsurf in this just being in a space I think one of the weird thing is online everyone is very excited about the short term wins that we're making right like what we're putting out maybe weekly we do these waves every couple weeks. But actually like a lot of the bets we're making inside the company are for things that are not you know three four weeks maybe three six months nine months away.
好的。让我问你一个可能作为最后一个问题的问题,你在构建 AI 产品或从事风帆产品中学到的最违反直觉的事情是什么?我认为其中一个奇怪的事情是在网上,每个人对我们取得的短期胜利都非常兴奋,比如我们每周发布的内容,或是每隔几周推出的一些成果。但实际上,我们在公司内部做的很多决策是为了那些三四个星期无法见效的事情,而可能需要三到六个月,甚至九个月才能见到成果。

That's what we're working on internally because I think this is kind of like Lenny what I was mentioning to you before. Like one of the goals that I tell everyone under our company is we should be cannibalizing the existing state of our product every six to 12 months. Every six to 12 months it should make our existing product look silly. It should almost make the form factor of existing product with dumb.
我们正在内部努力实现这一目标,因为我认为这有点像我之前和你提到的Lenny。我们公司设定的其中一个目标就是每六到十二个月都要对现有产品进行“自我颠覆”。每隔六到十二个月,我们的产品就应该让之前的产品显得过时,设计形式也要显得有些“笨拙”。

So it there's this weird tension where you want to have a product and market and you want to incrementally iterate and listen to users and keep making it making it better and better. But I would say we were the first. Agentic ID product out there right that's what we landed with and I think that the value of that is going to depreciate very quickly unless we continue to reproversel and we will need to reproversel in ways in which our users are not even asking.
这段话主要表达了一种微妙的局面:你希望拥有一款产品并进入市场,同时希望不断听取用户反馈,通过渐进式迭代使产品更优秀。但我们的产品是市场上第一款Agentic ID产品,这带来的价值会迅速贬值,除非我们持续进行自我革新。我们需要以用户尚未想到的方式进行改进。

So there's this tension here where incremental feels very safe right at this one more button users say hey I would like to be able to have this drop down to do X but that is not the reason why we're going to win that's just that's like a you know that's almost table stakes. Yeah we'll decide to do some of these we might not decide to do a lot of these things but it's like it's these longer term efforts inside the company that almost disrupt the existing product that are ultimately the reason why we're going to succeed.
这里存在一种紧张关系,增量改进看起来很安全,比如增加一个按钮,用户会说,他们希望能够让这个下拉菜单实现某个功能。但这并不是我们成功的原因,这些只是基本的要求。是的,我们可能会决定完成其中的一些改进,但可能不会做很多。这是公司内部那些几乎会颠覆现有产品的长期努力,才是我们最终成功的原因。

And it's this weird tension that you need to have in your head of you can't also not listen to your users at all because they're the reasons they're the reason you exist. This reminds me of a recent podcast guest we had Gara for captions on the podcast and he told us that he had just two roadmaps they have two roadmaps of the company they have the the real road map.
这段话表达了一种奇怪的矛盾心理,你不能完全不听取用户的意见,因为用户是你存在的原因。这让我想起我们最近请到的一位播客嘉宾Gara,他在播客上提到他们公司有两个路线图,其中一个是真正的路线图。

Like the typical road map based on feature request and user feedback and data and things like that and then they have a secret road map which is completely not informed by users or data it's just them making bets on where they think the world is going. That's right. And I love that he calls it the secret road map just to make it very mysterious. That's very smart.
像那种基于功能需求、用户反馈和数据等创建的典型路线图一样, 他们还有一个“秘密路线图”,这个路线图完全不受用户或数据的影响,只是他们根据自己对未来趋势的猜测而做出的决策。没错。我很喜欢他把它称作“秘密路线图”,这让它显得非常神秘。这真是个聪明的做法。

Okay I have one more question I apologize. What's one thing that you wish you have known before starting code and honestly I wish I had. Maybe humility is like the wrong term but this idea of just being okay with being wrong faster. Like I always think about things on like when we make decisions me and my co-founder we always talk about it we're almost like hey I wish we had made the decision to do this a couple months earlier. We always talk about this and the weird thing is outside looking at everyone's like wow like actually you know the decision was made at the right time but in my head I'm always banging my head being like what if we had made it a couple months earlier.
好的,我还有一个问题,不好意思。有没有一件你希望在开始编码之前就知道的事情,老实说,我希望我当时就明白。也许谦逊这个词不太准确,但我想说的是,能够更快地接受自己可能出错这个概念。我总是在思考,当我和我的合伙人做决策时,我们总是讨论这样的话题,几乎每次都会说,“要是几个月前就做出这个决定就好了。”我们总是这么讨论。奇怪的是,外界的人看我们就觉得,“哇,实际上你们在恰当的时间做出了决定。”但在我心里,我总是揪着自己不放,想如果我们能提前几个月做决定会怎样。

And I think part of that is you know I I waxed poetically about like oh you need to be a rationally sort of optimistic and uncompromisingly realistic but it's very hard to do this in practice right because you drink your own cool it to it's very because if you're not drinking your own cool it you you won't get up out of bed. Right the answer is already solved it's not actually any of these startups the answer is Microsoft is going to be the the winner in any software category right isn't that isn't that the answer just because of distribution resources and capital right they're going to come out of that every space.
我认为这部分是因为我曾经诗意地谈论过要理性地乐观,同时又要毫不妥协地现实。然而,在实践中做到这一点非常困难。因为如果你不相信自己的想法,你就不会有动力去做任何事情。而且我们通常会认为答案已经被解决了,所有创业公司的问题最终答案就是微软会在任何软件领域成为赢家。难道不是这样吗?因为他们拥有庞大的分销资源和资本,他们将主导每一个领域。

So I think I think in some ways you this this amount of just understanding that hey like reevaluate your hypotheses and get into an uncomfortable space way more frequently is something I need to remind myself even to this day and probably something that I didn't know coming in and starting the company right I we started the company at like peak zirp time at that time probably like everything seemed like it was going to moon and there was probably a lot of irrational confidence I would say that we shouldn't have had.
因此,我认为,在某些方面,你需要时常提醒自己,要重新评估你的假设,并更频繁地进入不舒适的领域。即便是到今天,这也是我需要提醒自己的事情。在创办公司之初,我并没有意识到这一点。我们是在零利率政策高峰期创办公司的,当时一切似乎都在快速增长,也许我们有许多不应该有的非理性自信。

Roon we covered so much ground what an incredible conversation I learned so much just just sitting here listening and asking questions is there anything else that you wanted to share before or leave listeners with any last piece and I get so wisdom before I let you go. To be honest I could give predictions about the space probably most of them are going to be wrong I think the best thing to do is just get your hands dirty with with all of these products and I think one of the most obvious things that's going to happen is in the next year. There will be a tremendous amount of alpha for anyone that is able to take maximum advantage of these tools right just imagine how many of your coworkers just don't even know the existence of these tools don't know what they can do and how much less productive they will be.
Roon,我们在这次谈话中涵盖了很多内容,真是一次不可思议的交流,我在这里静静地听和提问中学到了很多。临走前你是否还有什么想分享或留给听众的最后智慧?老实说,我可以对这个领域做一些预测,但大多数可能都是错的。我认为最好的做法就是亲身实践这些产品。我相信,未来一年里,任何能充分利用这些工具的人都将获得巨大的优势。想象一下,有多少同事甚至不知道这些工具的存在,不知道它们能做什么,这将使他们的工作效率低很多。

And and just I would just say get your hands as dirty as possible as quickly as possible and when you say get your hands dirty basically it's like download would serve start coding ask it to build. Yeah build apps build apps start using it for maybe even making making mocks modifying your existing code base like there's probably ways in which you could be a force multiplier to your organization and ways in which they never even anticipated right imagine if you are a product manager that could actually very quickly make edits to the code base and and just start pushing changes yourself you probably get a tremendous amount of respect from your own engineering peers you could probably get way more done because of that it's just I feel like the there's no there's no sort of.
你可以尽可能快地让自己动手实践,把手弄脏。所谓的“弄脏手”就是下载软件,开始编码,试着让它构建。是的,构建应用程序,构建应用程序,甚至尝试使用它来制作模型或修改你现有的代码库。你可能会成为你所在组织的倍增器,以一些他们从未预料到的方式。例如,想象一下,如果你是一个产品经理,而且还能快速编辑代码库并自己进行调整和实施更改,你可能会因此赢得工程同事们极大的尊重。这会让你能够完成更多的事情。我觉得,没有什么比这种能力更具优势的了。

See link at the point I think this is such an under estimated point you're making here there's apps that can build things from scratch and then there's apps like this like an edit your existing code base if you're PM at like what's what are the what's the largest company work with like people wise probably like it publicly I'd say let's just say JP Morgan chase okay they have over 50,000 developers okay so you could be a PM JP Morgan Chase and be like I have a I have a problem I need to solve I want to move this metric I want to.
查看链接,在这一点上,我认为你所说的内容是一个被低估的观点。有一些应用程序可以从零开始创建东西,还有一些应用程序像这样可以编辑现有代码库。假设你是一个项目经理,比如说在像JP摩根大通这样的大公司工作,员工人数庞大,对外公布的开发人员就有超过5万人。因此,你作为JP摩根大通的项目经理,可能会遇到需要解决的问题,想要推动某个指标的提升。

Change the step and sign up flow you you just open up windsurf and tell it to do the thing you want and then can you push straight to GitHub and do a yeah actually you could do that. Yeah, okay yeah you are yeah I could make up the earthery this is insane yeah future is out of control okay that was such an important point in there because I think people may not realize this they see all these other apps they're like oh Bill ice prototypes but this is like legitimately something if you can actually do work with yeah when you think about the people I least that I don't know Lenny who you respect the most they're the people that somehow despite their title their level of agency and just output just to the all the way down to the weeds to the highest level strategy is just perfection right they know when to go all the way down.
更改步骤和注册流程,你可以简单地打开Windsurf,并告诉它你想要执行的任务,然后你可以直接推送到GitHub。实际上,你确实可以这样做。是的,好吧,你可以。我可以创造这个,这是疯狂的。未来已经失控了。这点非常重要,因为我认为人们可能没有意识到这一点,他们看到其他应用程序时,可能会想这是些不起眼的原型,但这个真的可以让你实际完成工作。当你想到那些你最尊重的人,比如我不知道的Lenny,他们是能够突破职位、权责和产出的限制,从细节深入到最高层次战略的人,这简直完美。

And I think you know sometimes you see people that talk about roles and they irrational I feel like oh because I'm this role I'm not allowed to touch this well now everything's open season right and I think this is an opportunity to almost go all the way down the weeds and all the way up to the top right And just be effective on every level and I believe the world all right well with that we'll leave folks are in thank you so much for being here awesome thanks Well, I'm an incredible conversation thanks for everyone.
我觉得你知道有时候你会看到一些人谈论角色,他们会表现得很不理性,好像因为自己是某个角色,就不被允许碰某些事情。但是现在一切都是开放的,我认为这是一个深入到细节又能看到全局的机会。只要我们在每个层面都有效率,我相信大家都会接受。好吧,就这样,我们就不多说了,非常感谢大家的参与。谢谢,这是一次很棒的对话,感谢每一位参与者。

Thank you so much for listening if you found this valuable you can subscribe to the show on Apple podcasts Spotify or your favorite podcast app Also, please consider giving us a rating or a leaving review as that really helps other listeners find the podcast you can find all past episodes or learn more about the show at Lenny's podcast dot com see you in the next episode.
非常感谢您的收听!如果您觉得这有价值,可以在 Apple 播客、Spotify 或您喜欢的播客应用上订阅我们的节目。此外,请考虑给我们评分或留下评论,这可以帮助其他听众找到这档播客。您可以在 Lenny's podcast dot com 找到所有的往期节目或了解更多关于节目的信息。我们下期再见!