Fiona Fung 谈 AI 对软件工程的影响

Anthropic 的工程师平均每季度交付的代码量是 2025 年的八倍。

Anthropic engineers, on average, ship eight times as much code per quarter as they did compared to 2025.

编码不再是瓶颈。它提升了每个人能力的天花板。

Coding is no longer the bottleneck. It's lifted the ceiling of what anyone is able to do.

理论上现在一切皆有可能。关键在于你能有多大的雄心？

Everything is now possible in theory. Now, it's about how ambitious can you be?

我们总是问自己，有什么比我亲自做更好？没想过，David。

It's always something we ask ourselves, what's better than me doing it? Haven't thought, David.

那些表现最好的人往往最主动、最积极、最有自主性。

The people that seem to be doing best are taking the most initiative, getting the most proactive, have the most agency.

我们说高自主性也意味着高责任感。所以关键在于确保人们有编码的自由，但同时也要问：责任是什么？你试图解决的假设是什么？

We say with high agency is also high accountability. So, it's all about making sure folks have that freedom to code. But, then it's also like, okay, what's the accountability for it? What's the hypothesis of what you're trying to solve?

我很好奇在这个软件工程的新世界里，我们失去了什么。

I'm curious what is lost in this new world of software engineering.

这可能会变得很孤独，因为我们都开始大量与自己的智能体合作。在 Claude Code 团队，我们最近开始了结对编程午餐。

It can start being a lonely experience cuz we all started just working with our agent so much. And on the Claude Code team, recently, we started up pair-wise programming lunch.

你会想到，在那些拥抱 AI 并表现出色的人，与那些不拥抱、感到非常沮丧、挣扎、抗拒的人之间，正在形成一道鸿沟。

Something you think about is this gap forming between people that are leaning into AI, killing it, and then people that are not, super frustrated, fighting, resisting.

关于沮丧，有时我也看到一点恐惧。对于任何让人恐惧的事情，我的建议是迎难而上，问自己：‘我能做什么？什么在我掌控之中？’

In terms of frustration, I think sometimes I also see a little bit of fear. For anything that there is a fear, my advice is lean in and ask, 'What can I do about it? What is within my control?'

今天我的嘉宾是 Fiona Fung。Fiona 领导 Anthropic 的 Claude Code 和 co-work 团队。她管理 Boris Cherney 和 Kat Wu，两人都曾做客本播客，且他们的节目位列历史收听量前十。在 Anthropic 之前，她在微软领导了构建 TypeScript 和 Visual Studio 的团队。之后她去了 Facebook，创立了 Facebook Marketplace 团队，从想法到发布全程负责。如今 Facebook Marketplace 每年产生超过 1000 亿美元的 GMV。在 Meta 期间，她还负责了 Meta 首款智能眼镜产品，并帮助构建了 Orion——他们的首款 AR 眼镜产品。随后她去了 Instagram，领导基础设施、增长、诚信和安全团队。在 Instagram 和 Meta，她管理着一个超过 500 人的组织。Fiona 拥有超过 25 年的工程师经验，作为长期的工程领导者，尤其是在 Anthropic，她对未来的方向、值得关注的事情以及团队在 AI 改变构建世界之际应该思考的问题有着独特的视角。非常感谢 Kat Lo、Boris Cherney 和 Mohammad Hegazi 为这次对话建议主题和问题。在开始之前，别忘了查看 Lenny's product pass.com，Lenny 的新闻通讯订阅者可以独家免费获得一年内全球最热门、最精良的 AI 产品。话不多说，有请 Fiona Fung。

Today, my guest is Fiona Fung. Fiona leads the teams behind Claude Code and co-work at Anthropic. She oversees both Boris Cherney and Kat Wu, both of whom have been on the podcast and whose episodes are in the top 10 most listened to episodes of all time. Before Anthropic, at Microsoft, Fiona ran the teams that built TypeScript and Visual Studio. After that, she went to Facebook, where she started the Facebook Marketplace team, which she took from idea to launch. Today, Facebook Marketplace generates over 100 billion dollars in GMV every year. Also, while at Meta, she oversaw work on Meta's first smart glasses product, and then she helped build Orion, their first AR glasses product. Then, she went to Instagram, where she led infrastructure, growth, integrity, and safety teams. While at Instagram and at Meta, she oversaw an org of over 500 people. Fiona has been an engineer for over 25 years and as a long-time engineering leader, especially now at Anthropic, she has such a unique lens into where things are heading, what's worth paying attention to, and what teams should be thinking about right now as AI transforms the world of building. A huge thank you to Kat Lo, Boris Cherney, and Mohammad Hegazi for suggesting topics and questions for this conversation. Before we get into it, don't forget to check out Lenny's product pass.com for a free year of the hottest and most well-crafted AI products in the world available exclusively to Lenny's newsletter subscribers. With that, I bring you Fiona Fung.

Fiona，非常感谢你来做客，欢迎来到播客。

Fiona, thank you so much for being here and welcome to the podcast.

非常感谢你的邀请，Lenny。

Thanks so much for having me, Lenny.

我大约一个月前参加了 Claude Code with Claude 活动，听了你的演讲，我当时就想，天哪，我一定要请 Fiona 来播客。她思考的比其他人超前太多，远超人们对 AI 的认知。你做了 25 年工程师，我浏览了你的领英。你居然是从 IBM 开始的。如今那里已经大不相同。过去两年工程师的工作变化之大令人难以置信，简直成了一项全新的工作。人们可能忘了，不久前 100% 的代码还是人写的，而现在正走向 100% 由 AI 编写。正如 Boris 那句名言：编码就是盐。与此相关的是，你们昨天发了一条推文，展示了 Anthropic 工程师平均每季度交付的代码量是 2021 到 2025 年间的八倍。我们会在屏幕上展示这张图。它一直稳定、稳定、稳定、稳定，然后 boom，直冲云霄。这个角色的变化太疯狂了。我很好奇，作为一名长期工程师，你一路走来经历了哪些重大时刻，改变了你的思考和运作方式，并最终成就了现在的你？

So, I was at the Claude Code with Claude event I don't know, a month ago at this point and I went to your talk and I was just like, holy I got to get Fiona on this podcast. She's thinking so far ahead of where everybody else is going and where people are at with AI. So, you've been an engineer for 25 years. I was browsing your LinkedIn. You started at IBM of all places. Such a different place to be these days. And it's just insane how much the job of an engineer has changed over the past just like 2 years. It's like a completely different job. Like, people may forget 100% of code was written by humans not long ago. And now it's getting to 100% of code written by AI. As Boris famously said, coding is salt. Along these lines, there's just this tweet that you guys put out yesterday where you showed here's the tweet. Anthropic engineers on average ship eight times as much code per quarter as they did compared to 2021 to 2025. We'll show this chart on the screen. It's just like stable stable stable stable boom shooting off into the moon. So, it's just insane how much this role has changed. I'm curious about your kind of path as an engineer going living through this, having been an engineer for a long time, what have been kind of like the big moments along the way where it's shifted your way of thinking and operating that have led you to what you do now and how you operate now?

哦，我喜欢这种回顾过去的感觉。是的，在 IBM 做 DB2，操作系统服务团队。那时我在想，怎样才能成为栈中某个困难领域的专家？我真的认为越底层、越接近操作系统，就越硬核，学到的也越多。所以我很幸运得到了 IBM 的实习机会。但有趣的是，从 IBM 到微软是一个巨大的转变。在 IBM 我们用 Vim，没有 IDE。可能有过 Eclipse 的许可，但不知为何大多数人不用。我记得主要是 Vim 和终端调试。加入微软时，我天真到连 IDE 是什么都不知道，而且那时你并不能自己选团队。那是 2000 年代初。首先我要说，我很感激得到了实习和工作机会，因为 2000 年互联网泡沫破裂，我们那届毕业生很多公司都不招人或冻结招聘。所以微软给我 offer 时我非常幸运。他们让我做 Visual Studio，我甚至不知道 Visual Studio 是什么，因为我来自 Unix 背景。我记得我问，Visual Studio 这个名字，是不是一个更好的画图程序？我能看出经理脸上的表情：这怎么回事？

Oh, I love this kind of look back in time. Yeah, like IBM, working on DB2, the operating system services team. Like back then I was thinking, oh, how can I be like the like what's a hard area of the stack? And I really thought the lower level you go closer to the OS, then it's like more hardcore and you learn more. So that was a I was really fortunate to gotten into the IBM internship. But the funny thing was I would I think there's even a big shift from IBM to Microsoft. So at IBM it was I think Vim. Like I didn't have an IDE that we used. I think there might have been an Eclipse license, but for some reasons most of us didn't use it. So I remember it it was mainly like Vim and you know, like kind of terminal debugging. And then when I joined Microsoft, I mean this is how naive I was. I didn't even know about IDEs and such and back then you didn't really get to pick teams. Like this was early 2000s. Actually first off I should say I was so grateful that I landed the internship and the role cuz to take us all the way back in time the dot com bubble burst in 2000. And so for my graduating class like a lot of the companies weren't hiring or or were having freezes. So I'm so fortunate when Microsoft extended me an offer. And so they're like you're going to work on Visual Studio. I did not even know what Visual Studio was cuz I came from like a Unix school. So I remember to asking, oh, this cuz I was thinking, well, the name Visual Studio, I'm like, oh, is this like a a better paint program? And I could tell the look of my manager's face like, what is going on?

但后来它成了我职业生涯前 11 年的挚爱。那是我第一次使用 IDE。加入 Visual Studio 团队后，看到 IDE 有调试器，可以设置断点、做多线程调试，这对我来说总是令人兴奋，让我想到这种逐步的变化。所以这就是从 I beam 到 Visual Studio 的故事。我真正喜欢 Visual Studio 的是，我在编辑器团队，用 VS 编辑器来构建 VS 编辑器，这就是我对 dogfooding 热爱的来源。我记得我首先想为自己和队友创造愉快的体验。

But then it ended up becoming like the love of my life for the first, you know, 11 years of my career. But that was the first time I used an IDE. So joining the Visual Studio team, seeing, oh, wow, like here's an IDE with like debuggers and you can set breakpoints and do multi-threaded debugging. Like that was also always mind-blowing for me to think about the the stepwise change. So yeah, like that was kind of the story going from I beam to Visual Studio. And then what I really loved actually about Visual Studio is I was on the Visual Studio editor team. So I use a VS editor to build the VS editor and that's where my whole love of dog feeding comes from. Like I I remembered I wanted to first and foremost create a delightful experience not only for myself, but for my teammates.

因为如果我们回到那个时候，你还记得吗，Twitter 是什么时候出来的？是 2006 年左右吗？

Because also if we go back in that time, if you remember, when did Twitter come out? Like was it 2006 or something?

它几乎伴随了我的一生。

It's been around my whole life.

但在那时，社交媒体出现之前，大多数工程师也很难快速获得客户反馈。当然，会有用户研究会议，或者客户来拜访我们。但你得不到现在这种快速反馈。不过那时我很幸运，因为我在 Visual Studio 团队。我们自己内部就给了彼此很多快速反馈，因为团队里所有人都是 VS 的重度用户。

But back then, before social media, it was also harder for most engineers to hear fast customer feedback. For sure, there would be user research sessions or we would have customers visit us. But you didn't get the rapid feedback that you do nowadays. But back then I was so lucky because I was on Visual Studio. We ourselves gave each other so much rapid feedback because we were all heavy VS users on the team.

是的，当我在 Visual Studio 工作时，我们那时还用 CD 发货。在那之前，正因为如此，才有非常严格的截止日期，因为你必须确保软件准备好，交给生产部门，然后刻录到 CD 上，再放到货架上。后来另一个转变是我们开始能够在线发布软件。我觉得这很有趣，我在演讲中也提到了这一点。以前，工程时间是非常宝贵的资源，但你也面临非常严格的截止日期，比如把软件刻录到 CD 上。所以那时你会做更多的规划，因为你想确保在有限的时间里做到最好。这就是我们现在在 Claude 和 Copilot 身上看到的转变：编码不再是瓶颈。所以现在，就像你展示的那条推文和那张图一样。但现在的关键是这种转变发生在哪里？现在不仅是工程师，还有设计师、产品经理，Claude 团队里的每个人都会提交代码。所以当不仅更多人提交代码，而且来自不同学科，吞吐量又如此之高时，我们如何考虑验证？这就是我看到的另一个转变。

Yeah, when I worked on Visual Studio back then, we also shipped software on CDs. I mean before that, and that's why there were really hard deadlines because you had to make sure the software was ready for us to give to manufacturing, to then put on the CDs, for us to then put on the shelves. And then once that was another shift when we actually started to be able to ship software online. And I think that's the interesting thing, and I kind of mentioned this in my talk. It's before, when engineering time was a really precious resource, but you also had these really hard deadlines, for example, printing software on CDs. And so back then you would do a lot more planning because you just wanted to make sure, given the time you have, you make the best of it. And that's the shift that we're seeing with Claude and Copilot: coding is no longer the bottleneck. And so now, like you showed the tweet and that graphic. But now it's all about where has that shift happened? Now not only engineers, but we also have designers, PMs, everybody on the Claude team checks in code. So when not only more people check in code, but also different disciplines, and the throughput is so high, how do we think about verification? That's kind of this other shift that I'm seeing.

本期节目由本季赞助商 WorkOS 呈现。OpenAI、Anthropic、Cursor、Vercel、Replit、Sierra、Clay 以及数百家其他成功公司有什么共同点？它们都由 WorkOS 提供支持。如果你正在为企业构建产品，你一定体会过集成单点登录、SCIM、RBAC、审计日志等大型公司所需功能的痛苦。WorkOS 将这些交易障碍转化为即插即用的 API，并提供了一个专为 B2B SaaS 打造的现代开发者平台。实际上，我投资的每一家开始向高端市场扩张的初创公司最终都会与 WorkOS 合作。这是因为他们是最好的。无论你是试图赢得第一个企业客户的种子轮初创公司，还是正在全球扩张的独角兽，WorkOS 都是实现企业就绪和解除增长障碍的最快途径。它本质上就是企业功能的 Stripe。请访问 workos.com 开始使用，或者直接加入他们的 Slack，那里有真正的工程师等待回答你的问题。WorkOS 让你能够通过令人愉悦的 API、全面的文档和流畅的开发者体验更快地构建。立即访问 workos.com，让你的应用做好企业就绪准备。

This episode is brought to you by our season's presenting sponsor WorkOS. What do OpenAI, Anthropic, Cursor, Vercel, Replit, Sierra, Clay, and hundreds of other winning companies all have in common? They are all powered by WorkOS. If you're building a product for the enterprise, you've felt the pain of integrating single sign-on, SCIM, RBAC, audit logs, and other features required by large companies. WorkOS turns those deal blockers into drop-in APIs with a modern developer platform built specifically for B2B SaaS. Literally every startup that I'm an investor in that starts to expand upmarket ends up working with WorkOS. And that's because they are the best. Whether you are a seed stage startup trying to land your first enterprise customer or a unicorn expanding globally, WorkOS is the fastest path to becoming enterprise ready and unblocking growth. It's essentially Stripe for enterprise features. Visit workos.com to get started or just hit up their Slack where they have actual engineers waiting to answer your questions. WorkOS allows you to build faster with delightful APIs, comprehensive docs, and a smooth developer experience. Go to workos.com to make your app enterprise-ready today.

人们会想到工程师成长过程中的这些里程碑，但我们忘记了这些年来也发生了很多变革。虽然不像我们现在经历的这样，但就像 IDE、Visual Studio 一样。所以我喜欢你能提醒我们这些软件工程史上的时刻，它们极大地改变了工作方式。

People think about these milestones along the way of an engineer's journey and we forget there's also been a lot of transformation over the years. Not quite what we're living through, but just like IDEs, Visual Studio. So I love that you're reminding us of these moments in the history of software engineering that have changed the work in a big way.

也许先定下这次对话的主题。很多人都在想，软件工程、管理软件工程师、管理软件和产品团队在未来会是什么样子，而你正在亲身经历这一切。所以你提到了更关注验证，确保发布的代码质量确实很高并且能正常工作。那么让我问一个宽泛的问题，看看对话会走向何方。一个 AI 驱动的软件团队在 2026 年会是什么样子？

Maybe just set this theme that I want to have for this conversation. A lot of people are just wondering what software engineering, managing software engineers, managing software and product teams look like in the future, and you are living through that right now. So you mentioned this point about a more focus on verification, making sure the quality of the code being shipped is actually high and something that will work. So let me ask this broad question and let's see where this conversation goes. What does an AI-pilled software team look like in 2026?

因为角色正在爆炸式增长，它正在向这种构建者角色转变。我会说，每个人都开始成为构建者。我最近做的另一个转变是，我实际上有一个 Claude Code 远程会话，我把它加入到我们所有的代码库中。这样我就能完全了解每个人所做的工作。这个实例还可以访问我们所有的 Slack 频道，我可以查看我们跟踪的所有指标。所以每个月，我会说，‘嘿，你知道什么有趣吗？让我们回顾一下。’然后我们会一起做。我会分享我的 Claude Code 屏幕，我们进行一次 Claude Code 会话。内容就是，‘嘿，重点领域是什么？哪些产品发布了？它们表现如何？哦，反馈渠道是什么？’所以尽管以前我只会用这些会话来生成 PR 和修复 bug，但实际上我用这些会话是为了能够与我支持的人进行对话。

Because the roles are blowing up, it's shifting more to this builder role. Everybody starts being a builder, I would say. The other shift that I've recently done is I actually have a Claude Code remote session that I enlist in all of our repos. And so this way I have full visibility into the work that everybody's doing. And this instance also has access to all our Slack channels and I'll have access to how the metrics of everything we track. And so every month, I'll say, 'Hey, you know what's fun? Let's take a look back.' And so we'll actually do it together. I'll share my Claude Code screen and we do a Claude Code session. And it's just about, 'Hey, what were the focus areas? What were some of the products that got shipped? How did they do? Oh, what were the feedback channels?' And so even though before I would have just used these sessions to generate PRs and bug fixes, I actually have these sessions to enable me to have conversations with folks that I support.

详细说说。所以这是一种管理技巧，可以说，帮助人们不仅发布，而且更好地发布，并理解他们发布的东西是否有影响力。是这个意思吗？就是用 Claude 来掌握人们发布的所有事情，然后与他们进行对话。

Say more about that. So this is a management technique, let's say, to help people not just ship, but actually ship better and understand if they're shipping things that have impact. Is that kind of the idea here? Just use Claude to keep on top of all the things people are shipping and then make that a conversation with them.

完全正确。所以，除了发布这个动作本身，还要看它在市场上的表现如何？或者，嘿，我们是否引入了一些 bug？这没关系。我有句话，‘犯新的错误。’犯错误没关系，只要犯新的错误，这样我们就能不断学习，因为如果你目标是零错误，那可能意味着你行动不够快，或者过于谨慎。所以，有了 Claude，它还可以查看一些事情。例如，实际上，是的，我们刚刚在看，鉴于我们发生的一些事件，让我们纵观全局。我们能提炼出一个主题吗？对我们来说，什么是一个好的投资领域，不仅仅是当我们考虑质量的时候？我们是否看到任何可能存在差距的热点？我认为过去这要手动得多。如果回顾一年前，我不认为我能用 Claude 获得这些洞察。

Exactly. So yeah, outside of just the action of shipping, it's how did it do in market? Or hey, did we cause some bugs? And it's okay. I have this saying, 'Make new mistakes.' It's okay to make mistakes, just make new ones so that we're always learning, because if you aim to make zero mistakes, that probably means you're not moving fast enough or being a little bit too cautious. And so yeah, by having Claude, then it can also look at some things. For example, actually, yeah, we were just looking at, given some of the incidents that we have, let's look across all of this. Can we generate a theme? What's a good area investment for us, not just especially when we think about quality? Are we seeing any hot spots of where there could be a gap? I think that used to be a much more manual process, I would say. If I look back a year ago, I don't think I would have been able to have some of these insights with Claude.

是的，部分原因是有那个因素，而且人们当时发布得也没那么多，所以你只需要列一个小清单就行了。

Yeah, well, partly it's because there's that and also people weren't shipping as much, so you could just make a little bullet list.

这是我上个季度交付的东西。这个功能，那个功能，这个功能，那个功能。所以我觉得我听到的是，这似乎是跟上 8 mate 所有交付的唯一方法之一。所以这是一个很酷的话题，关于你如何找到方法来跟上这 8 倍的代码增长。还有什么其他方法帮助你和你的团队跟上并保持所有交付内容的质量？这显然是一个挑战，一个更大的挑战。

Here's the things I shipped last quarter. This feature, that feature, this feature, that feature. So I think what I'm hearing here is this is like one of the only ways to stay on top of all the things that 8 mate is shipping. So this is a really cool thread of just like how you found ways to stay on top of this 8x increase in code. What else has worked in helping you and your team stay on top of and maintain quality of all the stuff that y'all are shipping, because that's obviously a challenge, a bigger challenge.

是的，反馈渠道对我们来说非常重要，但我们也会收到大量反馈。例如，即使是我自己，通常我的早晨仪式是，你知道，我喝杯咖啡，然后查看反馈渠道，试着找出——如果我有一些创作时间——有什么我可以帮忙的，或者我能看到什么差距。那曾经是我每天早上都会做的事情。嗯，大概一两个月前，我们推出了 routines。这也完全改变了。现在我只是有一个 routine 来自动化这一切。而且，几乎就像以前我可以生成一些提示，但现在有了 routines，几乎就像有一个智能体帮我生成提示和 PR。例如，一个是‘嘿，关注这个反馈渠道，你知道，有哪些主题？’然后当我醒来时，我就有一个很好的摘要。甚至还有一些 PR 我可以查看和审查。

Yeah, and so definitely like the feedback channels are really important to us, but then we also get a lot of feedback. For example, even I myself, usually what my morning ritual would be, you know, I get my morning cup of coffee and then I look at the feedback channels and then I try to pick up what are, you know, if I have some maker time, what's something that maybe I would be able to help out or what I could like see some gaps. That just used to be something I would do every morning. And uh yeah, I think maybe a month or two ago we launched routines. And that's also completely changed. Like now I just have a routine that automates all this for me. And then there's also, it's almost like before I would, you know, be able to kind of like generate some prompts, but now with routines, it's almost like I'm, you know, having an agent help me generate the prompts and the PR. So for example, one is, 'Hey, keep a look on this feedback channel, you know, what are some of the themes?' And then like when I wake up, then you know, I have a really good summary of that. And then even some like PRs that I'll be able to take a look and review.

反馈渠道，这些反馈来自哪里？是像电子邮件、Twitter，还是各种组合？

And the feedback channel, where's that feedback coming from? Is that like emails, Twitter, or a combo of everything?

我们的反馈渠道肯定有很多来自内部，但也有电子邮件、渠道。实际上，每个人，当我们收到反馈时，即使是朋友发消息给我们，或者在 LinkedIn 或社交媒体上，我们都会把所有这些发布到 Slack 里。当然我们也有合作伙伴关系。所以我们为各种来源设置了不同的渠道。但这就是我说的，我需要 Claude 的帮助来跟上，因为进来的反馈太多了。

Our feedback channels are definitely like we have a lot from internal, but also like emails, channels. Actually, everybody, when we all get feedback, even on like when friends ping us or on LinkedIn or socials, we'll all actually like post all of that in Slack as well. And so we also have like of course partnerships. And so we have different channels for all the various sources. But that's what I mean of I need Claude's help to help me stay on top because there's so much incoming feedback.

明白了。好的，这很酷。所以，这是一种你建立的工作方式，用来跟上所有交付的内容，这是一种日常仪式/例行程序，你作为管理者查看人们对 Claude Code 和 Co-work 当前状态的看法，过去只是说，好的，有人去修这个，修那个。现在就像是，这是修复这个问题的 PR，看看。如果你想，我们随时可以交付。

Got it. Okay, so this is cool. So, this is a like a way of working that you've built to stay on top of all the stuff shipping, which is this kind of daily ritual / routine where you as a manager look at what people are saying about the current state of Claude Code and Co-work and used to just like okay, someone go fix this, go fix that. Now it's like here's the PR that will fix this thing, check it out. We're ready to ship it if you want.

没错。

That's right.

好的，显然对人们来说一个很大的挑战就是代码审查。我想象 Claude 也在做很多自己的代码审查。你最近有没有发现什么能让你的团队更快地交付他们确信很棒的东西？

Okay, like obviously a big challenge for people is also just code review. I imagine Claude is also doing a lot of its own code reviews. Is there anything there you've recently figured out that allows your teams to ship faster stuff that they are confident is great?

是的，老实说，想想我们去年甚至还没有 Claude 代码审查，这很疯狂。说到瓶颈，那是一个非常大的瓶颈，你知道，人类审查者。所以，对于需要深度专业知识的领域，我们肯定要确保有适当的人类审查。我认为对我们有帮助的是，我们越能自动化地检查‘好’的框架。当你给 Claude 一个框架来验证时，它非常擅长。所以，我提到过，最近我们更新了内容设计，加入了一个规模。我认为如果你有规范，把它们检入仓库，然后确保规范经常与代码保持同步。但我发现非常有效的是，任何时候你有一个‘好’的陈述，把它放到仓库里，然后 Claude 代码审查可以确保它仍然符合你设定的目标。

Yeah, and honestly, it's crazy when you think we didn't even have Claude Code Reviews last year. And so speaking of bottlenecks, that was a really really big bottleneck of, you know, the human reviewers. So, we definitely for the important like like areas that need deep subject matter expertise, we definitely want to make sure we have the proper you know, like human still reviewing. I would say what helps us though is the more that we can automate to almost check in the framework for what good looks like. Claude is very good when you give it a framework to validate against those frameworks. So, I had mentioned like you know our late you know like recently we just updated the content design to to have a scale in it. Like my like I and this is why like um I think if you have specs or like or like like check those into the repo and then make sure the spec also keeps up to date with the code like frequently. But that's what I found like works really well of any time you have like a statement of what good looks like, get that into the repo and then Claude code review can make sure it's still matching what you set up to do.

基本上，这就像是测试驱动开发的进化。

Basically, it's like the evolution of test-driven development.

是的，对于 TDD，我记得那是一件大事，天哪，大概在 2000 年代，先写测试，然后确保测试失败，再写代码。原则上这很好，但我知道我自己有点挣扎，因为几乎就像你必须先吃西兰花。这就是为什么我会说，啊，你必须先写这个测试，而我从交付和构建产品中获得了如此多的快感。所以，这很有趣。实际上，我在 Claude code 上修复的第一个 bug，我记得我问 Claude：‘嘿，我想做测试驱动开发。帮我先写测试。确保它失败，然后我们再做修复，然后测试通过。’而过去测试生成就像我必须支付的税。现在它自动化了，你甚至可以重新审视这些已经存在一段时间的原理，但现在它们可能更高效，因为你有模型可以为你做更多的工作。

Yes, for TDD it's cuz I remember that was like a big thing, my gosh maybe like in the 2000s of write the test first and then you can like make sure the test fails then you do actually the code. In principle, it's really good but I think I know I remember that I myself struggling a bit because it was almost like you have to eat the broccoli first. That's why I'm like ah you have to write this test first and I just get so much thrill out of shipping and building product. So, that's funny. Actually, the first bug I fixed on Claude code I remember asking Claude, 'Hey, I want to do test-driven development. Help me write the test first. Make sure it fails and then we'll actually, you know, do the fix and then now that test pass.' And the fact that that used to be, you know, like that test generation used to just be this tax that I remember having to pay. Like the fact that that's now automated and you can even revisit all these principles that have been around for a while but now they actually might be even more efficient just because you have the models that can do more of the work for you.

是的，这太不公平了。它直接先帮你写测试。

Yeah, like that's it's so unfair. It just writes the test for you first.

所以，关于构建者这一点，你演讲中我最喜欢的一张幻灯片是，我想问你关于你招聘什么样的人以及你在人们身上寻找什么。所以，我会读一下你在那里说的，我想在这里听到更多。所以，你现在招聘时寻找的两种类型是：有产品感的创意构建者，以及处理困难部分的深度系统专家。

So, on this point of builders, one of my favorite slides from your talk that I want to ask you about is who you are hiring and what you look for in people. And so, I'll read what you said there and I want to hear more here. So, the two profiles that you now look for when you're hiring are creative builders with product sense and deep systems experts for the hard parts.

是的，深度专业知识。例如，当我刚加入 Claude Code 时，我们有非常棒的产品通才。然后我意识到，哦，我们缺少有系统背景的人。所以，那绝对是我们需要更多有系统和分布式系统专业知识的人的领域。所以，我认为，无论哪个部分，都是信任但验证。模型非常好，但肯定还有很多领域需要验证。所以，无论哪里需要深度专业知识，我认为那是一个仍然需要投资的领域。另一个是产品感，几乎就像梦想家。

Yeah, the deep subject matter expertise. Like for example, when I first joined Claude Code, we had really great kind of like product generalists. And then I realized, oh, we were missing folks with systems background. And so, that was definitely an area that we needed more folks with kind of like systems and distributed systems expertise. And so, I would say whatever are the parts that it's all about trust but verify. The models are really good, but there are definitely a lot of areas that still need verification. And so, wherever you need the deep subject matter expertise, I would say that's, you know, an area to definitely still invest in. And the other one is kind of like the product sense works almost like the dreamers.

这些人通常会说：‘哦天哪，我对某个产品充满热情。’他们有了想法，就去构建，然后不断查看反馈、迭代、打磨，确保产品体验令人愉悦。就像端到端地拥有那个产品。这就像另一项技能，在 Claude Code 上对我们帮助很大。

Like these are folks that usually will be like, 'Oh my gosh, I'm really passionate about a product.' And they have an idea, they build it, and then it's always like looking at the feedback, and then iterating, and polishing, and making sure that the product is a delightful experience. Like owning that product end-to-end. That's like another skill set that served us really well on Claude Code.

这非常共鸣。有个词叫‘雄心’，我不知道你是否用了，但这是你说话时我想到的。最近在播客和其他工作中，这个词经常出现。前几天我和一位 10 倍工程师聊天，他说：‘我以前听到一个功能想法，有人说“嘿，我们应该做这个”，我会说“不，那太难太复杂了”。但现在我会说“不，不，这完全可能。我只要让 Claude Code 去做就行。”它就直接完成了。这是一种思维转变。他现在意识到，关键在于你能有多雄心勃勃？理论上现在一切皆有可能。问题在于你能想得多大、多雄心勃勃，而不是‘好吧，都是些愚蠢的小功能和需要我解决的事情。’这有共鸣吗？这是你思考的吗？

This super resonates. There's this word ambition. I don't know if you used it, but that's what I thought of as you were talking. That's been coming up a bunch recently in the podcast and in other work I've been doing. There's this 10X engineer I was talking to the other day, and he was just like, 'I used to like I heard about a feature idea, like I have someone's like, 'Hey, we should build this.' And I was like, 'No, that's really hard and complicated.' And he's like, 'But now I'm like, no, no, that's so possible. I just ask Claude Code to do it.' And it just does it. And it's this whole mindset shift. And he's just realizing now it's about how ambitious can you be? Like everything is now possible in theory. Now it's about how ambitious and how big can you think versus just like, 'Okay, it's all these stupid little features and things I have to unblock.' Does that resonate? Is that something that you think about?

是的，实际上我昨天刚和一位工程师聊过，他本身不是移动端工程师，但我们确实需要更新这个功能，使其也有移动端版本。这太神奇了。他说：‘你知道吗？’因为很常见，你可能会想：‘等等，但我不是安卓专家。’但现在，多亏了 Claude，我实际上可以有一个伙伴，也能在移动端做这件事。所以这绝对有共鸣。就像它提升了每个人能力的上限。

Yeah, so actually I was just catching up with an engineer yesterday, and actually is not a mobile engineer by trade, but we really needed to update this feature to also have a mobile footprint. And it was just amazing. Like he's like, 'You know what?' Because it's common, you might think, 'Wait, but I'm not like an Android expert.' But now, thanks to Claude, actually I can actually have a partner and actually also do this on the mobile surfaces. And so that definitely resonates. It's like it's lifted the ceiling of what anyone is able to do.

让我顺着这个话题。随着角色发生了如此巨大的转变，有些人在蓬勃发展，有些人则非常沮丧、不开心、挣扎、抗拒。你看到那些做得很好、适应并蓬勃发展的工程师，与那些沮丧、不顺利的工程师（甚至工程之外的人）之间有什么共同点？

Let me follow that thread. As the role has transformed in such a crazy way, some people are thriving, some people super frustrated, unhappy, fighting, resisting. What do you see common across the people that are doing really well, the engineers that have adapted and are thriving, versus the engineers and, you know, even outside engineering that are just like frustrated and having a bad time?

我会说成长心态真的非常有帮助。实际上，即使在 AI 工具出现之前，我就发现它非常宝贵。我学到了很多。实际上是从微软转到 Meta 的时候，那是我第一次真正——第一年我心想：‘哦，这就是成长心态的真正含义。’它其实就是不断学习的概念。曾经让你走到今天的东西，可能不再适合你。但这真的很难，因为当然，我们每个人都是通过某种方式或操作才达到现在的状态。所以有时想到‘等等，你要求我改变让我成功的东西’会有点可怕。所以我认为成长心态对我很有帮助，我也注意到它对其他人也有帮助。比如总是带着好奇心，总是能够学习。至于沮丧，我认为有时我也看到一点恐惧。所以我的建议是——至少在生活中——因为我们都有恐惧，恐惧当然是进化的一部分——我没学过人类学，但我觉得这有道理，对吧？它帮助我们确保生存，不被大型捕食者吃掉。但对于任何让你恐惧的事情，我的建议是迎难而上，问自己：‘好吧，我能做些什么？什么在我掌控之中？’因为有时沮丧来自恐惧，感觉一切都不受控制，事情发生在自己身上。所以如果你思考：‘好吧，什么在你掌控之中？’不是‘事情发生在我身上’，而是‘事情为我而发生’？然后你能做些什么来改变？我觉得这很有帮助，因为如果不这样，恐惧加上一切失控的感觉会非常令人沮丧。我实际上记得高中时——有趣的是，当我们回到 IBM 的时候。高中时，我其实没有进入计算机科学或工程领域。我真的很想成为一名视觉艺术家。这要追溯到很久以前。那时电脑非常贵。我实际上连电脑都没有。我第一次接触电脑是在九年级，我想是在高中。我不知道现在高中还有没有这种事。我的高中有打字课，就是学习如何用键盘打字并变得熟练，那是我的第一次。然后下一节课可能是 HTML 编程。总之，我之所以爱上它，是因为——我喜欢艺术的地方在于创造，如果你有想法，你可以去创造并讲述一个故事。然后我意识到：‘哦，计算机和编程让我能够做到这一点。’所以无论如何，我试图快速补上所有科学课程以便进入大学，但我有这种恐惧：‘哦，但我怎么负担得起工程学院的学费？’这是一个巨大的未知。我在安大略长大，所以我很感激。我知道有一个安大略学校援助计划，我想叫 OSAP，我非常感激，但我不知道它能覆盖多少学费或生活费，这完全未知，而且还有一年时间。我记得我在想：‘好吧，我能做些什么？’然后幸运的是，加拿大国家银行在我们高中贴了一张传单，上面写着：‘嘿，我们正在招聘高中实习生当银行出纳员。’我记得：‘哦，那——’当然是最低工资，但我认为那可能是一条生命线。但有趣的是，高中我最讨厌的课是会计，所以我根本不知道自己是否擅长，但我还是报名当了银行出纳员，结果那是一个很棒的决定，因为我整个夏天都在工作，攒了钱，然后周末也能当出纳员。所以周一到周五上学，周六当出纳员，这最终成了我的生命线，让我能够支付所有学费。

I would say that a growth mindset really, really helps. Like actually even before AI tooling, I found that has been just so valuable. And I learned that a lot. Actually it was the shift from Microsoft to Meta. That was where I first real — that first year I'm like, 'Oh, this is what having a growth mindset really means.' It's really this concept of always be learning. Be also what served you to get you to this point may not serve you no longer. But it's really hard because, of course, everybody like we all, you know, we've all gotten to the state by acting or, you know, like operating in a certain way. And so sometimes it is a little bit scary to think, 'Wait, you're asking me to change what has made me successful.' And so I would say the growth mindset has really served me well and I think it's also served others well that I notice. Like always leaning in with curiosity and always being able to learn. And then in terms of the frustration, I think sometimes I also see a little bit of fear. And so my advice there is at least this is how just in life — because we all have fear, and fear is of course an evolutionary thing — I didn't study anthropology, but I think it makes sense, right? It helps us make sure we were able to survive and not get eaten by larger predators. But for anything that there is a fear, my advice is kind of lean in and ask, 'Okay, is there something I can do about it? What is within my control?' Because sometimes the frustration comes from fear and feeling like everything is outside of my control and so it's happening to me. And so if you think about, 'Okay, what is in your control?' Instead of happening to you, is it happening for you? And then what's something that you might be able to do and change? I felt that's been helpful because if not, it is super frustrating to have the fear and then feeling like everything's outside of your control. I actually remembered when I was in high school — it's funny when we were going back to IBM. When I was in high school, I actually didn't go into computer science or engineering. I really wanted to be a visual artist. And this is how far back we go. Back then computers were really expensive. I actually didn't even have access to a computer. My first computer with access was grade nine I think in high school. I don't even know if this happens in high school anymore. My high school had a typing class, you know, just to learn how to type on a keyboard and learn to be really proficient, and that was my first time. And then the next class was maybe like some HTML programming. So anyways, the reason why I fell in love with it was — what I love about art is creating and being able, if you have an idea, you can go ahead and create and tell a story. And then I realized, 'Oh, computers and programming enable me to do that.' So anyways, I tried to really fast make up for all the science classes for me to get into university, but I had this fear of, 'Oh, but how will I afford to get into an engineering school?' And it was this big unknown. I grew up in Ontario, so I was very grateful. I knew there was an Ontario school assistance program, OSAP I think it's called, which I'm very grateful for, but I didn't know how much of that would cover my tuition or expenses, and it was just this unknown, and it would be like a year out. And I remember thinking, 'Okay, what can I do about it?' And then as luck would have it, the National Bank of Canada just posted this flyer in our high school saying, 'Hey, we're hiring high school interns to be a bank teller.' And I remembered, 'Oh, that —' and of course it was going to be minimum wage, but I thought that could be a lifeline. But it was funny because the class I hated the most in high school was accounting, so I don't know if I'd be any good at it at all, but I signed up to be a bank teller, and that ended up being such a great decision because I worked all summer, saved up, and then I was able to work as a bank teller on the weekends. So I would go to school Monday to Friday, and then on Saturday I'd be a bank teller, and that ended up being this lifeline that enabled me to pay for all my school expenses.

嗯，你知道，我们聊过 2000 年的互联网泡沫破裂，那时候公司不怎么招实习生，实际上我继续做了两年的银行出纳。但那是我想做的一个我能控制的行动，来对抗我的恐惧：如果我真要走上这条路，我甚至不确定自己能不能付得起学费。所以，这大概是我另一个建议：成长型思维。如果你感到沮丧或焦虑，看看有没有一个你能控制的行动可以采取？因为我觉得有句话叫：做点什么。如果你不害怕，你会做什么？实际上，那是我以前最喜欢的两句话：如果你不害怕你会做什么，以及偶尔做点吓人的事，因为那通常也是我们成长的方式。我发现，当你非常擅长并专业地做某件事时，你处于巅峰，效率最高，但如何继续成长呢？就是去做一些你以前没做过的吓人的事，是的，你会经历低谷，因为你需要学习。但这就是你不断推动自己学习的方式。

Um and you know, we talked about the year 2000 dot com crash, then when folks weren't hiring as much interns, actually I continued being a bank teller for two years. And so, but that was the one action I thought I could take that was within my control to try to counter this fear I have of if I'm really going to go down this path, I don't even know if I could have afforded to go to school. So, that's probably my other advice of like growth mindset, and the source of frustration or anxiety, if it's coming from, you know, see is there some one action that's within your control that you can take? Because I think there's a saying: do something. What would you do if you're not afraid? Actually, those were my two favorite sayings before: what would you do if you're not afraid, and do something scary once in a while because that's also usually how we grow. I found that when you're really good and professional at what you do, you're kind at peak, maximum efficiency, but then how do you keep growing is you then do something scary that you might not have done before, and yeah, you will have a dip because you need to learn. But that's kind of how you keep pushing yourself to learn.

我在这个播客里用得最多的一句话是：你害怕的那个洞穴里，藏着你寻找的宝藏。

The quote that I have probably used the most on this podcast of all quotes is: the cave you fear contains the treasure you seek.

哦，我喜欢这句话。

Oh, I love that.

是的，太对了。就像，我忘了是谁说的，但最吓人的事情就像指南针，指向你应该做的事。

Yeah, and it's so true. Just like, I forget who put this, but the thing that is scariest is like a compass towards what you should be doing.

嗯哼。我要偷走你的名言了。

Mhm. I'm going to steal your quote.

是的，请便。你知道，别做所有吓人的事，比如别跳崖，但在职业选择上，这大概是个好选择。

Yeah, please do. Like, you know, don't do all the scary things, like maybe don't jump off a cliff, but maybe in career moves it's probably a good choice.

那么，沿着这条路，我知道有一件事对你很重要，我也在想，那就是正在形成的差距：一边是那些拥抱 AI、做得很好的人，另一边是那些没有的人。对于可能在这个新兴世界中被落下的人来说，这是一个可怕的时期。我知道你花了很多时间在小企业上，你的一大热情就是帮助人们学习如何在工作中使用 AI。谈谈你是怎么想的，以及我们应该考虑什么来帮助人们基本上不掉队。

So, kind of following this path, something that I know is important to you, something you think about that I also think about is this kind of gap that is forming between people that are just like leaning into AI, killing it, doing super well, and then people that are just like not. And this is like a scary time for people that may be left behind in this new world that is emerging. I know you spend a lot of time with small businesses. That's a big passion of yours to help people learn how to use AI in their work. Talk about just like how you think about that and what maybe we should be thinking about to help folks, you know, stay not fall behind basically.

哦，我喜欢这个话题。是的，这是我的热情话题之一，因为我提到过，我在加拿大长大。我小时候搬去那里，出生在香港。所以我不会说英语，我父母又一直工作。所以我奶奶，她是任何人能拥有的最好的奶奶。我知道每个人都觉得自己的奶奶最好，但我真的很幸运。我有最好的奶奶。她搬来和我们住，在我父母工作时照顾我。但我们俩都不会英语，但我通过上学和同学交流学会了英语。当我想到我奶奶时，她在一个新国家感到非常孤立，那时候不像现在这么方便。但有一个夏天，我们碰巧找到一家小毛线店，店主是一位会说粤语的女士。于是那个夏天我们每周都去那家毛线店，我奶奶找到了她的编织圈子，然后我好像学会了做 macrame，顺便说一句，我觉得 macrame 正在复兴。看到什么流行总是很有趣。

Oh, I love this. Yeah, it's one of my passion topics because I kind of mentioned, you know, like growing up in Canada. I moved there when I was a kid. I was born in Hong Kong. So, I didn't speak any English and my parents had to work all the time. So, my grandma, who is the best grandma that anyone could have ever asked for. I know everybody thinks their grandma's the best, but I really was so lucky. I had the best grandma. She moved with us just to take care of me while my parents were working. But neither of us spoke English, but I was able to learn how to speak English by going to school and speaking with classmates. And when I think about my grandma, it was very alienating for her to be in a new country where, you know, back then it wasn't as walkable. But one summer I remembered we just happened to find this little yarn shop that was owned by a lady that also spoke Cantonese. And so that became every week to this yarn shop this summer and my grandma found her knitting circle and then I think I learned how to do macrame, which I think is having a comeback by the way. It's always funny to see what's...

Macrame 要复兴了？

Macrame coming back?

Macrame，我觉得是的。你是在 Lenny 的播客上第一次听到的。我觉得 macrame 要复兴了。

Macrame I think yeah. You heard it here first on Lenny's podcast. I think macrame's coming back.

好吧。

All right.

但那可能是我热爱的来源。我想，哇，这个小企业创造了这么棒的社区感。我很幸运，和我喜欢的所有小企业都成了朋友。所以这就是热情的来源。然后事情是这样的：我用 Coda 来管理自己的商务旅行报销。我不知道为什么，我真的不喜欢做商务报销。当我用 Coda 时，它就像魔法一样。我想，所有这些我不喜欢做的事，Coda 都替我做了。然后我想，等等，我所有的朋友，说实话，小企业主们真的非常努力。他们工作极其辛苦，而且有时利润率很低。所以我想，如果 Coda 能帮我处理小小的商务旅行报销，那对他们来说会非常有用，因为我看到我的朋友有时坐在酒吧里，面前堆着一叠账单，他们做的就是开票和报销。我觉得没人真的喜欢做这些。所以这就是起因。然后我记得帮他们中的几个上线。看着他们走完我们的上线流程，也让我很谦卑。实际上，它发现了一些很好的 bug。所以这真是双赢，而且我也很开心，因为他们用 Coda 的方式我从来没想过，因为我只专注于它处理 PDF 和发票有多棒。然后，你知道，我一个朋友开了两家餐厅，她说：‘天哪，我这个文件夹就像一个杂物抽屉，基本上我们的文档文件夹就成了一个杂物抽屉，或者下载文件夹就像个杂物抽屉。她说：‘我知道里面有几份菜单，但我找不到。’我说：‘那我们问问 Coda 吧。’所以我们让 Coda 访问目录，找到了菜单。然后她用了一种非常独特的方式。她说：‘我想确保我对本地人和游客都保持合理的价格。’所以她说：‘嘿，Claude，看看我这个地区的同类菜系。’然后它返回了很酷的几乎像市场分析一样的东西。她说：‘嘿，我其实刚去过西雅图那家餐厅，味道不错。’所以我每次都能学到新东西。而且，他们也给了我很好的反馈。

But that was probably where my love came from. I'm like oh wow this little small business created this wonderful sense of community. And I've been really fortunate to become friends with all the small businesses that I love. So that's kind of like where the passion comes from. And then what happened was I was using Coda for my own business expensing travel. I don't know what it is. I really don't like doing business expensing. And when I was using Coda, it was magic. I'm like all these things that I don't like to do like Coda is doing for me. And I'm like wait a minute all my friends and honestly small business owners they really bust their butt. Like they work incredibly hard and they use, you know, sometimes might be operating on really small margins. And so I thought if Coda is so good at helping me do my little business travel expense, this would be huge for them because I see my friends sometimes sitting at the bar with stacks of bills and all they're doing is invoicing and expensing. And I think nobody actually really likes to do it. So that's kind of where it came from. And then yeah I remembered helping a couple of them onboard. And it was also very humbling to see them go through our onboarding flow. Actually, it found some really good bugs. So, it was really like a win-win, but it was also delightful for me because they also use Coda in ways that I wouldn't have thought about because I was all fixated on look at how it is amazing with PDFs and invoice. And then, you know, one of my friends who runs two restaurants, she's like, 'Oh my gosh, this folder I have is like a junk drawer of like it's basically our documents folder just becomes this junk drawer of every or downloads like just a junk drawer. And she's like, 'I know I have a few menus in here and I can't find it.' And I'm like, 'Well, let's ask Coda.' So, we gave Coda access to directory, found the menus. And then, she uses it in a really unique way. She goes like, 'I want to make sure I keep my prices reasonable for locals and tourists.' So, she goes, 'Hey Claude, look across my style of cuisine in this area is a comparable.' And it came back with really cool almost like market analysis. And she goes, 'Hey, I actually just went to that restaurant in Seattle and that was pretty good.' So, I learn something every time. And yeah, they've been giving me great feedback as well.

那么问题就是，我们如何把这种好处传播给每个人？因为如你所见，很多人会说：‘我没时间搞这个。’或者‘我讨厌 AI。’他们就想忽略它。

So, the question then is just like how do we spread this to everybody? Because as you see, you know, there's like a lot of people are just like, 'I don't have time for this.' Or 'I hate AI.' It's just like I want to ignore it.

是像聊天一样，只是分享例子吗？你怎么看？如何在这个问题上取得进展？

Is it like talking, is it just talking about this sharing examples? What do you think? How do you make a dent in this problem?

对我们所有人来说，尤其是你的听众，他们可能对 AI 非常着迷。如果他们的社区或家人中有人，我会从你真正觉得 AI 工具给你带来有意义生活改变的事情开始。然后看看那是否能成为对话的开端。对我来说，AI 是一种工具。它就像黑暗中的光。我也完全理解令人沮丧的部分。但对我来说，知识就是力量。你必须学会如何使用这些工具，因为它实际上可以成为光明与黑暗方程中光明的那部分。所以我认为这是我希望大家都能帮忙的事情。无论是社区成员还是你真正喜欢的生意，想想，“嘿，你有没有……”一开始有点尴尬。我记得我第一次联系朋友时，我不太和他们谈论我的工作，但我说，“嘿，我算是做 AI 的。我能给你看看 Codoxer 能做什么吗？”这对我来说听起来都不自然，但最后我们玩得很开心。所以我希望有这样的对话开端。我只是想确保我们继续分享知识，让工具变得公平，因为如果不这样，我担心差距会越来越大。

For all of us, especially your listeners who are probably very AI-pilled, if there's anyone in their community or family, I would start with something that you really felt has made a meaningful life change for you with AI tools. Then see if that's a conversation starter. For me, AI is a tool. It's the whole light in the dark. I totally understand the frustrating part too. But for me, knowledge is power. You have to learn how to use the tools because it could actually be the light part of that light and dark equation. So I think that's something I'd love everybody's help with. Whether it's a community member or a business you really like, think, "Hey, have you ever..." It's a little awkward to start. I remember when I first reached out to my friends, I don't talk about what I do with them a lot, but I said, "Hey, I kind of work in AI. Can I show you what Codoxer can do?" It sounds unnatural even for me, but we ended up having a lot of fun. So I'd love that conversation starter. I just want to make sure we keep sharing the knowledge and making the tool equitable, because if not, I'm concerned the divide grows larger and larger.

我也是。我发现像你说的分享用例非常有力。前几天我正好用 Codoxer 填写我儿子的夏令营表格。在推特上分享后，很多人说，“哦，哇，我没想到这个。”是啊，就是这些你没想到的小事，Codoxer 和 Claude 都能做。顺着这个思路，说到 Codoxer，Anthropic 在发现这些巨大机会方面非常早，领先于其他人。比如编程，遥遥领先。意识到这是一个巨大的市场。不管是有意还是无意，就像，“哇，这可能是历史上最大的新商业机会。”然后 Codoxer 就是一个很好的例子，专注于知识工作。让我们解决所有知识工作吧。为什么不呢？远远领先于其他人。另一个要素是对模型个性的关注，你们很早就意识到这有多重要。不仅是为了体验，也是为了模型的智能和成功。你认为 Anthropic 和团队做了什么不同的事情，让你们能够发现这些机会，并在其他实验室之前大力投入？

Me too. I find that sharing use cases as you said is so powerful. I was just using Codoxer the other day to fill out my son's camp forms. And just sharing that on Twitter, a lot of people were like, "Oh, wow, I didn't think about that." Yeah, it's just these little things you don't think about that Codoxer and Claude can do. Kind of along those lines, speaking of Codoxer, Anthropic has been super early on uncovering these really big opportunities ahead of everyone else. For example, coding. So far ahead. Realizing this is a huge market. Whether it was intentional or not, it was like, "Whoa, that's maybe the biggest new business opportunity in history." And then Codoxer is a great example of leaning into knowledge work. Let's just solve all the knowledge work. Why not? So far ahead of everyone else. Another element is the focus on the personality of the model, something you all were very early on about how important that is. Not just for the experience, but also for the intelligence and success of the model. What is it that you think Anthropic and the teams do differently that allows you to uncover these opportunities and then go big on them before other labs?

嗯，我没在其他实验室工作过，所以不确定他们如何运作，但我会分享。在 Claude Code 团队，我们也关注潜在需求。我们很幸运有编程这个用例，因为我们很多人都是自己的第一批客户，能够进行非常快速的反馈。所以我认为潜在需求是关键。例如，对于 Codoxer，我们注意到很多不一定是程序员的人也在使用 Claude Code。我们能改善那个体验吗？这实际上在 Anthropic 之外，在我参与过的所有不同产品中都很有用。有趣的是你提到 Claude for small business。在我几次访问之后，我们最终推出了 Claude for small business。这很酷，因为这不是我的主意，但我也注意到了。当我和他们合作时，他们问，“哦，它有这个插件吗？”我说，“我觉得有，”然后我们不得不去搜索。所以现在 Claude for small business 把一切都捆绑在一起，在 Codoxer 内部你只需一个开关。有一个很棒的团队与小企业进行了合作会议，可能发现我们可以在这里提高效率，或者改善体验。所以我会说，始终倾听反馈并迭代，以提供愉快、可靠、高质量的体验，同时也要留意其他出现的用例，看看我们是否也能改善那个体验。在软件领域，我学到客户会以你意想不到的方式使用你的产品，无论好坏。所以最好的方法就是迭代、学习，并保持与反馈的紧密联系。

Well, I haven't worked in other labs, so I'm not sure how they operate, but I'll share. On the Claude Code team as well, we keep an eye on latent demand. We're very fortunate with coding as a use case because so many of us were our own first customers, and we're able to do really rapid feedback. So I think latent demand has been key. For example, with Codoxer, we noticed a lot of folks who weren't necessarily coders were using Claude Code. Can we make that experience better? That's actually served me well even outside of Anthropic in all the different products I've worked on. And it's funny you mentioned Claude for small business. After I had a few visits, we ended up launching Claude for small business. That's really cool because it didn't come from me, but I noticed it too. When I was working with them, they asked, "Oh, does it have this plugin?" I said, "I think it does," and then we had to go search for it. So now Claude for small business bundles it all up, so inside Codoxer you just have a little toggle. There was a wonderful team that did co-work sessions with small businesses and probably found we could have an efficiency gain here, or make the experience better. So I would say always listen to feedback and iterate to make a delightful, reliable, high-quality experience, but also keep an eye out for other use cases that are popping up and see if we can make that experience better too. In software, I've learned that customers will use your product in ways you didn't intend, for good or bad. So the best way is to iterate, learn, and stay close to feedback.

潜在需求。这个词在这个播客里出现过很多次。

Latent demand. That term has come up a bunch on this podcast.

是的。

It's on there.

可能有点道理。所以本质上就是密切关注你可能没有预料到的或正在出现的行为。然后大力投入，探索它，构建一些东西。

Might be something there. So essentially it's just watching closely for behavior that you may not have expected or that is just kind of emerging. And then just going big on that, exploring it, building something.

是的。并且有一个假设。因为当你看到人们费尽周折让某件事工作时，你能否让那个体验更顺畅、更好？

Yeah. And having a hypothesis. Because when you see people jumping through hoops to make something work, can you actually make that an even smoother and better experience?

回到你们团队的运作方式，你们处于可能性的边缘。工程的角色已经发生了很大变化。我很好奇你认为工程领域下一个前沿是什么，特别是它将如何改变。是智能体集群吗？还是别的什么？工程师运作方式的下一个重大转变是什么，你们已经在研究或实施，或者正在开始发生？

Coming back to the way your teams operate, you guys are so at the edge of what's possible. The role of engineering has changed so much. I'm curious what you think is the next frontier of how engineering in particular is going to change. Is it fleets of agents? Something else? What's the next big shift to how engineers operate that you're already working on or implementing, or that's starting to happen?

我会说我们正在更多地转向异步。所以你说得对，智能体集群，这就是为什么例程如此有趣。我以前同步地做一个提示，然后异步地启动不同的提示。但现在我可以有一个例程，实际上为我生成这些提示。所以几乎就像抽象层次在不断提高。我希望我有一个水晶球来看看这会是什么样子。

I would say we're shifting more towards async, asynchronous. So to your point, fleets of agents, that's why routines is so interesting. I used to do a prompt synchronously, then kick off different prompts asynchronously. But now I can have a routine that actually generates these prompts for me. So it's almost like the level of abstraction keeps pulling up a bit. I wish I had a crystal ball to see what this will look like.

一年后我们再回顾，应该会很有趣。

It'll be fun actually for you and me to revisit a year from now.

不，我想多听听这个。帮我们理解一下什么是 routines，什么是异步？你写一个 prompt，然后它就自动执行并立即写出结果？说说这到底是什么样的。

No, I want to hear more about this. So help us understand what is routines and then what is asynchronous? You're writing a prompt and it just kind of goes off and writes it immediately? Talk about what this actually looks like.

是的，routines 就是你可以……如果你还记得我讲过以前我常做的事：早上喝杯咖啡，然后说‘嘿，帮我看看这个 Slack 频道’。但现在我设置了一个 routine，每天早上固定时间运行，说‘嘿’。

Yeah, so routines is like how you can... So if you remember I was talking about what I used to do: always wake up with my morning cup of coffee and say, 'Hey, look at this Slack channel for me.' But now I have a routine that I set to run every morning at a certain time to say, 'Hey.'

嗯，没错。但它实际上能代表你去启动智能体。因为以前可能是‘哦，你可以用 cron 任务来自动化’，但现在变成了‘嘿，看看这些反馈，如果你发现一些 bug，有哪些可以快速修复的？’然后它会启动任务，我醒来后就有 PR 可以审查。而以前更像是不同的智能体，我仍然在想‘好吧，现在我用这些信息做什么？’所以这是一种更高层次的抽象：‘好吧，我怎样才能写一个 routine，它也能为我生成 prompt 来启动不同的智能体？’所以我认为我们会朝着这种异步工作方式发展。

Mhm, that's right. But then it's able to actually go and kick off agents on your behalf. So that's because before it would be like, 'Oh, you could do a cron job to automate,' but now it's like, 'Hey, look at these feedback, and if you're seeing some bugs, what are some polish fixes you might be able to knock out?' And then it would go kick off, and then I wake up and end up having PRs that I could review. Versus before, which was still more of a kind of different agents, and then I'm still thinking about, 'Okay, now what do I do with this information?' So it's that higher level abstraction of, 'Okay, now how can I actually write a routine that also basically does prompts for me for spawning different agents?' So I think we'll move more towards that kind of asynchronous style of working.

太有趣了。所以从某种意义上说，作为管理者，你每天都要做这些事情，而你说的就是你可以设置这些 prompt，每天检查你本来要做的事情：项目进展如何？哪些落后了？我需要解决什么阻塞？谁遇到了困难？如何修复一些细节？所以这里的想法是，把你作为管理者每天要做的事情写下来，让 Claude 替你完成，然后向你展示‘这是我在做的，这是需要审查的’。

So interesting. So like in a sense as a manager, you have these things you do daily, and what you're saying here is you can set up these prompts that kind of check in every day on the things you would be doing: how are the projects going? What's falling behind? What should I unblock? Who is struggling? How do I fix some polish? And so the idea here is kind of write these things that you almost do as a manager daily and have Claude essentially do them for you, and then show you, 'Here's what I'm doing, here's what there is to review.'

然后甚至在某些时候给予更多自主权：‘你知道吗，放手去做吧。’例如，如果验证结果很好，就去做。

And then it's even like giving even more autonomy at some point: 'You know what, go for it.' For example, if the verification is really good, go for it.

看，所以你给了它一点自由去做更多。是啊，太有趣了。这让我想起……说到‘放手去做’，我本来没打算谈这个，但我刚看了 Tyler Cowen 关于现状的精彩演讲。不知道你认不认识 Tyler Cowen——非常聪明的经济学家，有个播客。他提到现在大家都在说，做得最好的人，他的说法是‘主动性’。他们有主动性。另一个词是‘能动性’。是不是这样……人们经常听到：那些做得最好的人最有主动性，最积极主动，最有能动性。这有没有让你想到人们可能需要思考或改进什么？

See, so you give it a little bit of freedom to do more of this. Yeah. That is so interesting. It reminds me... speaking on this idea of 'go for it,' I don't like... I wasn't planning to talk about this, but I just watched Tyler Cowen's awesome talk about just what's happening. I don't know if you know Tyler Cowen—really smart dude, economist, has a podcast. And he just had like... there's so much talk of the people that are doing best in this world; his term is 'initiative.' They have initiative. Another term people use is 'agency.' Is that something... just like you know people hear this a lot: the people that seem to be doing best are taking the most initiative, getting the most proactive, have the most agency. Does that spark any thoughts to you about what people may need to think about or improve on?

实际上，就是这个词——能动性。这是我们在 Claude Code 和 Code Work 团队非常看重的。但有趣的是，我同时强调高能动性，因为我们的理念是：‘嘿，这里有个问题’，然后团队里的每个人都会有解决问题的想法。所以这是高能动性，同时我们也说高能动性伴随着高责任感。所以关键在于确保大家有自由去发挥。但同时也要问：‘那么，对应的责任是什么？’这又回到了‘你试图解决的假设是什么？’所以我认为，能动性和责任感就像一枚硬币的两面，这种平衡对我们的团队非常有益。

Actually, that's the word—agency. That's what we really hold important on the Claude Code and Code Work team. But it's interesting, I say along with high agency, because it's like we really... it's about, 'Hey, here's a problem,' and then it's really everybody on the team has ideas for how to address the problem. So it's really high agency, and then we say with high agency is also high accountability. So it's all about making sure folks have that freedom to cook. You know, they have that, but then it's also, 'Okay, what's the accountability for it as well?' And that's where, again, it goes back to, 'What's the hypothesis of what you're trying to solve?' So I think the balance—or almost like two sides of the same coin—agency and accountability has served our team really well.

这是一个非常重要的元素。有能动性。好的。每个人都在做事，但问题是，你实际上搞砸了什么？你做了什么？沿着这个思路，感觉最近有一种氛围转变：从 token 最大化——疯狂投入，尽可能多花钱，看看有什么可能——变成‘等等，我们到底从中得到了什么？成本是多少？投资回报率是多少？’有趣的是，Boris 之前在 Meta 负责产品和生产力——他的工作就是衡量最终生产力。还有那条关于代码行数、代码发布的推文——有一个有趣的讨论：如何真正衡量生产力提升和 AI 工具投入的 ROI？你们在 Anthropic 工作有无限免费 token 的优势。考虑到这一点，关于如何衡量当今世界工程师的 ROI，你学到了什么？

Such an important element. Have agency. Okay cool. Everyone's off doing stuff, but okay, what have you actually broken? What have you done? So kind of along those lines, it feels like there's this vibe shift recently from token maxing—just go crazy, spend as much as possible, just see what's possible—to like, 'Wait, what are we actually getting out of this? How much is it costing? What's the ROI?' Interestingly, Boris was actually head of product and productivity at Meta—that was like his job, measuring end productivity. And then also this tweet about lines of code, code shipped—there's this interesting discussion of just how do you actually measure productivity increase and ROI of AI tools in spend. How do you... you guys have the infinite advantage of getting free tokens working at Anthropic. With that in mind, what have you learned about how to measure ROI of engineers in today's world?

最终生产力是一个非常迷人的话题。是的，因为我记得，即使对我们来说，我们最初也是从代码行数开始的。那是吞吐量。然后我记得有一次争论：‘嗯，代码行数——这个工程师写了海量代码，但他们只是拿了一个库然后移植过来。所以他们提交了。’我当时想：‘好吧，也许是有意义的代码行数。’然后又说：‘但如果我们更新框架，现在生成的代码更少，但输出还是一样呢？’所以现在我想：‘好吧，也许是用 PR 合并时间。’但非常有趣的是，无论哪个指标，如果你真的关注产出，我的建议是：第一，产出是否真的导向结果？因为 token 最大化有点像我们以前用的代码行数。但我更关注的是：我们到底想做什么？所有这些……还有一句我很喜欢的话：‘不要用行动代替进步。’因为如果你衡量工具使用情况，你是在衡量动作，但它是否真的让最终结果变得重要？所以我真的试着退一步，专注于：我们要解决的问题是什么？衡量它的好方法是什么？然后我们主要关注这个，而不是那种生产力测量。

End productivity is such a fascinating topic. Yeah, because I remember, even for us, we first started with lines of code. And that's throughput. Then I remembered once there was a debate: 'Well, lines of code—this engineer had crazy lines of code, but they just took some library and ported it. So they checked it in.' And I was like, 'Well, maybe it's significant lines of code.' And then it's, 'Well, but what if we're updating our frameworks and now we're generating less code, but the output's still the same?' So now I'm like, 'Okay, maybe it's time to land PR.' But it's very interesting—whichever metric, it's like if you're really focused on the output, my advice here is: one, is the output really going towards the outcome? Because yeah, the token maxing is kind of like the lines of code that we used to have. But I'm really much more about: what is it that we're trying to do? All of this... there's another saying I really like: 'Don't forsake motion for progress.' Because if you're measuring tool user usage, then you're measuring the action, but is it really making whatever the end outcome is important? And so I really try to zoom out and focus on: what is the problem we're trying to solve? What's a good way to measure that? And then that's what we focus mostly on, versus kind of the productivity measurement.

不过我想说，除了指标之外，尤其是当团队里越来越多的人采用 AI 工具时，我强烈建议领导者们去搞一次倾听之旅。我特别喜欢关注资深工程师。听听他们什么有效、什么无效，我们怎么才能做得更好，因为他们会帮你把经验复制推广到整个工程团队。有时候这些对话会激发新想法，还能带来很好的共享学习，这比指标仪表盘有意思多了。我从指标中学到了一些好教训。我完全赞成：当你有一个可以持续优化的指标时，那很棒，但永远要记住我的成长心态——它还在为你服务吗？永远要问自己，这个指标真的还在服务于你最初的目标吗？举个有趣的例子：在 Facebook Marketplace 早期，我们按区域发布，想确保在扩张前打造出令人满意的产品。我记得早期我们关注的一个指标是卖家数量。第一个区域发布后，我发现那个区域的卖家数量很低，但用户实际上找到了他们想要的商品，而这正是我们的目标：帮助人们找到需要的物品。后来我意识到那个区域不是卖家多，而是有超级卖家。但我们扩张前的第一个门槛原本会严重依赖卖家数量。我记得那次快速对话：嘿，这又回到了人们会以你意想不到的方式使用产品，要快速发布、快速学习。于是我们更新了指标，意识到不能只看卖家数量，因为它没把超级卖家算进去。这就是我的建议：无论什么指标，不管是生产力还是产品，永远要保持警惕，确保你不是盲目地追随一个曾经合理的指标，因为环境变化太快了。甚至指标本身也可能需要调整。

I would say though, outside of metrics, especially if you're on teams as you're having more people adopt AI tooling, I would definitely go on a listening tour for the leaders listening to a podcast. I love to focus on the senior engineers as well. Hear from them on what's working, what's not, how can we actually make it better, because they will also help you multiply and scale that out across a full engineering team. And sometimes there's those conversations where you might get sparked an idea that comes up and also really good shared learning versus metric dashboards. It's very interesting. I've learned some good lessons from metrics. I'm all about it's really great when you have a metric that you can actually hill climb on, but always keep in mind my whole growth mindset of is it still serving you? Always keep in mind like is that metric really still serving the outcome that you were aiming for. A fun example I have with this is in the early Facebook Marketplace days, we were launching by region and we really wanted to make sure we're building a delightful product before we expand. I remember in the early days one thing we would keep an eye on was number of sellers. I remember after launching our first region, I thought the number of sellers in that area was low, but actually people were finding items they were looking for, which is what we were aiming for: helping people find items they need. Then I realized in that region it wasn't a large number of sellers, but there were power sellers. But our first gate before we expand would have factored heavily on number of sellers. I remember that quick conversation of hey, this goes back to that whole people will use things in ways you may not expect and ship better rate learn. So we updated the metric to realize it's not number of sellers because it didn't factor in power sellers. That's the advice I have: whatever metric, whether for productivity or even for product, always keep an eye and make sure you're not just having blinders on that's blindly following a metric that used to make sense, because sometimes the landscape can change so fast. Even the metrics themselves might need to be adjusted.

这又回到了你分享的那个流程：让 Claude 监控每个工程师提交的所有 PR，然后不关注指标，而是关注由此引发的对话——这个 PR 有什么影响，可能出现了哪些 bug——这是了解工程师工作状况的一个非常有效的方法。

And this comes back to your process that you shared of having Claude watch all the PRs shipping per engineer, let's say, and then not focusing on the metrics but focusing on that leading to a conversation about what impact this had, what were maybe some bugs that happened, and that being a really powerful way of understanding what's going on with this engineer.

太棒了。

Awesome.

让我们回到速度、质量和影响力这个问题上。关于如何平衡这些，你还有什么心得吗？代码生成速度惊人，还要保持质量和影响力。还有什么可能对其他每天处理大量 PR 的团队有帮助的建议吗？

Let me come back to this question of speed and quality and just impact. Is there anything else you've learned about how to balance those things? There's a crazy velocity of code being generated and just stay on top of quality and impact. Is there anything else there that might be helpful to other teams that are trying to wrangle all these PRs being shipped every day?

我想说，这其实是我们想继续加强并做得更好的地方：主动质量。特别是对于质量，要明确哪些是关键体验，并确保你确实有相应的指标。这些是观察长期趋势的好东西。在质量方面，我们发现越主动，越能早期发现质量问题。这是我们非常关注的一点。我提出了一个概念叫‘坏与糟’。‘坏’是非常严重、不可恢复的错误。‘糟’是有点痛苦但可恢复的问题。有趣的是，当‘糟’积累起来，通常也会变成‘坏’。即使有这样一个高层框架也有帮助。有时候仪表盘上有加载时间之类的指标，但当你面对很多不同的产品表面时，很难说‘等等，这个数字是好还是不好？’所以对我们有帮助的是，除了原始的性能或可靠性数字，还要有一个框架来定义什么是糟糕的体验，并确保我们专注于解决这些问题，同时关注‘糟’的情况。这给了我们一些帮助。

I would say, and this is honestly what we want to keep doing more of and being better at, too: proactive quality. Especially for quality, making sure what are the key experiences and making sure you actually have metrics for them. Those are really good things to look at trends over time. On the quality front, we found the more proactive we can be in getting earlier detection into quality. That's been one thing we've been paying a lot of attention to. I started this concept of 'bad versus sad.' Bad is a very bad irrecoverable error. Sad is something that's kind of a pain point but recoverable. It's interesting when you stack up sads, it could generally go to bad. Even having a high-level framework like that helps. Sometimes with dashboards you have time to load or all these other things, but when you're dealing with a lot of different product surfaces, it's harder to say, 'Wait, is that a good number or not?' So one thing that's helped us is, versus just raw performance or reliability numbers, also having some framework of what we think is a bad experience and making sure we're focused on addressing those, and also keeping an eye on where we see sads. That's helped us a little bit.

我喜欢‘坏与糟’这个分类。所以这有点像阈值：这是坏的，好的，这是严重的。那么你们衡量的是性能、故障还是哪些方面？

I like the bad and sad. So these are kind of like thresholds of this is bad. Okay, this is serious. And this is in terms of performance or failures or what sort of things are you measuring here?

例如，我们给每个团队自主权。既然知道‘坏’是非常严重的不可恢复错误，我们让每个团队为自己的领域或服务定义什么是‘坏’和‘糟’。比如在 CLI 上，崩溃率可能是‘坏’，因为你丢失了工作。‘糟’可能是闪烁，这是可恢复的。我们让每个团队自己定义，这很有意思，因为以前由于领域不同，我们有各种仪表盘，但很难退一步看到体验的整体主题。所以我们给每个团队高度自主权，让他们决定什么是‘坏’和‘糟’，以及每个团队想要达到的目标。

For example, we allow each team agency. So knowing that bad is a really bad irrecoverable error, we enable each team to define for their surface areas or services what constitutes a bad and a sad. For example, on CLI, crash rates could be a bad because you lost work. A sad might be flickering, which is recoverable. We have each team define that, and that's why it's been interesting because before, since surface areas are different, we had all these dashboards but it's harder to zoom out and see the overall theme of the experience. So we give high agency to each team to decide what constitutes a bad and a sad, and then what goal each team wants to achieve.

我听到的一个主要收获是，保持质量的最佳工具就是监控和测试，而不是花更多时间审查，这很合理，因为速度太快根本跟不上，这几乎呼应了为智能体闭环的想法，让它们自己解决问题。它们知道成功是什么样子。酷，我们自己修复。所以这是一个非常有趣的收获：多投资测试。评估我想也是其中一部分，还有监控失败和速度等。

One of the main takeaways I'm hearing here is that one of the best tools for staying on top of quality is just monitoring and tests versus spending more time reviewing, which makes sense because the speed is just impossible to stay on top of and it almost speaks to this idea of closing the loop for agents to be able to kind of figure things out themselves. They know what success looks like. Cool, we'll fix it ourselves. So that's a really interesting takeaway: just invest more in the tests. Evals I imagine is part of this and then just like monitoring failures and speed and things like that.

没错。

That's right.

有件事我想是公开的。我知道你们有一个仪表盘，专门追踪类似 F 开头的词，比如人们有多频繁地……因为他们非常恼火和沮丧。好像有个有趣的术语，我忘了叫什么。

Something I think this is public. I know that you guys have this dashboard that tracks just like F-words, like how often people are like... because they're so pissed and frustrated. There's like a funny term for it, I think. I forget what it's called.

是的。

Yes.

实际上，我记得那是去年九月，因为我们都看到了一些挫败感。团队里一位工程师说：‘嘿，我们也许应该跟踪脏话。’我觉得：‘哦，这是个好主意。’我当时刚加入，我们进行了一次非常有趣的对话。回顾起来很有意思，这也是评估困难的原因，因为它回到了用户体验，以及我们如何确保体验愉快、减少挫败感。不过，脏话仪表盘确实是个有趣的东西。

Actually, I remember that was last September, because we were all seeing some frustrations. An engineer on the team said, 'Hey, we should maybe track swear words.' I thought, 'Oh, that's a great idea.' I had just joined, and we were having that really fun conversation. It's very interesting to look at, and that's why Evals is hard too, because it goes back to user experience and how we can make sure it's a delightful experience and less frustrating. But yeah, the swear word dashboard is a fun one.

本期节目由 Mercury 赞助。Mercury 是一种截然不同的银行服务，深受超过 30 万企业家的喜爱，现在又推出了 Command。我是 Mercury 超过 6 年的客户，从未想过离开。Mercury 就是由产品人而非银行家打造的银行。他们让发送发票、转账、为团队成员设置虚拟卡变得如此简单，我敢说甚至很有趣。你的银行有 API、终端原生 CLI 或 AI 就绪的 MCP 服务器吗？我觉得没有。最近他们推出了 Command，一个直接内置于 Mercury 的对话式界面，充当你的财务操作员。我一直在用 Command 转账、查看哪些类别花钱最多、分析现金流，就在今天，我还用它查了过去一年从某个特定赞助商那里赚了多少钱。我只是问：‘过去一年我从 X 那里赚了多少？’10 秒后我就得到了答案。这太酷了。访问 mercury.com 了解更多信息，几分钟内即可在线申请。Mercury 是一家金融科技公司，非 FDIC 承保银行。银行服务由 Choice Financial Group 和 Column N A 提供，均为 FDIC 成员。

This episode is brought to you by Mercury. Radically different banking loved by over 300,000 entrepreneurs and now with Command. I've been a customer of Mercury's for over 6 years. I have never once thought about leaving. Mercury is basically what happens when banking is built by product people, not by bankers. They make it so easy, dare I say fun, to send invoices, move money around, set up virtual cards for folks on my team. Does your bank have an API, a terminal native CLI, or an AI ready MCP server? I don't think so. And just recently they launched Command, a conversational interface built directly into Mercury, which acts as your financial operator. I've been using Command to transfer money around, to figure out what categories I've been spending the most money in, analyze my cash flows, and just today I used it to find out how much I've made from a specific sponsor over the past year. I just asked, 'How much have I made from X over the past year?' 10 seconds later I have an answer. It is so freaking cool. Visit mercury.com to learn more and apply online in minutes. Mercury is a fintech company, not an FDIC insured bank. Banking services provided through Choice Financial Group and Column N A, members FDIC.

回到你的工作方式，以及你在这个疯狂的新世界中摸索出的方法。我听说你实施了一些相当独特的做法，我认为对团队运作很有帮助，而且对你来说效果很好。其中之一是让每位经理先以独立贡献者身份开始，然后每位经理必须继续兼职做独立贡献者，有点像球员兼教练的方式。谈谈这个，为什么在当今世界如此重要？

Kind of going back to the way you operate and ways that you've figured out to work in this crazy new world that we're in. I've heard about a couple things that you've implemented that are pretty unique, I think, to how teams operate and I think is something that has worked really well for you. One is making every manager start as an IC and then just every manager has to continue being an IC part-time, kind of this player-coach approach. Talk about that, why that's so important in today's world.

嗯，我喜欢这个。有趣的是，我刚加入时，我有很棒的招聘伙伴，我注意到整个成长心态的主题。只是因为环境变化太快。以前行之有效的方法可能不再合理，甚至今天合理的明天也可能需要改变，对吧？这是我必须不断提醒自己的。所以我刚加入时，招聘人员说：‘好的，我们有几个经理职位。’实际上，这源于我与团队所有成员进行的倾听之旅。我听到很多：‘嘿，我很欣赏自主权，但我如何确保优先级？’通过这个，我意识到，还有一些很好的反馈，关于确保不要有太多审查层级。作为领导者，如果你先以独立贡献者身份开始，不必担心支持他人——因为那是一个非常沉重的责任——你就能给自己创造者时间，深入代码，学习代码库或产品，无论是什么。我做的代码审查与其说是在修复什么，不如说是让我保持流畅，因为我们在协作文档和代码上做了很多改动。即使我做代码审查，也更多是为了每天使用产品以保持触感。尽管指标和仪表盘很棒，但如果你作为领导者没有每天亲身使用产品，你有时会失去对产品感觉的把握。在经理方面，给新加入的经理时间，在支持他人之前深入，有助于他们与团队建立良好的关系。否则，有时经理加入新团队后立刻想：‘我必须管理。让我拿出我的管理工具箱，做些管理的事情。’但如果你先不担心这个，而是真正体验作为团队工程师和队友的感觉，这对建立关系大有裨益。在使用产品方面，我加入的每个团队，我收到的第一条评论往往是：‘嘿，我真的很喜欢你实际使用我们构建的东西。看到你提供用户反馈真是耳目一新。’所以作为领导者，这也是我们亲身体验团队工作的方式。

Mhm, I love it. It's funny when I first joined, because I have amazing recruiting partners, and I noticed this whole theme of growth mindset. It's just because the landscape is changing so fast. What worked well before may not make sense, and even what makes sense today may need to change tomorrow, right? That's what I have to keep reminding myself. So when I first joined, recruiters said, 'Okay, we have these couple manager postings.' And actually, it came from a listening tour I did with all the members on the team. I heard a lot of, 'Hey, I really appreciate the agency, but how can I make sure prioritization?' Through that, I realized, and there was some really good feedback too, about making sure it's not too many layers of reviews. When I think as a leader, if you start as an IC first without the worry of supporting people—because that's a very heavy responsibility—you give yourself that maker time to actually type deep into the code and learn the code base, or the product, whatever it is. The PRs I do are less about what I'm fixing; it's more about keeping me in the flow because we're making so many changes to co-work and code. Even me doing PRs is more about using the product every day to keep that touch. As amazing as metrics and dashboards are, if you as a leader aren't living and breathing your product every day, you sometimes lose touch with the feel of the product. On the manager front, giving time for managers that join to go deep before supporting people helps them build great rapport with the team. If not, sometimes managers join a new team and instantly think, 'I have to manage. Let me dig into my manager toolbox and do manager-y things.' But if you give yourself time to not worry about that first and actually learn what it's like to be an engineer and teammate on the team, that goes really far in building rapport. In terms of using the product, every team I've joined, one of the first comments I get is, 'Hey, I really love how you're actually using what we build. It's refreshing to see you giving user feedback.' So as leaders, it's also a way for us to personally experience the work the team does.

有些人可能不知道，你在加入 Anthropic 之前在 Meta 管理着一个大约 500 人的组织，对吧？然后你基本上转成了 Anthropic 的独立贡献者工程师。

Something that people may not realize, you were overseeing an org of like 500 people at Meta before you moved to Anthropic, right? And you moved to IC engineer basically at Anthropic from that.

我一开始做独立贡献者的时间很短。但实际上，这是我在微软和 Meta 之间的经历。在 Meta，我面试的是经理职位，但至少在头一个季度，我也是独立贡献者，因为我真的很想体验成为 Meta 工程师的感觉。在那之前，我在微软，在工程方面磨练了技能。所以我熟悉所有代码库、工具和语言。头几个月真正学习作为 Meta 工程师如何发布产品，这非常宝贵。而且也很有趣。我觉得我们有时会忘记这一点。顺便说一句，这就是我喜欢 Claude Code 的原因。因为我上次在 Meta 发布生产软件大概是 2017 年。每年我可能会开始——我做了很多内部测试，也用内部测试来帮助我保证产品质量。但距离我上次发布生产软件已经很久了。

I started out like it was for a very short amount of time. But actually, this was my journey between Microsoft and Meta. At Meta, I interviewed as a manager, but at least for the first quarter, I was also an IC because I really wanted to learn what it's like to be a Meta engineer. Before that, I was at Microsoft, kind of cut my teeth on engineering at Microsoft. So I knew all the code bases, the tools, the languages. It was so valuable to have those first months actually learn what it's like to ship as a Meta engineer. Plus it was also fun. I think sometimes we forget that. By the way, that's what I love about Claude Code. Because the last time I shipped production software at Meta was probably 2017. Every year I might start—I do a lot of dogfooding and use dogfooding to help me with the quality of the product as well. But it's been a very long time since I shipped production software.

部分原因是我怕搞砸。我总担心：万一我做了什么导致一个 bug，而我又没正确验证，或者浪费了别人的时间怎么办？因为工具流程会变。但记得在 Claude 的第一周，我差点又像往常一样去认识所有工程师请他们喝咖啡，然后我想，等等，让我问问 Claude。Claude 是个很好的入职伙伴，因为我对代码库很好奇，问它问题，它帮我做自动化测试，但我也想做一些手动测试。我问 Claude，帮我设计一个手动测试的方法，确保覆盖所有情况。这给了我信心，让我能再次发布代码。我越来越得心应手。很多做经理的朋友联系我说，多亏了 Claude，他们又开始写代码了。总的来说，作为领导者，确保你使用团队构建的产品很重要。

It's because part of it is I don't want to screw something up. I'm always so scared of what if I do something and then I cause a bug and then I'm not verifying properly or am I wasting someone's time? Because the tool flows would change. But I remember that first week on Claude, I almost went and did my usual, let me go meet all the engineers and treat them to coffee, and then I'm like, oh wait, let me ask Claude. Claude was this really good onboarding buddy because I was curious about the code base, asking it questions, and it also helped me do automated tests, but I also wanted to do some manual testing. I asked Claude, hey, help me come up with a way for me to manually test this to make sure I cover all the cases. All that gave me confidence that I could ship code again. I got more comfortable with it. I've had a lot of friends reach out to me that have been managers for a while and say, hey, I'm shipping code again thanks to Claude. In general, it's important to me as a leader to make sure you're using the product that your team builds.

很有意思，你作为天使领导者监督着最改变工程师角色的团队。这是一个元角色。工程师的工作因为你们构建的软件而转变。一个相关的问题是，你是否担心工程师的编码技能因为不再实际写代码而退化？这重要吗？你考虑过吗？这是个大问题吗？

It's so interesting that you are overseeing the team as an angel leader that is most changing the role of an engineer. It's such a meta role. The work of an engineer is transforming because of the software that you're building. One question along these lines is just do you worry about engineers skills to code atrophying from not actually writing code anymore? And does it even matter? Is this something you think about? Is it a big deal?

有趣的是，我们在团队里确实讨论过这个问题。比如，我们错过了什么？或者就像你说的，我总是在想新人入职和上手的过程。Boris 早期手写代码，现在当然不了，但他从之前就获得了知识，因为他熟悉代码库。所以对所有新加入的工程师，我也说确保花时间理解架构或变更，因为这又回到了信任但验证。也许有一天这不再重要，但以我们现在的速度，我仍然认为理解你依赖的那一层很重要。花时间了解你的依赖，这样当依赖变化时，你更清楚，或者你可能没有利用好变化。所以我认为总是要深入理解。但我们在 Claude Code 团队发现的另一件事是，过了一段时间，我们觉得这可能变得孤独，因为我们都太专注于和智能体一起工作。所以最近我们开始了结对编程午餐。我们还发现，在 Claude Code 上，每个人都用不同的方式使用 Claude Code 协作。我们发现结对编程时，我们从彼此身上学到了很多。我们也确保有共同的时间。比如，黑客马拉松是另一件我们喜欢做的事，以确保我们作为团队互动。

It's interesting because we actually have this discussion on the team a bit. Like, are there things that we miss? Or to your point, I'm always thinking about when someone's onboarding and ramping. You have Boris who hand wrote the code in the early days and of course doesn't anymore, but he gained that knowledge from before because he was in the code base. So for all the engineers that join, I also say make sure you take the time to still get the understanding of the architecture or the change because it goes back to that trust but verify. Maybe one day it won't matter anymore, but at the pace we're going, I still think understanding like it's always double clicking on that layer that you depend on. Take the time to learn about your dependencies, so when your dependencies change, you're more aware or you might not be taking advantage of changes. So I think it's always about doing that double click. But the other thing we found interesting on the Claude Code team is after a while we felt it could start being a lonely experience because we all started just working with our agent so much. So recently we started a pairwise programming lunch. What we also learned was on Claude Code, everybody uses Claude Code co-work. Everybody uses a flow so differently. We found that when we do pairwise programming, we actually learn so much from each other. And we also make sure we have time together too. For example, hackathons is another thing we really like to do to make sure we're interacting together as a team.

说得好。孤独感出现了，因为过去是团队一起构建代码。有人做后端，有人做前端，有人做 iOS 应用。可能后端有一群人。而现在，如果 10 个云并行运行做所有这些事。找到连接工程师的方法真是个好主意。所以这个想法有点像结对编程，但又不是。就像孩子成长时的平行游戏。你挨着工作，但构建自己的东西。但即使只是看别人如何构建也很有价值。

That is such a good point. Just like the loneliness that emerges because used to be teams building code together. Someone's doing back end, someone's doing front end, someone's doing iOS app. Probably a bunch of people on the back end. And now, well if 10 clouds running in parallel doing all these things. That is such a good idea of just like finding ways to connect engineers. So, the idea here is like almost pair programming, but not. It's like parallel play when kids are growing up. You're kind of working next to each other, but building your own things. But even just watching how other people build is really valuable.

是的，因为我们的工具链也在快速变化。但有趣的是，我们团队每个人都以不同方式使用 Claude Code 和协作。每次我看别人工作，我自己也学到东西。

Yeah, and it's because our own tool chain is changing so fast as well. But it's very interesting to me that everybody on our team just uses Claude Code and co-work in different ways. So every time I watch someone work, I learn something myself as well.

你如何管理那些过度痴迷于优化工作流程的人？你会说‘没关系，继续做’吗？

How do you manage people getting over obsessed with optimizing their workflows? Is there anything you just say, 'Okay, it's fine. Just keep going.'

我没看到太多团队成员那样。我觉得每个人都对架构更新或产品体验感到兴奋。大多数人经常讨论这些。我们不会过度优化，因为实际上没有完美答案。

I haven't seen too many folks on our team like that. I think everybody is just really excited about either an architecture update that we think will be higher reliability or some product experience. So most folks talk about that a lot. We don't over-optimize because there's no perfect answer actually.

这些见解真的很有趣。随着角色转变，有得也有失。我好奇在软件工程的新世界里还失去了什么。我曾经做了 10 年工程师。坐在那里心流编码非常有趣。你知道那种感觉：‘哦，它工作了。看它编译。太棒了。我在进步。’现在你不再那样做了。你只是坐着等智能体构建东西。工程师在这个新世界里还失去了什么？

These are really interesting insights. Just as the role transformed, things come, things go. So I'm curious what else is kind of lost in this new world of software engineering. I used to be an engineer for 10 years. It was so fun just to sit there in flow coding. You know this feeling. Just like, 'Oh, wow, it's working. Look at it compile. It's amazing. I'm making progress.' And now it's like you don't do that anymore. You just sit there and wait for agents to build the thing. What else is kind of lost in this new world for engineers?

是啊，真有趣。我刚刚和团队里一个工程师聊过心流。记得以前，你遇到一个棘手的问题，放上音乐，然后就进入状态了。所以有点怀念，最后总有一个大‘啊哈’时刻。你记得你终于搞定了。现在我们从产品中获得很多快乐。但我也听其他工程师说，一些最困难的部分正是我以前享受的。所以我觉得我们都在转变。但我最看重的是，这就是为什么我提到结对编程和黑客马拉松。

Yeah, it's so funny. I just had that conversation with an engineer on the team about flow. Remember the old days you have this really gnarly problem and you pop that music soundtrack in and then you're just in the zone. So yeah, there is a little, and then there was always that big aha moment at the end. You remember you're like you finally cracked it. So we do, but I think now we get a lot of joy from the product. But I do hear from other engineers as well, some of the hardest parts is what I used to enjoy. So I think we're all just kind of shifting. But I do see the thing most, and that's why I was talking about the pairwise programming and the hackathon.

最近确实越来越多的人开始觉得这开始变成一种孤独的体验。

That did recently come up more of folks were starting to feel like it's starting to be a lonely experience.

真有意思。在 Anthropic 内部，我很好奇，工程是目前我认为变化最大的角色。那么，你觉得到目前为止，Anthropic 内部变化第二大的角色是什么？和几年前相比最不一样的是哪个？

So interesting. Within Anthropic I'm curious so engineering like the most transformed I think of any role right now. What other What's like the second most transformed role so far would you say within Anthropic that's most different from how it was like a couple years ago let's say?

所有与编码相关的角色都在转变。比如产品经理，我知道你和 Kai 聊过。我认为产品经理也发生了很大变化，因为产品经理不再受限于等待工程资源来实现想法。所以这算是下一个我看到转变的角色。实际上，我们的产品经理也卷起袖子帮忙推动一些功能，比如当我们想做某件事但工程师无法完成时。所以我认为所有与编码相关的角色都开始转变。但这也凸显了验证的重要性，因为当更多不同学科的人参与进来时，我们如何确保每个人都有很高的信心？我还认为我们需要做更多工作来持续自动化工作流程的其他部分。当然我们很关注编码，但接下来，想想设计或数据科学，这些开始成为下一个领域，我认为是很好的机会，看看我们如何也能开始改善那里的体验。

It's all the coding adjacent roles are shifting. Like PM is I know like you you were chatting with Kai. I think PM is also transformed quite a bit because PM bar no longer bottlenecked if if they have an idea waiting on engineering bandwidth. Um so that's kind of like the the next role I've seen shift. Like actually our PMs have also helped us roll up sleeves and help shift you know like some features when we when we were um you know like when there wasn't uh when there was a you know something we wanted to do and an engineer wasn't able to. So I think um it's all the coding adjacent roles are starting to shift. Um but I think that's where again the verification is important cuz when you have more different disciplines checking in how do we make sure everybody has high confidence. I also think we need to do more to keep automating these other portions of the workflows. Like for sure we focus a lot on coding but next when you think about like design or data science like those are starting to be the next areas I think are good opportunities for us to see how we can yeah like um uh start and improving kind of like experiences there as well.

说到数据科学，我有一个数据科学朋友，他说现在数据科学完全不同了，大部分工作变成了别人用 AI 做自己的数据科学工作（通常做得不怎么样），然后拿给数据科学家看：“这是我做的分析，你能确认一下对不对吗？”而一半时间都是错的。所以现在的工作完全变了，不再是他们原本想做的，而是“好吧，我整天就在审核这些 AI 数据科学的东西，搞什么鬼？”

Yeah, I have a speaking of data science, I have a data science friend and he was just saying how data science is so different now where now most of their job is people doing their own like not amazing data science work using AI and it and then just like showing it to the data scientist, "Here, here's the analysis I did. Can you just make sure it's right?" And half the time it's not right. And so the job is just like a whole different job now instead of doing the work that they thought they wanted to do and that's like, "All right, I'm just reviewing all this AI data science all the time. What the hell?"

顺着这个思路，回到你的团队运作方式和变化，我想问：与几年前相比，现在工程经理应该对团队有什么期望？什么是正常的基线期望？除了我们交付更快之外，还有其他变化吗？

Kind of along the lines, coming back to just how your team operates and how things are changing, let me see if something comes with this question. What should an engineering manager expect from their team now versus like a couple years ago? What's like a normal, I don't know, baseline expectation of how things should work? Is it other than just, you know, we're shipping faster? Is there anything else?

哦，有意思。嗯，我认为大多数提交都有云端辅助，这是一个转变。我们有一些 Slack 频道收集所有反馈，还有仪表盘也迁移到云端。我认为让工程师持续培养更强的产品感，这有助于打造真正有想法的产品工程师。我注意到，以前很多非工程角色，现在工程师也能胜任，有时你不再被跨职能伙伴卡住。现在这些阻碍变少了，因为模型能够增强工程师原本不具备的额外能力。

Oh, interesting. Well, definitely I think most commits are cloud assisted and so that was a shift. Um I think you know, I kind of like mentioned we have like Slack channels with all the feedback and also our dashboards that we have get to cloud. I think having engineers building like keep building that stronger product sense muscle is I I think also like another and I think that in general helps kind of build these really strong minded product engineers. I would say more of these roles that were traditionally non-engineering, you do now see engineers being like and sometimes you're just blocked by, you know, waiting for you know, a cross-functional partner. I think there's there's less of those blocks now just because the models are able to augment additional capabilities that you may not have as an from as an engineer.

所以有趣的是，这是双向的。工程师变得更有产品思维，对产品的质量和成功负责，而每个人也变得越来越像工程师。

So it's kind of interesting that it's both directions. Engineers becoming more product minded and responsible for the quality and success of a product and then everybody becoming an engineer more and more.

对，没错。一切都在模糊化。

Yeah, that's right. It's all blurring.

是啊。我忘了谁说的，但有个说法是：角色到底是什么？这个人说，就是你做的事情的平均值？你做得最多的那件事，那就是你现在的角色，不管它是什么。

Yeah. I forget who said this, but there's this like like what is a role anymore in this this guy said that it's like what's the average of what you do? What's like the highest percentage of what you and that's kind of your role now, whatever it is going to be.

嗯。

Yeah.

哦，我想回到你刚才说的对产品的痴迷，就是亲身使用产品、吃自己的狗粮。我和很多与你共事的人聊过你，他们提到最多的就是你痴迷于亲身使用产品，无论你在构建什么，都不断使用它。说说为什么这如此重要，为什么你要向你的团队和下属灌输这一点。

Oh man, I want to come back to your point about obsession with the the product living breathing the product dog fooding. I talked to a bunch of people that work with you about you and that's the thing that came up most just like your obsession with living and breathing the product using the product constantly, whatever it is you're building uh this idea of dog fooding. Talk about just like why that is so important, why that's something you instill within your teams and and and reports.

哦，我很喜欢这个。嗯，这对我来说真的很有效，是保持对产品脉搏感知的好方法。任何时候你构建产品，都有一个梦想——你希望实现某种体验或让体验变得更好。所以这能让我非常贴近脉搏。另外，可能是在 Visual Studio 上，我培养了对这种做法的热爱。但有趣的是，即使是 Marketplace，我离开团队后偶尔还会用。有一次我有一台 MacBook Air，想卖掉旧的，我之前没在 Marketplace 上卖过东西。结果我一挂上去，就有买家试图骗我，这是一个我没发现的新骗局。这说明人们会以你意想不到的方式使用你的产品。所以作为领导者或团队成员，我们都有不同的生活经历。有趣的是，当我支持 VR 和 AR 团队时，我使用 VR 设置总能发现一些奇怪的楼层高度问题。这最终帮助了团队，因为我有一个很好的复现环境。所以我认为，第一，这是保持对产品脉搏感知的方式，不要只沉迷于指标、仪表盘或演示。

Oh, I love it. Um yeah, I think it's it's really and and this has worked for me um it's just been a really good way for me to keep a pulse on you know, anytime you build product there's there's a dream. Like you're really hoping to enable an experience or make an experience better. So I think um being able like like that helps me keep really close to the pulse. I also think uh maybe and maybe something like for sure on Visual Studio that was like, you know, where I where I got this love of it um but it's interesting cuz even Marketplace, I remembered every time once in a while I'll do like even after I left the team actually. Um one time I had like a MacBook Air and I wanted to sell my old and you know, I haven't sold anything on Marketplace let let me and I could not believe it the minute I I put it up for sale a seller or buyer tried to scam me and it was an interesting like new scam vector I didn't detect and so but that goes to again like people will use uh your products in ways that that you may not expect and so especially as leaders or even like anyone on the team, we all have different like life like actually it's it's funny when it when I was a you know, supporting the VR and AR teams, somehow how I used VR, the setup, I would always be able to find these really weird floor height issues. So, that ended up being a I took a you know, like I'm going to help us you know, like cuz somehow I got a good repro environment. Um And so, I think it's number one like making that's how you keep your pulse on the product that you're building and don't get too lost in metrics and dashboards only or presentations.

我觉得你说的这一点非常重要，我想确保大家听到：总是存在轶事证据和例子与数据之间的对比。而你说的是，作为产品领导者和工程领导者，你在轶事、那些作为用户经历的特定小案例上取得了很大成功，而不是只沉迷于数据。

I think that's such an important point you're saying there that I just want to make sure people hear is just like like there's always this idea of anecdotal evidence and just like examples versus the data. And what you're saying here is as a product leader as an engine leader, there you found a lot of success in like the anecdotes, the specific uh little one-offs that you experience as a as a as a user versus like obsessing with the data only.

是的。实际上，有时这也是我能够最有效帮助团队的方式。

Yeah. And and actually, sometimes it's also how I've been able to most effectively help the team.

举个例子，我上一个团队是领导一个 VR 团队。我没有向那个代码库提交任何代码，因为我真的很担心搞乱操作系统。但我们做了很多打磨修复，我想利用自己的‘吃狗粮’时间来实际检验体验效果。这也是我觉得自己还能有意义地贡献、帮助团队保持质量门槛的一种方式。每个团队成员通常都很感激，因为作为领导者，你在支持团队里的人。在指标之外，每个人都希望自己的工作有意义。确保领导者使用你的产品，我觉得大家会感到领导者仍然非常投入。

So, for example, the last team I was on, I was leading a VR team. I had not checked in any code into that codebase because I was really worried about messing up the operating system. But we were doing a lot of polish fixes, and I wanted to use my dogfooding time to actually vet how the experience looks. That was also a way I felt I could still meaningfully contribute to help hold the quality bar for the team. Every team member usually really appreciates that because as a leader, you're supporting folks on the team. Outside of metrics, everybody really wants to make sure their work matters. Just making sure that leaders use your product, I think folks feel the leaders remain really engaged.

这和你说的工程师需要更有产品思维的观点很相关。工程师需要更像产品经理，产品经理需要更像……但作为工程师，这是做到这一点的一种方式：不断使用产品。这会帮助你作为用户理解产品缺少什么，因为你就在使用它。

And this connects a lot with your point that engineers need to become more product minded. Engineers need to become more PM-y, PMs need to become more... But as an engineer, this is one way to do it: use the product constantly. That'll help you understand what is missing in the product as a user because you're just using it.

没错。我想说，如果你领导一个团队，很难亲自使用产品，那就去见客户。无论其他途径是什么，我认为这也很重要。每次我做客户拜访，总能学到新东西。我记得我们试图在拉丁美洲推出 Facebook Marketplace 时，在智利做测试。效果不如其他地区。我们组织了一次很小的调研之旅，我去了智利。我拿了一堆安卓手机。团队很小，只有三个人。落地后，我打开这些安卓手机，发现 LTE 连接比我们在美国习惯的要慢得多。Marketplace 的信息流在那种慢速 LTE 环境下加载得很差。这真是个增长障碍——连加载都不行。这就是为什么始终倾听客户反馈并建立快速反馈循环如此重要。

That's right. And I would say if you're leading a team where it's really hard for you to use the product, then meet with customers. Whatever the other avenue is, I think that's also been really important. Every time I've done customer visits, I always learn something new. I remember when we were trying to launch Facebook Marketplace to Latin America, we were testing in Chile. It just wasn't doing as well as the other regions. We had a really small research trip where I went to Chile. I got a whole bunch of Android phones. It was a very small crew, just three of us. Upon landing, I opened up these Android phones and realized the LTE connection was much slower than what we were used to in the US. The Marketplace feed didn't even load very well on those little LTE situations. What a growth blocker—you can't even load. That's why it's so important to always listen to customer feedback and get that fast feedback loop.

我记得杰夫·贝佐斯说过，如果你有数据和一个故事，相信故事而不是数据。令人惊讶。这是个很好的例子。好了，再问几个问题。在你的演讲中，最后有一张很有趣的幻灯片，列出了你正在重新思考的问题，这些问题你还没想好怎么解决，因为变化太大了。我来读一下这三个问题。我好奇的是，是否还是这三个问题，或者还有其他当前需要解决但尚未解决的运营问题。你在演讲中分享的是：我们还需要独立的 iOS 和 Android 组织吗？全自动审核要推进到什么程度？随着角色模糊化，如何确保每个人同样高效？这些问题还在吗？还有其他你正在思考的、需要攻克但还没想明白的问题吗？

I think it was Jeff Bezos that said if you have the data and you have an anecdote, trust the anecdote over the data. Surprisingly. And that's a great example. Okay, just a couple more questions. One is in your talk, you had this really interesting slide at the end of what questions you're kind of rethinking about right now that you haven't figured out how to solve with how much is changing. I'm going to read the three. I'm curious if it's still these three, if there's anything else like current problems we need to figure out that we haven't solved in how we operate. What you shared in your talk was: do we still need separate iOS and Android orgs? How far do you push fully automated reviews? And with role blurring, how do you ensure everyone's equally productive? Still problems? Is there anything else that you're thinking about like, okay, we need to crack this. We haven't figured this out.

你知道，iOS 和 Android 那个问题，我觉得我们其实还在——有趣的是，我提到了深度专长。我们确实觉得仍然需要引进有这些专长的人，但可能不需要那么大规模，因为人们在灵活变通。所以还是要确保我们有 Android 和 iOS 专家，但每个平台不需要那么大的移动组织。这仍然是我们试图平衡的问题：我们是否有正确且足够的专长？第二个问题是——抱歉，第二个是什么来着？

You know, the iOS Android one, I think we're still actually—it's funny because I speak of deep expertise. We definitely feel it's really important to still bring on folks with that expertise, but we probably don't need as large because people are flexing. So it's again making sure we have the Android and iOS experts, but less of a larger mobile org per platform. That's still a balance we're trying to figure out: do we have the right and enough expertise? The second one was—sorry, what was the second one?

哦，对。是全自动审核要推进到什么程度？

Oh, yeah. It is how far do you push fully automated reviews?

啊，对。这其实是个有趣的问题。关于内容设计检查，我认为我们在所有方面都在寻找：如何真正定义‘好’的样子？验证仍然是一个我认为还有很多机会的领域。但推进到什么程度，我认为要看我们觉得专家仍然重要的地方，然后还要不断问自己：有没有办法利用我们的专长来实现自动化？纵观整个端到端体验，确保我们没有遗漏。我们从工程角度出发，但也要确保体验如何考虑其他领域。我觉得我们肯定还能做得更多。

Ah, yes. Actually, well, this is a fun one. With the content design check, I think we're looking for across all of it: how do you actually get what good looks like? The verification is still one that I think there's a lot more opportunities there for us. But how far to push, I think looking at where we think that experts still matters, and then also have to keep asking ourselves, okay, is there a way to leverage our expertise to also automate? Looking across the whole end-to-end experience, making sure we're not missing things. We come at it from an engineering standpoint, but making sure experiences how we think about those other areas. I think there's definitely still more that we can do there.

基本上，就是如何解决如何设置验证，确保体验符合你的期望？

Basically, how do you solve how do you set up a verification that the experience is what you want it to be?

正是。这个问题仍然很难解决，因为你提到了评估案例。部分肯定是准确性，但也关乎体验。所以我们还在思考。

Exactly. That and I think that one is still a hard one to crack because you kind of mentioned the eval cases. Some of it for sure is accuracy, but it's also the experience. So that's something we're still kind of thinking through.

太棒了。还有其他最近发生变化、我们需要重新思考运营方式的问题吗？还是主要就是这些？

Awesome. Is there anything else that's like this has changed recently we got to figure out how to rethink the way we operate or is this kind of the big ones?

你知道，因为日常工作和一切变得更加异步，我觉得上下文切换的负担开始变重。我甚至记得我自己也……所以我认为这可能是另一个我们需要思考的问题：我们如何为团队成员或用户，真正改善体验来减轻这种负担？因为我确实看到上下文切换的负担在增加。

You know, I think because with routines and everything being more async, I think there is starting to be a high load on our context switching. I even remember I myself was like, oh I kicked off like I kicked off like... So I think that's probably another thing we have to think about: how do we, whether for our team members or our users, how can we actually make the experience better to reduce that load? Because I do see the context switching load increasing.

我可以想象，如果你有 20 个智能体在运行，就会有没完没了的检查和审查，你必须记住你在做什么。这是一个非常有趣的世界，我们之前谈到的‘心流’——工程师和大多数人很少有连续几小时的心流，但现在智能体可以提醒你：你当前的状态。切换时的重置几乎更容易，因为你不需要重新学习一切。你不需要重新理解代码库和架构。你可以直接说，好吧，但这是我们要做的。这有点像既变好了，也变坏了。

I can imagine if you have 20 agents running, there's just endless checking in and reviewing, and you have to remember what you're doing there. It's such an interesting world where the idea flow we talked about before—engineers and most people have less of the just hours of flow, but now the agents can kind of just remind you: here's where you're at. The reset to switch almost is easier because you don't have to relearn everything. You don't have to re-understand the codebase and the architecture. You can kind of just like, okay, but here's what we're trying to do. It's kind of like both got better, got worse.

嗯，这很有趣，因为我以前会专门留出专注时间写代码，但现在有了更多异步智能体，我发现我需要再留出专注时间来跟进我发起的各种异步工作。

Well, it's interesting because I used to block out focus time for coding, but now with more async agents, I find I need to block focus time just to catch up on all the async work I've kicked off.

是啊，你有什么解决办法吗？这很难。人们就是想做越来越多的事，但怎么才能不频繁切换上下文呢？真的很烦人。

Yeah, do you have any thoughts on a solution? That's hard. People just want to do more and more, but how do you do that without constant context switching? It's really hard and annoying.

是的，我同意。我肯定还没找到解决办法。

Yes, I agree. I definitely haven't cracked it yet.

真有意思。有个问题我很想听听你的看法。是关于工作和招聘的。你觉得 AI 会让工程师变得不那么必要，但你们却在疯狂招人。你觉得这会怎么发展？工程师角色的未来是什么？

So interesting. There's a question I'm excited to hear your answer on. It's about jobs and hiring. You think AI would make engineers less necessary, but you guys are hiring like crazy. Where do you think this goes? What about the future of the engineer role?

我来坦诚说一点。一个很大的开放问题是我们如何培养下一代。你和我走上工程道路的方式截然不同。当你从学校毕业，怎么加速这个过程？但对我来说重要的是，他们仍然理解深入到底层细节的那种“双击”。我想知道软件工程是不是更像一种研究员或学徒项目。我知道实习只有三个月，做小项目，但我想知道如何把我们获得的一些人生经验压缩进去，教给下一代建设者。

I'll share some vulnerability here. One big open question is how we grow the next generation. How you and I got to our engineering path is so different. When you graduate from school, how do you fast-forward it? But the important thing to me is that they still understand the double-click down to the layer of an eight. I wonder if for software engineering, it's almost like a fellowship or apprenticeship program. I know internships are only three months with small projects, but I wonder how to cram in some of the life experiences we got and teach that to the next generation of builders.

没错，如果你从来不需要看代码，那新软件工程师有什么动力去真正理解基础设施如何工作、内存分配以及所有那些基础的东西呢？

Right, if you never have to look at code, what's the incentive for a new software engineer to truly understand how infrastructure works, memory allocation, and all those foundational things?

这很有趣。也许模型会变得足够好，以至于这都不重要了，但我确实认为那种深入理解是有意义的，因为那可能是改进产品或系统的机会。但如何学会这一点，不一定非得靠多年写代码。

And it's interesting. Maybe the models will get good enough that it doesn't matter, but I do think there's something about that double-click because that's where there might be an opportunity to improve the product or system. But figuring out how to learn that not necessarily by years of typing code.

是啊，总得有人在某个层面上理解代码。就像有些 COBOL 工程师，有一天不得不被从退休中拉出来：‘你还记得怎么写 Python 吗？’

Yeah, somebody has to understand code at some level. It's like some COBOL engineer they have to pull out of retirement one day: 'Do you remember how to write Python?'

你知道什么很有趣吗？我的一位前经理是从打孔卡时代开始做软件工程师的。他一直在给我发他用 Claude Code 构建的东西。想想他的职业生涯：他从打孔卡开始，完全不一样。看看什么仍然重要、什么会改变，会很有意思。也许重要的东西会随着时间推移而变化，我们需要建立相应的熟练度。

You know what was really fun? One of my previous managers started as a software engineer when it was punch cards. He's been messaging me everything he's been building with Claude Code. I think about his career: how he started with punch cards was totally different. It'll be interesting to see what remains important and what changes. Maybe the important things shift over time, and we need to build proficiency in them.

哦对，只学真正重要的东西。我经常听到的说法是，这是一个新的抽象层次，就像汇编和二进制一样——它不断上升。现在我们不需要看代码了；这是一个新的抽象层：提示词和 Claude 的思考消息。

Oh yeah, just learn the things that really matter. The argument I constantly hear is that it's a new level of abstraction, just like assembly and binary—it keeps going up. Now we don't need to look at the code; it's a new layer of abstraction: prompts and Claude's thinking messages.

是啊，也许关键是什么是有趣的问题，什么经验值得优先积累。当你构建东西时，你怎么知道它引起了共鸣，并且达到了预期效果？

Yeah, and maybe it's about what is an interesting problem, what's the prioritization for experience to build. When you build things, how do you know it's resonating and doing what you intended?

而且它好吗？我们是在建一堆垃圾，还是这真的是可行的架构？我认为年轻人的优势在于，他们更容易投入并以这种新方式工作，而不是固守旧方式。像你这样长期工作的工程师能适应并拥抱这一点，真是令人惊讶。改变一切太难了。

And is it good? Are we building a bunch of slop or is this actually architecture that will work? I think the advantage for young people is it's so much easier to lean in and work in this new way versus being stuck in the old ways. It's amazing how many long-time engineers like yourself have adapted and embraced this. It's so hard to change everything.

嗯，变化的速度也很快。我记得第一次用 Sonnet 3.5 或 3.6 时，它还会犯错。但一些抵制 AI 工具的工程师会指出这些错误。很难理解那种指数级的改进速度。也许我尝试自动化的事情还不够好，但在下一个模型里就好了。所以总是值得重新审视那些没成功的事情，因为现在可能有了新能力。

Well, the rate of change is also so fast. I remember the first time I used Sonnet 3.5 or 3.6, it was still making mistakes. But some engineers resisting AI tooling would point out those mistakes. It was hard to understand the exponential rate of improvement. Maybe something I tried to automate wasn't good enough, but in the next model it was. So it's always worth revisiting things that didn't work, because now there might be a new capability.

是啊，这个播客里经常提到这一点。就构建那些几乎能用的、处于边缘的东西，因为一旦模型达到那个水平，你就会遥遥领先。好了，最后一个问题。你可能已经回答了，但什么让你夜不能寐？

Yeah, that comes up a lot in this podcast. Just build something that is almost working, at the edge, because once the model gets there, you'll be so far ahead. Okay, final question. You may have already answered this, but what keeps you up at night?

让我夜不能寐的可能是我们如何……我们谈到了 Claude Code 和协作团队文化。

The thing that keeps me up at night is probably how we... we talked about Claude Code and co-work team culture.

团队文化对我来说非常重要。这是一种“一个团队”的心态，我也经常和同事们分享。而且，文化是活生生的东西，不是贴在墙上的海报，它会随着时间变化，体现在我们如何对待彼此、如何互相支持。所以，团队文化对我来说很重要，因为我们在成长，文化也在变化。确保那些重要的东西得以保持，对我来说非常关键。我希望有多元化的视角，这样我们才能进行健康、开放、诚实的辩论，我们欢迎这些辩论。我称之为“一个团队”的心态：当你接近终点线时，回头看看是否有团队成员需要帮助，因为我们是一起完成任务的。这大概就是让我夜不能寐的事情。还有很多其他难题，但我觉得很多都是产品或工程上的挑战，我们有仪表盘、理论或假设，但文化是人的方面。我认为这是我一直想确保的：随着我们的成长，我们仍然保持那种文化，因为它是团队的根基。当它开始偏离时，我总是担心：如果它偏离了，我们是否及时发现了，并作为团队一起讨论，确保我们都希望文化朝着正确的方向发展？

That's and the team culture is really important to me. Like it's the one team mentality and I share with folks. And by the way, culture is like a living breathing thing. It's not just a poster you slap on a wall and it changes over time and it shows up in how we treat each other, how we're there for each other. So, the culture of the team is important to me because we are growing and since the culture shifts, making sure that maintaining the things that are important, it's really important for me to have diverse perspectives so we can have healthy open honest debates in the open and we welcome those. And I call that one team mentality: when you get close to the finish line, look behind you and see if there's someone on our team to help, because we finish as a team. That's probably the thing that keeps me up at night. There are so many other hard problems, but I think a lot of the other ones are product or engineering challenges that we have dashboards or theories or hypotheses, but the culture is a human aspect. I think that's the one I always want to make sure that as we grow, we still maintain that culture because it is the fiber of the team. When it starts drifting, I'm always worried: if it drifts, are we catching it and having conversations as a team together to make sure we all want the culture to grow in the right direction?

是的，我想每个人都在为此挣扎，考虑到变化的速度和招聘的速度，尤其是像 Anthropic 这样的公司，正处在历史上最疯狂、最前所未有的增长轨道上。我能理解在这么多变化中这有多难。这很合理。即使在我待过的 Airbnb，那也是一个相当大的增长轨迹，但和你们经历的完全没法比。那也是一个持续讨论的话题：我们如何保持文化？

Yeah, I imagine everybody is struggling with this considering the pace of change and the pace of hiring, especially a company like Anthropic that's in this crazy, most unprecedented growth trajectory in history. I could see how that could be a challenge with so much change. It makes sense. Even at Airbnb when I was there, that was quite a growth trajectory and that was nothing like what you guys are going through. And that was a constant topic of conversation: how do we maintain the culture?

实际上，我很好奇你在 Airbnb 的经历，你们在成长过程中是如何保持文化的？

Actually, I'm curious what was your experience at Airbnb to maintain the culture as you were growing?

其中一个有效的做法是：创始人对文化非常执着。每次全员大会、每次大型会议，都会提醒大家文化和价值观。创始人自上而下地痴迷于此，这占了很大一部分。没有一次会议不提到这个。另一个我经常回忆起的记忆是：我们请来了 Meta 的 Sheryl Sandberg 做炉边谈话，有人问她如何在规模化时保持文化？因为我们发展太快，很难应对所有这些变化、文化和新人。她的建议是：这其实是你想要的问题，因为这表明你在成长，做得很好。这是正常的。如果你做得不好，什么都不会改变。那种不成长、不疯狂招人的情况要糟糕得多，会造成更多痛苦。所以你现在面对的是一个好问题。这个建议一直留在我心里。

One thing is just what worked well: the founders being obsessed with it. Every all-hands, every big meeting, just reminding of the culture and the value of the culture and what the values are. The founders top-down being obsessed with it was a really big part of it. It just couldn't have a meeting without that coming up. The other is a memory I always come back to: we had Sheryl Sandberg from Meta come to do a fireside chat and somebody asked her how do you maintain culture as you scale? Because we're going so fast and it's so hard to deal with all this change and culture and all these new people. Her advice was: this is actually the problem you want to have because this means you're growing and doing well. This is normal. Nothing will change if you're doing badly. That's a much worse situation when you're not growing and you're not hiring like crazy. That's a much worse situation that will cause even more suffering. So this is a good problem you're dealing with. That advice has always stuck with me.

哦，那太好了。这很有趣。你提到，我认为在 Claude Code 和协作团队中，重要的事情之一，无论是个人贡献者还是管理者，但我特别要求团队中的管理者：我们不仅要谈论进展顺利的事情，还要坦诚地谈论不顺利的事情。因为如果我们能真正讨论不顺利的事情，我们才能解决它。说到让我夜不能寐的事情，我的噩梦是，如果某人是管理者，我问‘嘿，事情进展如何？’他们回答‘一切都好。’我会想，‘天哪，我不好。我知道事情并不好。’这就像那个 meme：医生猫在着火的房间里喝咖啡。那就是我的噩梦。所以这实际上是我和团队中很多人，尤其是新加入的管理者讨论的话题：‘嘿，我们一定要保持这种开放的对话，这样我们才能一起解决问题。’

Oh, that's great. It's interesting. Here you talk, I think one of the important things to kind of Claude Code and co-work team is whether ICs or managers, but this is a thing I especially ask for managers on the team: it's really important that we all talk about what's going well, but also just be open about what's not going well. Because if we can actually have a conversation about what's not going well, that's how we can actually address it. Speaking of what keeps me up at night, my nightmare is especially if someone's in a manager position and I'm like, 'Hey, how are things going?' and they say, 'Everything's fine.' I'm like, 'Oh my gosh, I'm not doing fine. I know things are not fine.' It's like that meme of the doctor cat with a cup of coffee in a room that's on fire. That is my nightmare. So that's actually a discussion I have with a lot of folks on the team, especially managers when they first join: 'Hey, let's always have these open conversations so that we can solve problems together.'

我想很多人都在挣扎：看到周围很多人做得非常好，至少表面上看起来很好。一切都很顺利。我在发展这家很棒的公司。很难真正诚实地说‘并不顺利，我在挣扎，我在落后’，因为周围每个人表面上都觉得自己干得很棒。

I imagine there's something a lot of people struggle with: seeing so many people around them doing super well, at least seemingly doing well. Everything's going great. I'm growing this awesome company. It's hard to actually be honest and say it's not going great. I'm struggling here. I'm falling behind because everyone around you is just on the surface feeling like they're killing it.

嗯。

Mhm.

是的。在我们进入非常激动人心的快速问答环节之前，你还有什么想留给听众的吗？还有什么我们没有覆盖到的，或者你想分享的重要事情？

Yeah. Before we get to our very exciting lightning round, is there anything else that you either want to leave listeners with, anything else that we didn't cover, anything else that's important that you wanted to share?

也许有一件事只是一个建议。你知道，我们讨论了 Claude 如何实现自动化。在 Claude Code 和核心团队文化中，另一件非常重要的事情是明确允许废除不再服务于我们的流程。所以，也许给任何在我们团队工作或领导团队的人一个建议：找出一个你害怕做、或者噪音很大、或者非常昂贵（比如很多手工工作）的流程。选一个，首先问：它还有存在的意义吗？例如，甚至我们的规划。实际上，那是我刚加入 Claude Code 时第一个重要的学习。我说，‘嘿，也许我们应该做一个六个月的路线图文档，但我们要做得非常轻量，因为我不想浪费太多时间做规划。’我觉得我们做了一个非常轻量的流程。但那对我来说是一个很好的学习，因为那个练习有助于启动对话并确保我们保持一致，但三个月后，我想，‘等等，我们还在参考它吗？’因为变化太大了。那也是我自己带来并改变的东西，想着‘嘿，也许这会有帮助。’所以，永远保持开放学习的心态，并经常问自己：你现有的流程，它还在服务于它的目的吗？因为领域变化太快了。

Maybe one thing is just a suggestion. You know, we talked about how Claude can automate things. One other thing that's really big on Claude Code and Core team culture is explicit permission to kill processes that no longer serve us. So maybe a suggestion is for anyone on our work and our team or leading teams: take your, what's one process that you either dread doing or is really highly noisy or is really expensive in terms of a lot of manual work? Pick one thing and first ask: is it still serving its purpose? For example, even our planning. Actually, that was my own big first learning when I first joined Claude Code. I said, 'Hey, maybe we should do a six-month roadmap doc, but we're going to do it super lightweight because I don't want to waste a lot of time planning.' And I felt we did a really lightweight process. But that was such a good learning for me because the exercise was good to kickstart conversations and ensure we're aligned, but three months into it, I'm like, 'Wait, have we still referenced it?' Because so much has changed. And that was also something I changed to that I myself brought in, thinking, 'Hey, maybe this will help.' So always be open to learning and always ask yourself: whatever process you have, is it still serving its purpose? Just because the field is changing so fast.

我喜欢这个建议。我得快速跟进一下这个问题。

I love that advice. I got to follow up on this real quick.

那么，你现在是怎么考虑规划的？你们做规划吗？是不是就像一个月度的路线图？简单来说，你们现在是怎么做的？

So, what is it? How do you think about planning now? Do you do any planning? Is it just like a month-long road map? What's kind of like the simple way to explain where you're at with that?

是的，我现在称之为 JIT 规划，也就是即时规划。因为我觉得六个月太长了。所以现在，虽然有些项目确实会超过一个月，但我们尽量只做一个月规划，非常轻量。实际上，连文档都没有，我们只是在一个小表格里对齐一下我们认为重要的事情。但即使这样，我也在想，'嘿，也许我们每周还是应该确认一下这个月的优先级是什么。'我们打算试试看，但我感觉可能每周我们都会快速检查一下，'嘿，确认一下，这仍然是这个月的优先级。好的。'嗯，是的，现在我们把它缩减成了 JIT 月度规划。

Yeah, I call it JIT planning now, like just-in-time planning. So, it is around like because yeah, I think 6 months was too long. So, now for sure some projects will take more than a month, but we try to do like a month of planning, really lightweight. Actually, there's not even docs. It's really just us aligning on a little spreadsheet of what we think is important. But even that one, I'm kind of thinking through, 'Hey, like every week we should probably still keep a like what we're trying is here are the month's priorities.' And we're going to try it out, but I have a feeling like every week we'll probably want to do really quick like, 'Hey, just to check. Yep, this is still this month's priorities. Good.' Um but yeah, like now we've shrunk it to JIT monthly planning.

所以，月度规划就是，对于下个月，我们有一个小表格或 Excel，列出我们计划要做的事情。然后每周检查一下，这仍然是下个月的计划吗？

So, it's monthly meaning for the next month, here's a little sheet/Excel spreadsheet of what we're planning to do for the next month. And then every week check in, is this still what we're planning to do for the next month?

是的，非常非常……但即使这样，我仍然在想，'我们怎么能进一步自动化呢？'因为我从不希望当有人需要更新表格时，这变成一种负担。所以，实际上，就在昨天我们还在聊，'嘿，我们怎么才能真正自动化这个？'嗯，这就是要问的问题，总是问自己，'我们能更好地自动化这个吗？'

Yeah, it's yeah, like very very we But even that one, I'm also still feeling, 'How can we even automate this more?' Because I never want it to feel like a tax when someone has to, you know, update the spreadsheet. So, this is actually yeah, like just yesterday we were chatting, 'Hey, how can we actually automate this?' Well, it's getting to that question, always ask yourselves, 'Can we actually automate this better?'

我的产品经理大脑在想，这怎么可能不做呢？

Like my PM brain is like, that's so like how could you not do something like that?

好的，这是我们下个月的想法。我们每周检查一次。确保这……很难想象不这样做。而且我听说你的表格上项目也不多。

Okay, here's what we're thinking for the next month. Let's just check it once a week. Let's make sure this is like it's hard to imagine that not happening. Um and you don't have a lot of items on the spreadsheet is what I'm hearing also.

是的，但我们真的努力聚焦。所以我们会分享我们认为的最高优先级。然后，对于那个机构，给定这些优先级，每个人都有自己的项目，他们认为如何解决这些优先级。

Yeah, but we really try to focus. So, we will share out like here's what we think are the highest priorities. And again, for that agency of given the priorities, then everybody's like their kind of like item for how they think addresses those priorities.

有没有像未来六个月的大赌注之类的东西？还是我们只考虑未来一个月？

Is there anything that's like here's for the next like 6 months bigger bets kind of stuff or is it just like let's just think 1 month ahead?

我喜欢这样。我们通常会有一些主题，关于我们认为工作方向在哪里。实际上，整个团队每六个月会聚在一起。那时我们会启动一些主题，但关键是保持对变化的感知，因为即使主题变化很快，当格局改变时。

I like so we'll usually definitely there's themes of where we think the work and so we'll definitely like um and actually the whole team will bring everyone together uh like every 6 months. So there we'll usually kick off like some themes but then it's really the making sure we keep the pulse of what because again like even though themes change you know so fast when uh the landscape changes.

好的，让我们打开表格看看。

All right, let's pull up the spreadsheet and let's take a look.

哦，天哪。这整个播客本来可以只聊你们做的这些规划。好吧，我得找别人来聊这个，因为你们的规划方式太有趣了。嗯，好的。那么，Fiona，我们到了非常刺激的快问快答环节。我有五个问题要问你。准备好了吗？

Oh man. Man, this whole podcast could have been just talking about this planning stuff they do. Okay, I'm going to have to find someone else to talk about this because this is so interesting just how y'all plan. Uh yeah, okay. Well, Fiona, with that we reached our very exciting lightning round. I've got five questions for you. Are you ready?

准备好了。

Ready.

好的，第一个问题。你经常向别人推荐哪两三本书？

Okay, first question. What are two or three books that you find yourself recommending most to other people?

哦，对于小说，我实际上会推荐两位作家给所有人：玛格丽特·阿特伍德和村上春树。嗯，就是这两位。我在加拿大长大，所以小时候读了很多阿特伍德的作品，但她的书很迷人，因为几乎像是思辨小说，你可以眯起眼睛说，好吧，这真的可能发生在一个社会上吗？所以我喜欢她对思辨小说的处理。村上春树，我喜欢他的魔幻现实主义风格。嗯，但有一本书，虽然我推荐的是作家，但有一本书我总是推荐给每个人，至少每年读一次，那就是《小王子》。我想我们可能都在人生的某个时刻读过它，但我认为它……我每年至少读一次。它只是提醒我去思考什么才是真正重要的。

Ooh, I will say for fiction actually two authors I recommend to everyone, Margaret Atwood and Haruki Murakami. Um those are just two like like I mean I grew up in Canada so I read a lot of Atwood growing up but her books are fascinating because it's almost like speculative fiction of you can kind of squint and say okay could this actually you know happen to a society. So I love her take on speculative fiction and Murakami I love his magical realism style. It's um but then the one book so there are authors but the one book I always recommend to everyone to read at least once a year or you know um The Little Prince. I like I think I'm sure we probably all read it at some point in our lives but I think it's a I read it at least once a year. It just you know, to remind me to think about like kind of like what's truly important.

哇。这个不常见。好的，我喜欢。嗯，最近你非常喜欢的电影或电视剧是什么？

Wow. That doesn't come up a bunch. Okay. I love it. Uh favorite recent movie or TV show you have really enjoyed?

我没看电视剧。

I haven't watched TV shows.

这在播客里我采访过的 Anthropic 员工中很常见。共同主题。

That's very common across Anthropic people I have on the podcast. Common theme.

但我会分享我手机里总是下载好的东西，这样我在飞机上就能看。有三部电影我手机里一直有，因为我觉得它们很有趣，有时间就可以看。一部是《天使爱美丽》。这是一部法国电影，哦天哪，顺便说一句，这些电影都很老了，算是经典电影。但我很喜欢《天使爱美丽》，非常奇幻。所以强烈推荐给没看过的人。你知道，如果你还记得我说过，我本来以为自己会成为视觉艺术家。我 16 岁时，高中组织了一次去巴黎的旅行，那给我留下了很多回忆，《天使爱美丽》真的捕捉到了我在巴黎感受到的魔力。另外两部是吉卜力电影。我喜欢《千与千寻》。嗯，它就是这样……我就是喜欢那个故事。我喜欢，是的，我喜欢《千与千寻》的一切。它可能是我最喜欢的吉卜力电影之一。第三部是另一部吉卜力电影，《风之谷》。我经常想到这部，因为如果有人问我，'嘿，你是怎么想到所有这些领导特质的？'我想我大概八九岁时看了这部电影。女主角娜乌西卡，看到她如何领导，在我心中留下了深深的印记，可以说娜乌西卡给了我很多启发，也影响了我许多不同的领导原则。

But I will share with you what I always have downloaded on my phone so that if I'm on the airplane. So there's three movies I always have on my phone because I think they're just so fun to watch if I have time. One is Amelie. It's this French movie that oh my gosh, all of these movies are going to be very old by the way. It's going to be like vintage movies. But I loved Amelie. Super whimsical. So really highly recommend it to anyone that haven't seen it. It's you know, if you remember I told you I was going on a I thought I was going to be a visual artist. So when I was 16, my high school we took a trip a high school trip to Paris and that just I've so many memories of that and Amelie really captures the magic I felt at Paris. And the other two are Ghibli films. I love Spirited Away. That's um it's just such a like just such a I just love that story. I love the yeah, like I just love everything about Spirited Away. It's probably one of my favorite Ghibli films. And then the third was another Ghibli film um Nausicaa Valley of the Wind. And I think about this one quite a bit because if anyone asked me, 'Hey, how did you kind of think about you know, all these leadership traits?' I think what I watched that movie probably when I was eight or nine. And the heroine Nausicaa and how she seeing how she leads just left such a like um just left such a footprint in my heart I guess you could say that probably Nausicaa has inspired me a lot and a lot of my different leadership principles.

哇，那本书叫什么来着？

Wow, what is that book called again?

嗯，电影叫《风之谷》，但它其实是基于漫画改编的。

Uh the movie's called Nausicaä of the Valley of the Wind, but it was actually based on a manga.

《风之谷》。所以，就像安迪·格鲁夫的《高产出管理》和《风之谷》的娜乌西卡。

Valley of the Wind. So, it's like High Output Management Andy Grove, Valley of the Wind Nausicaä.

没错。

That's right.

两本顶级管理书。太酷了。好的。嗯，你最近有没有发现特别喜欢的产品？可以是应用、衣服、小工具、厨房用具。

Two top management books. So cool. Okay. Uh do you have a favorite product you recently discovered that you really love? Could be an app, could be clothing, could be a gadget, could be kitchen equipment.

我想分享一个产品，最近我意识到它对我的生活有多大影响。嗯，因为我最近经常旅行，而且我喜欢轻装出行。

I'll share the product that I was reminded of how much has made a difference in my life recently. Uh because I've been just traveling a little bit and so I don't and I like to travel really light.

所以，我都是用酒店提供的洗发水和护发素。我忘了其实我有一款他们的产品——我保证这不是广告——Sweet Sisters Bodycare。这是惠德比岛的一家本地企业。他们的产品之所以对我的生活产生巨大影响，是因为它是一整套有机头发、身体和护肤产品。几年前，我鼻子上开始长皮疹，非常疼，甚至流血。我完全不知道该怎么阻止。我试过不用任何乳液，脸上什么都不涂，但还是很疼。然后有人问我：‘你用什么洗发水？’我说：‘我从十几岁开始就一直用同一种。’他们说：‘也许你的身体对里面的化学物质产生了过敏。’我当时想：‘什么？’于是我找到了这款有机洗发水。果然，用了他们的洗发水——因为你不会想到洗头的时候水会流到身体其他部位。从那以后，我把所有东西都换成了 Sweet Sisters。最近我又想起了这件事有多重要，因为用了一周酒店洗发水后，我的皮肤又开始有反应了。我想：‘也许我应该买旅行装瓶子随身带着。’

So, I use whatever shampoo and conditioner the hotel gives. And I forgot that I actually have one of their products—I promise this is not an infomercial—but Sweet Sisters Bodycare. It's a local business on Whidbey Island. The reason their product has made such a big difference in my life is that it's a full line of organic hair, body, and skin care. A few years ago, I started getting this rash on my nose that was really painful, actually bleeding. I couldn't figure out how to stop it. I tried not using any lotions, cut everything out on my face, but it still hurt. Then someone asked, 'What shampoo are you using?' I said, 'It's the same one I've used since I was a teenager.' They said, 'Maybe your body has developed an allergy to the chemicals in it.' I was like, 'What?' So I found this organic shampoo. Lo and behold, I used their shampoo—because you don't think that when you wash your hair, it goes over the rest of your body. Since then, I've switched everything to Sweet Sisters. I was recently reminded of how important this is because after a week of hotel shampoo, I started having skin reactions again. I thought, 'Maybe I should get travel-size bottles to bring with me.'

这个推荐太棒了。我喜欢本地企业的推荐，加分不少。顺便说一下，你这次旅行——可能有些人不知道——世界各地都在举办 Code with Claude 活动。我去了旧金山的那场，伦敦也有一场。你要去东京的那场。这是最后一站吗，还是之后还有更多？

This is an awesome pick. I love local business picks, even big bonus points for that. By the way, this travel you're doing—just for folks that may not know—there are these Code with Claude events happening all over the world. I went to the one in SF. There was one in London. You're going to one in Tokyo. Is that the end of it, or is there more after that?

东京是下周，那是这次旅行的最后一站。

Tokyo is next week, and that's the last leg of the trip.

然后未来可能还会有更多。太酷了。我很高兴看到这些活动。好的，还有两个问题。你有没有最喜欢的人生格言，在工作或生活中经常用到？

And then probably more in the future. So cool. I love that that's happening. Okay, two more questions. Do you have a favorite life motto that you find yourself coming back to often in work or in life?

在工作中，我真的很喜欢提醒大家保持简单。你真正想做好的是什么？专注于那件事。保持简单，因为我觉得有时候我们会想太多。这是一个很好的座右铭。在生活中，可能是：在一个你可以成为任何人的世界里，要善良。

In work, I really love to remind folks to keep it simple. What is the thing you're really trying to do well, and focus on that? Keep it simple, because I think sometimes we can overthink. It's always a good mantra. In life, probably: in a world where you can be anything, be kind.

是的。我喜欢这句。我们去参观一所蒙台梭利学校时，老师就把这句话挂在墙上。

Yeah. I love that one. We were at a Montessori school tour, and that's what the teacher had up on the wall.

我们有太多事情要处理，你永远不知道别人生活中发生了什么，一个小小的善举就能带来巨大的改变。对我来说，这就是我在疫情期间记得的事情。我们都在家工作。我连续开会，一对一会议对我来说非常重要，因为那段时间通常对对方也很重要。他们可能有事情要讨论。所以我总是优先安排一对一会议。在那段时间，我祖母身体不好，她在加拿大的一家养老院，因为疫情，我无法去看望。甚至我姑姑和我妈妈也不能去。偶尔如果有护工帮忙，我们可以视频通话，但你永远不知道什么时候能通。突然，我姑姑发消息说：‘祖母今天中午 12 点可以视频。’我想：‘哦不，我正好有一个一直想开的一对一会议。’我给我的下属发消息说：‘真的很抱歉，这么临时通知。可以改期吗？’他说：‘没问题，完全没问题。’对我来说，这就是一个小小的善举。他没有把它当回事，但这对我影响巨大，因为我终于能和祖母视频通话了。

We have so many things going on that you never know what's happening in someone else's life, and one small act of kindness can make the biggest difference. For me, that was what I remembered from COVID. We were all working from home. I was in back-to-back meetings, and one-on-ones are really important to me because that time is usually also important for the other person. They might have things to discuss. So I always prioritize one-on-ones. During that time, my grandmother wasn't doing well; she was in a home in Canada, and because of COVID, I couldn't visit. Even my aunt and mom couldn't visit. It was rare that if they had a helper, we could do FaceTime, but you never know what time that will be. All of a sudden, I got a message from my aunt saying, 'Grandma can FaceTime at 12:00 p.m. today.' I thought, 'Oh no, there's this one-on-one I've been meaning to have.' I messaged my report and said, 'I'm really sorry. It's so last minute. Is it okay to reschedule?' He said, 'Yeah, totally. No problem at all.' For me, that was a small act of kindness. He didn't make it a big deal, but it made the biggest difference to me because I got to say hi to my grandmother on FaceTime.

我喜欢这个故事。好的，最后一个问题。鲍里斯·切尔尼，当我问起你时，他有一个有趣的见解：‘在非常重要的会议上，你经常能听到菲奥娜在背景里织毛衣的咔嗒声。’能说说这是怎么回事吗？你最近织了些什么？

I love that. Okay, final question. Boris Cherny, when I asked him about you, had this interesting insight: 'In very important meetings, you can often hear the click-clack of Fiona knitting in the background.' Maybe talk about what's going on there and what are a couple things you knitted recently?

哦天哪。嗯，我最近织了这件上衣。你给自己做衣服，太不可思议了。这对于 Claude Code 自我构建来说非常元。你知道，我们总是在构建自己的衣服。实际上，编织和编程之间有一个有趣的联系，因为编织就像两种针法：下针和上针，所以是 0 和 1。很多栈和队列的概念实际上都适用。我有点像编译器，编织的时候就在生成可执行文件。不过我也不确定。实际上，是我祖母在我八岁时教我织毛衣的。我提到过她，我常去那家毛线店。所以每次织毛衣，我都会想起她。我总喜欢一心多用，就像你看到的。我同时启动多个智能体，所以只要我坐着——因为我练习得足够多，已经很熟练了，不用看自己在做什么——这就像有些人玩指尖陀螺一样。织毛衣就是我坐着不动时做的事情。我想：‘哦，这是生成更多编织品的时间了。’很可爱。我有很多毛线，如果不织的话，我可能有点毛线上瘾的问题。

Oh my gosh. Well, I knitted this top recently. You make your own clothing. Unreal. This is very meta for Claude Code building itself. You know, we're always building our clothing. Actually, there's a fun thing between knitting and programming because it's kind of like two stitches: knit and purl, so it's zero and one. Many concepts of stacks and queues actually apply. I'm kind of like a compiler, generating an executable when I knit. But I don't know about that. Actually, it was my grandma who taught me to knit when I was eight. I kind of mentioned her, and I go to that yarn shop. So every time I knit, I think of her. I always like to multitask, as you can see. I kick off multiple agents, so anytime I'm sitting—because I practice enough and got proficient, I don't have to look at what I'm doing—it's almost like how people have fidget spinners. Knitting is just something I do anytime I'm sitting still. I think, 'Oh, this is time to generate more knitting.' It's cute. I've got so much yarn that if I don't do this, I might have a slight yarn addiction problem.

我喜欢这个。当我问鲍里斯，当 AGI 到来、我们不用工作时他会做什么，他说他会让我做。所以我猜你的答案就是织毛衣，做漂亮的衣服。

I love this. When I asked Boris what he would do when AGI hits, when we don't have to work, he said he's going to make me. So I'm guessing your answer would be just knit and make beautiful clothing.

哦天哪，我的梦想是以我祖母的名义开一家毛线店，创建那样的社区。

Oh my gosh, my dream is to actually open up a yarn store in my grandmother's name and create that community.

然后协同工作会帮忙，你把一切都自动化。

And then co-work would help out, you automate everything.

没错。

That's right.

尤其是发票处理。天哪，Fiona，你太棒了。你和你的团队正在以如此深刻的方式改变世界，这太不可思议了，而且很明显为什么它发展得这么快。干得好，干得好。谢谢你抽出时间。

Especially invoicing. Oh my god. Fiona, you're awesome. It's just incredible the work that you and your team are doing just changing the world in such profound ways and there's no it's clear why it's growing so fast. So good job. Good job over there. Thank you for making time for this.

嗯，我真的非常幸运和谦卑，能与如此出色的团队合作。我知道自己有多幸运，我充满感激。但也非常感谢你邀请我参加播客，这非常有趣。

Well, I'm just really honestly lucky and humble that I get to work with such an amazing team. Like I know how lucky and I am I am and I'm so grateful. But thanks a lot for having me on the podcast as well. This was a lot of fun.

嗯，关于后续问题，如果大家想联系你，可以在网上哪里找到你？听众怎样才能帮到你？

Uh to follow up on questions, where can folks find you online if you are online if they want to follow up on anything and how can listeners be useful to you?

哦，嗯，我肯定在 LinkedIn 上，我相信大多数人都已经分享过了。但我很希望得到反馈，哪些做得好，哪些不好。嗯，还有你们正在使用的任何潜在需求，可能是有趣的用例。你知道，最近有个朋友给我发消息说，哦，我正在用 Claude 帮我生成一个棚屋的建筑平面图，他还给我看了他的棚屋，很酷。所以我很想听听这些。然后，是的，也许还有，你知道，我们谈到过联系那些你喜爱的小企业，或者你觉得还没有接触过 AI 的人，因为有些听众是超级 AI 达人。是的，也许花点时间手把手教他们，展示 AI 能如何帮助他们。

Ooh, uh so definitely I'm on LinkedIn and I'm sure most people have shared this already but would love feedback of what's going well, what's not going well. Um also any latent demand that you are all using that might be interesting use cases. You know, I had a friend message me recently to go, oh I'm using Claude to help me generate uh a building plan for my shed and he actually showed me his his shed, which was cool. So would would love to hear about that. And then yeah, maybe also, you know, we talked about reaching out across over there's someone whether a small business that you love or or someone that you feel like hasn't you know, as some of the listeners are super AI pill. Yeah, maybe take a time to hold somebody's hand to show what's AI might be able to help them with.

说得太好了。这个回答非常棒，尤其是出自你之口，Fiona。太棒了。非常感谢你来到这里。

Such a good one. That is such a good answer to this question. Especially coming from you, Fiona. This was awesome. Thank you so much for being here.

非常感谢你的邀请，Lenny。

Thanks so much for having me, Lenny.

大家再见。非常感谢收听。如果你觉得本期有价值，可以在 Apple Podcasts、Spotify 或你喜欢的播客应用上订阅节目。另外，请考虑给我们评分或留下评论，这真的能帮助其他听众找到这个播客。你可以在 lennyspodcast.com 找到所有过往剧集或了解更多节目信息。下期再见。

Bye 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 leaving a review as that really helps other listeners find the podcast. You can find all past episodes or learn more about the show at lennyspodcast.com. See you in the next episode.