从瓶颈到突破：扩展 Claude Code 的团队经验

嘿，各位，能听清吗？好的，我发誓这不是 Claude Code 的事，但你们介意我拍张照吗？因为 Boris 和 Jared 的场次是 2 点，我本以为这里会空无一人。我想，不可能还有人从那个场次过来吧。所以，天哪。

Hey folks, do y'all hear me okay? Okay, I swear this is not a Claude Code thing, but do you guys mind if I take a photo? Because Boris and Jared had their session at 2:00 and I really thought this was going to be empty. I'm like, there is just no way people would still be coming in from that session. So, Oh my gosh.

谢谢，提示词。我保证我和 Boris 不是总在自拍。

Thank you, prompt. I promise me and Boris don't just do selfie words all the time.

但下午好，感谢各位出席。所以，是的，我叫 Fiona Fung，负责 Claude Code 和 Cowie 的工程与产品。我和 Boris 和 Cat 合作非常紧密。在加入 Anthropic 之前，我曾在 Meta 和微软领导并壮大过团队。那么，对于今天的演讲，这算是总体议程，核心思想是，在帮助 Claude Code 和 Cowie 成长以及我们建设这个团队的过程中，我学到了哪些经验教训。以及哪些东西——这很有趣，即使回顾我在 Meta 或微软，甚至 Anthropic 的经历，这些经验也很有意思。有趣的是，我大概一个月前做了这套幻灯片，但已经不得不修改一些内容，因为比如，我刚开始做这套幻灯片时，还没有 routines（例程），那种工作方式对我来说也是全新的。所以，是的，我们确实想——我想涵盖我注意到的五个主题。

But good afternoon and thanks for attending. So, yeah, my name is Fiona Fung and I lead Claude Code and Cowie engineering and product. So, I work really closely with Boris and Cat. And before Anthropic, I had led and grown teams at Meta and then also Microsoft. And so, for today's talk, this is kind of like overall agenda, but the whole idea is what are some of the lessons I learned and helping Claude Code and Cowie kind of like grow and as we're building out this team. And kind of like what things I and it's it's interesting as lessons I learned even if I think about my time at Meta or even Microsoft, but even Anthropic. Like it's funny, I did this slide deck maybe like a month ago and also already I've had to change some of the content cuz for example, when I started this deck, there were no routines and that even like that way of working was different for me. And so, yeah, like we really want to like I want to kind of cover five themes that I've noticed.

第一个是瓶颈已经转移了，它们发生了移位。那么，当瓶颈转移时，我们在 Claude Code 团队内部不得不重写哪些团队规范？我还想分享一些关于我们必须重写的这些团队规范，我们是如何推出的，以及一些证据，比如一些信号，表明我们正朝着正确的方向前进。对我来说，始终重要的是要审视它是否仍然有效，是否仍在朝着正确的方向前进？然后我会以一些我仍然在思考的问题作为结尾，还有一些建议，供你们采取行动，与你们的团队展开对话。那么，第一部分，瓶颈已经转移。我称之为“转变”。但你们可能会经常听到我重复这个副标题，那就是“过去对你有用的，可能不再适用”。实际上，即使回顾我所有的经历，无论是在 Anthropic、Meta 还是微软，持续成长的心态一直是一块非常好用的肌肉。尤其是现在，变化的速度——我不知道你们是否感受到了——变化的速度有点疯狂，对吧？比如我记得去年我第一次开始做一些现场编码，它还会犯一些错误，我会说：“啊，为什么你到处都用常量？这不是好的工程实践。”而现在，它已经变得如此强大。但这就是我看到的这个有趣的转变：当瓶颈转移时，你如何思考适应瓶颈周围的一切？

One which is the bottlenecks have moved, they've shifted. And so, when bottlenecks shift, what are then some of the team norms that we had to rewrite within the Claude Code team? I also wanted to share a little bit about all these team norms we had to rewrite, how we rolled them out, and also what are some of the proof as some of the you know, like some signals that I get of well, yeah, we're trending in the right direction. And it's always going to be important for me to kind of look at to see is it still serving us, trending in the right direction? And then I'll end it with a few kind of like questions that I still have for myself, and then also some suggestions for you to maybe take an action and embark uh to your teams to have conversations together. So with that, the first section, the bottlenecks have moved. I call it the shift. But you'll probably hear me repeat this kind of subtitle text a lot, which is what served you prior may not serve you any longer. And when actually even when I think about all my experience, whether it was like at Anthropic or Meta or Microsoft, the constant growth mindset is just a muscle that has served me really well. And especially right now when the rate of I don't know if y'all are feeling it, the rate of change is just a little bit crazy, right? Like I remember the first time I started doing some live coding was last year, and it was still making some some, you know, bugs that I'm like, "Ah, why why are you using constants everywhere? That's not good engineering practice." And now it's it's, you know, just become so much more capable. But that's that's what I I'm seeing as this interesting shift of when the bottlenecks moved, how do you think about adapting uh in terms of everything else around that bottleneck?

所以也许你们也有同感，但多年来，工程带宽一直是昂贵的东西。比如编码吞吐量非常昂贵。当你想到我们发布软件的所有流程时，很多流程都围绕着——嗨，欢迎。这里有把椅子。把那些预留标签拿掉。没人坐。

So maybe y'all are feeling this too, but like for years engineering bandwidth was the expensive thing. Like coding throughput was really expensive. And when you think about all the processes we have of shipping software, a lot of it was around Hi, welcome. There's a chair. Take away those reserved tags. There's no one sitting.

这里还有一把椅子，先生。欢迎。嗯，但是是的，所有这些，即使你回想我们过去如何做规划，比如记得我们过去用瀑布式，然后是敏捷，所有这些都是因为工程带宽非常昂贵。实际上，我在这里稍微岔开一下。这不是我们第一次——当你想到我们的行业，我们总是不得不适应。比如我要把你们放进时间机器。和我一起回到 2000 年代。那是我职业生涯的开始。我在 Visual Studio 工作，我们当时在发布 Visual Studio 2005。我跟你们说真的，在那些日子里，如果大家还记得，我们是用 CD-ROM 发布软件的。在 CD-ROM 之前，实际上是软盘。所以我仍然记得 VS 2005，当时有非常严格的截止日期。我们必须赶上那些截止日期，因为我们必须把软件送到制造实验室，印在 CD 上，装进盒子里，运到商店。所以，当你想到这些，当我们能够在线分发软件时，那也改变了我们发布软件的方式。所以，这就是我觉得非常有趣的地方，我看到的这个新的转变是工程带宽，它不再是昂贵的东西了。

And there's another one right here, sir. Welcome. Um but yeah, like all of that, like even when you think about how we used to do planning, like remember we used to do like waterfall and then agile, everything was used to be because engineering bandwidth was really expensive. Actually, I'll take a little segue here. This is not the first time our Like when you think about our industry, we've always had to adapt. Like I'm going to put you all in a time machine. Come back with me all the way to the year 2000s. That was when I started my career. I worked on Visual Studio, and we were shipping Visual Studio 2005. And I kid you not, in those days, if folks remember, we used to ship software on like CD-ROMs. Before CD-ROMs, it was actually floppy disk. And so, I still remember VS 2005, there were really hard deadlines. We had to hit those deadlines cuz we had to get the software to the manufacturing lab to print on the CDs, to put in the boxes, to ship in the stores. And so, when you when you even think about that, when we were able to distribute software online, that also changed how we ship software. And so, that's what I'm finding really interesting of this this new, you know, shift that I'm seeing is engineering bandwidth. It's no longer the expensive thing.

所以，例如，在 Claude Code 团队，编码肯定不再是慢的部分了。嗯，我想说，不仅仅是它不再是慢的部分，而且吞吐量也真的、真的增加了。所以，不仅仅是“耶，我们都能构建更多东西了”，我们生成的代码量也发生了很大变化。所以，我们看到的是，当你的瓶颈从编码和实际打字行为转移时，比如你记得，过去写代码很贵，写测试或重构也很贵。我记得所有这些对话：“我们必须安排时间做重构。哦，但我们必须做产品工作，这很贵。你什么时候能找到时间做？”所有这些现在都转移了。那不再是瓶颈了。所以，当这种情况发生时，有时我注意到瓶颈最终会转移到其他领域。那么发生了什么？比如，验证、审查、跨职能合作伙伴、安全。因为编码不再是瓶颈，而且我们做的编码量也大得多，这些是我们看到的一些新瓶颈。所以，我们总是在问：“这段代码正确吗？谁来审查这段代码？”这可能是所有同行领导者问我最多的问题之一。比如：“人类如何跟上你们做代码审查的方式？”有趣的是，还有它如何维护？因为现在对我们所有人来说，生成大量代码也容易得多。所以也要考虑维护成本。

So, for example, on the Claude Code team, for sure, coding is rarely the slow part anymore. Um and I would say it's not even that it's not the slow part, it's just also the throughput has really, really increased. So, it's not only like, "Yay, we're all all getting to build more." It's just the amount that we're generating has also changed a lot. And so, what we saw was, you know, when your your bottleneck shifts from kind of the coding and the actual act of typing, like if you remember, it used to be writing code was expensive or writing tests or refactoring. I remember all of these conversations of, "We have to schedule some time to do refactoring. Oh, but we have to do product work, and this is expensive. When are you going to find that time to do it?" All of that has shifted now. That is no longer the bottleneck. And so, when that happened, sometimes I notice the bottlenecks end up shifting towards other areas. And so, what happened? Like, for example, verification, review, cross-functional partners, security. Because coding is no longer the bottleneck, and also we're doing so much more of it, these are some of the new bottlenecks that we're seeing. So, it's really always us asking, "Is this code correct? Who reviews this code?" That's like probably one of the top questions I get from all fellow end leaders. Like, "How are humans keeping up with how you guys are doing like code reviews. And interestingly, also how is it maintained? Because now it is also a lot easier for us all to generate a lot of code. So also thinking about that maintenance cost, too.

那么，基于此，这些是我注意到的一些悄悄失效的流程。我喜欢“悄悄失效”这个说法，因为我不知道你们是否——很多时候我们引入流程，希望是有原因的，对吧？比如我们在想：“嘿，这里有个缺口，或者我们想改进。”但多年来我发现，流程很少会自我消亡。我们倾向于一层又一层地叠加更多流程。比如我记得在一个团队里，我们有太多的 SLA。

So with that, these were some of the processes that I noticed quietly stops working. And I love that phrase quietly stops working cuz I don't know if you all like a lot of times we all put in processes hopefully for a reason, right? Like we're thinking, "Hey, there was a gap here or we want to improve." But what I've found over the years is rarely do processes kill themselves. We tend to just layer more and more and more processes on. Like I remember that on one team, we had so many SLAs.

比如有 P0 级 bug 的 SLA、高优先级子评审之类的……总之，SLA 太多了。过了一阵子我就想：“天哪，我们得给优先级排个序，让所有工程师都知道哪个 SLA 更重要。”我记得当时甚至在想：“嘿，我们应该开始考虑哪些东西需要稍微整理一下。”但没错，这些流程可能曾经对你有用。你还记得那句话吗——“过去对你有用的，可能不再适用了”。但比如规划规范，我们过去花很多时间做预规划，因为编码时间很贵。代码所有权，过去也经常有“这是谁写的代码？谁拥有它？”这样的问题。现在这个问题有点不一样了。代码评审，我们一会儿会讲到。团队构成也很有意思。不仅是角色在模糊化，对吧？比如工程师也可以……现在 AI 能帮助增强非工程角色。我的非工程伙伴也都在发布代码。所以当角色开始模糊，你不再有那些孤岛时，会发生什么？然后这也涉及到知识共享。知识共享、入职培训等等，都是我们在 Claude Code 注意到的另一个信号，我们过去做事的方式也有一点变化。所以，在第一部分我们谈到了这种转变。那么在 Claude Code 团队内部，有哪些规范是我们必须重写的？我想和你分享其中一些，希望其中一些能引起你的共鸣，或者你觉得有用。

Like there was a P0 bug SLA, a high-priority sub review instead of like... Anyways, there's so many SLAs. After a while I'm like, "Oh no, we need to stack rank priorities so that all the engineers knew which SLA was going to be even more important." And I remember even at that time I thought, "Hey, we should start thinking about what things we should defrag a little bit." But yeah, so these are the processes that might have served you. Do you remember again is that line of what may have served you may not serve you any longer. But like the planning norms. We used to spend a lot more time, you know, pre-planning because coding time was expensive. Code ownership, there used to also be a lot of questions of who wrote this code? Who owns it? That's a little bit of an other question now. Code reviews, what we'll get into a little bit. Team makeup is interesting, too. It's not only like roles are blurring, right? Like so between like engineers can also... So now now have AI to help augment non-engineering roles. My non-engineering partners are also all shipping code. So what happens when roles start blurring and you don't have those, you know, like the silos anymore? And then that also goes to knowledge share. Knowledge sharing and onboarding and everything is another signal that we're noticing at Claude Code how we used to do things change a little bit, too. And so, you know, in the first section we talked about the shift. So, within the Claude Code team, what are some of the norms that we have to rewrite? So, I want to share some of those with you and then, you know, hopefully some of them will resonate with you or you might find helpful.

所以，第一是代码评审。比如人类判断谁真正需要它，我们会逐一过一遍这些，但你知道，入职培训也变了，我们怎么做规划——你听我讲了很多关于规划的事，招聘，尤其是角色模糊化以及团队构成对我们来说的变化。还有组织形态，那是我最喜欢的热门话题之一。我会在向 Anthropic 提出这个建议时和大家分享那个故事。我爱我的招聘伙伴，他们很棒，但我记得，有一个招聘伙伴真的觉得我疯了。所以，我也想和大家分享这个。

And so, number one is code review. Like human judgment of like who actually needs it and we'll kind of go through all of these, but you know, like the onboarding is also changed, how we do planning, you heard about me talk about like planning a lot, hiring, especially with roles blurring and kind of team makeup how that has changed for us, too. And also org shape, that's kind of one of my favorite spicy topics. I'll share that story with y'all when I start proposing that at Anthropic. I love my recruiting partners, they're awesome, but I remembered, you know, one recruiting partner really did think I was crazy. Um so, I want to share that with y'all, too.

那么，规划是怎么变化的？还有技术辩论。规划，我们做得少多了。我还想说，时机也很重要，我称之为 JIT 规划，几乎就像 JIT 编译，因为即使在我刚加入时，我就想：“我们难道不需要一个六个月的路线图吗？”我们确实投入了一些精力，写了路线图，头三个月还挺好，然后新年回来，很多事情已经变了。所以我意识到，六个月的路线图似乎有点太长了。所以，关键是如何确保在正确的时间做适量的事情，因为原型制作和代码生成不再是过去的瓶颈了。

So, how have planning changed? But also technical debates. Planning, we do a lot less of it. Like I would also say and also the timing, I call it like JIT planning, almost like JIT compiling because even when I first joined, I'm like, "Don't we need a six-month roadmap?" And we, you know, we put some effort in, we wrote it, it was pretty good for three months, and then I came back over the new year and so many things had changed already. So, I realized well, six-month roadmap just seems like a little bit too long. So, again, it's how do you make sure you kind of like do just the right amount in the right time because again, prototyping and code generation is just not the bottleneck that it used to be.

技术辩论也很有趣。在技术辩论中，代码说了算。我会和大家分享，当我刚加入 Claude Code 团队时，我想做一次重构。我想借此了解代码库。我和 Boris 进行了一场健康的技术辩论，关于走哪条路，我几乎要动用我的老工具箱了。我几乎要拍他的肩膀说：“我们去那个房间，用白板……”然后我想，等等等等等等。现在，我可以直接生成我们讨论过的所有不同选项。我生成了三个 PR。技术辩论中很酷的一点是，我不仅关心 API 的实现，还关心对 API 所有调用方的影响。所以当我能让 Claude 帮我生成三个不同版本时，我们不仅能辩论实现，还能辩论对同事的影响。所以我认为这是另一个非常关键的转变。所以，当构建变得便宜，争论变得昂贵时，这又如何改变你的团队规范呢？

The technical debate one is a fun one, too. So, in technical debates, code wins. I'll share with y'all when I first joined the Claude Code team, I wanted to do a refactoring. I wanted to like get to learn about the code base. And me and Boris had a healthy technical debate of, you know, which way to go, and I almost leaned into my old toolbox. I almost tapped him on the shoulder to go, "Let's go to that room and have a whiteboard and we can..." and I'm like, wait wait wait wait wait a minute. Nowadays, I can just generate all the different options we've been discussing. I generated three PRs. And the cool part about that for the technical debate is I really cared not only about the implementation of the API, but also the impact to all the callers into the API. And so when I can have Claude help me generate the three different versions, it allowed us to have a debate of not only implementation, but also impact to the colleagues. So I think that's another really interesting kind of pivotal change. Um so yeah, like you know, when building is cheap, arguing expensive, again, how does that shift your team norms a bit?

我想指出的是，这让你更需要确保建立团队文化，来思考如何对齐。例如，完全行不通的是，因为代码生成速度快得多，不应该变成“最后提交的人获胜”，比如“我要熬夜到下午 3 点提交这个 PR，我设置一个例行程序，确保我最后发言”。这绝对不行。这让你更需要确保有良好的团队文化，能够进行开放、诚实的技术辩论，同时也有良好的团队对齐。

I do want to call out this makes it even more important to make sure you set up team culture for how you think about alignment. For example, what totally won't fly is because code is, you know, so much faster for us to generate, it shouldn't be like the last person who check in wins, you know, like I'm going to stay up at 3:00 p.m. to submit this PR. I set up a routine so that I get the last word in. So definitely a no-no. That makes it even more important to make sure you have good team culture that can have open, honest technical debates, but also a good team alignment.

所以我讲了很多我们在规划中减少的内容。在 Claude Code，我们确实减少了每次代码仪式前的设计文档。我想说，某些团队，尤其是某些场景，设计文档仍然非常重要，特别是当我们进行异步讨论时。但在 Claude Code，我们大多数讨论不是用文档，而是用 PR。这有点像我们的一句话：“嘿，我们有个想法，去原型验证。”这是另一件事。我们不太做产品评审，因为环境变化太快。所以让我们做原型，让大量内部用户使用它，我非常喜欢把它发布给你们所有人，然后听取所有优秀的反馈，这样我们才能真正……而且，这改变了我们的规划仪式，设计文档少了很多，讨论主要在 PR 或原型中进行。

So I talked a lot about kind of what we reduce in planning. On Claude Code, we definitely have reduced the design doc before every code ritual. I would say certain teams and for definitely certain scenarios it's still really important to think about design docs, especially as we're doing like kind of like async discussions. But on Claude Code, most of our discussions is like instead of a doc, a PR. That's kind of like one of the word we have of "Hey, we found an idea, go prototype." That's the other thing. We don't really do a lot of product reviews because the landscape is changing fast. So let's prototype, let's actually get a lot of internal ants using it, and I'm really a big fan of shipping it out to all of you, and then hearing all the excellent feedback so that we can really... And again, like that has changed our planning ritual to be a lot less design docs, and mostly discussions are in PRs or prototypes.

所以我们减少了那些，但我们加倍投入了什么？我认为这是一个我们实际上需要做得更多并继续改进的领域，那就是验证。因为，吞吐量不同了。而且有新的故障方式。那么，你如何扩展？我称之为“左移”。在过去，你会发布代码，我希望在你们任何人发现 bug 之前找到它。而比我发现 bug 更好的是我所谓的“左移”，即更多自动化，这样我们能在源头更早地捕获问题。所以，我认为这是我们需要继续加倍投入的事情。

So we reduced that, but what did we double down on? And I think this is an area where we actually need to do more and continue to being better, it's the verification. Cuz again, it's like the throughput is different. Um, and there are new ways to break. So, how can you scale out? And I call it kind of shift left. Like in the old days, you would get code out and I would love to for me to find bugs before any of you find it. And what's better than me finding a bug is actually what I call shift left, like more automation, so we catch it earlier to the source. So, that is something that I think we need to continue to double down on.

另一件有趣的事是，因为角色在模糊化。比如，我的设计师，我希望在提交代码时更有信心，不会破坏某些东西。我记得，我修复了一个简历相关的 bug，第二天我在看 Boris 的帖子时，看到有人@他：“我注意到一个 bug。”我记得当时有种不祥的预感。

And the other thing that's interesting is also because roles are blurring. For example, my designers like I would love to have more confidence that when I checked in this code, I don't break something. Like I remember it, I fixed a bug in resume or something and the next day I was catching up on Boris's, you know, threads and I saw someone tag him up, "I'm noticing a bug." I remembered having that sinking feeling.

我不知道你们有没有问过：“我是不是刚抓到一个 bug？”因为吞吐量的原因，我真的想确保每个人，无论角色如何，对自己提交的变更都有更高的信心。谁做了这个改动？我的建议是，因为我们的所有 PR 都有 Claude 辅助，这问题有点奇怪。比单纯问这个问题更有用的是我所说的“深入挖掘”。在过去，当你问“谁做了这个改动？”时，你真正想回答的问题是什么？你是想找谁导致了这次回归？你绝对不想指责，只是想了解谁是最后一个碰这段代码、可能造成破坏的人。或者你是在找专家来回答客户问题？还是你想获取背景信息？所以，无论那个深入挖掘的问题是什么，也想想有没有办法自动化它。

I don't know if you've ever asked, 'Did I just catch a bug?' Because of the throughput, I really want to make sure everyone, regardless of role, has much higher confidence in the changes they're putting in. Who made this change? My advice here is, since all our PRs are assisted by Claude, it's a bit of an odd question. What's more helpful than just that question is what I call 'double-clicking into it.' In the old days, when you asked, 'Who made this change?' what question are you really trying to answer? Are you looking for who caused this regression? You definitely don't want to blame, but just want to know who was the last person that touched this code that might have caused this break. Or are you looking for an expert to answer a customer question? Or are you looking to gain context? So, whatever that double-click question is, also think about whether there's a way to automate it.

你是如何跟上代码审查的？

How do you keep up with code reviews?

我很高兴你们看了今天早上的主题演讲；Kat 提到了这一点。我们确实大量使用 Claude Code 进行代码审查。现在有趣的是，你在哪些地方非常信任 Claude，但在哪些地方仍然需要人类？当然，正如 Kat 展示的，Claude 在照看 PR 方面也做得很好。所以我们确实让 Claude 处理所有样式、lint 和 PR 反馈请求，甚至在完全提交之前捕获并修复一些 bug。还有添加测试。这就是我们真正依赖 Claude 的地方。但我仍然明确需要人类的领域是专业知识。这完全是“信任但验证”。例如，法律审查，我始终想确保我仍然有法律伙伴参与。这关乎风险承受能力。例如，信任边界和安全敏感代码，我仍然想确保我引入专家。另一个有趣的领域是产品感和品味。我记得我喜欢用 Claude 做的一件有趣的事是为节日或季节装饰 Claude。去年假期，我想更新终端中的 Claude，给他一个节日主题。我让 Claude Code 把 Claude 变成雪人。那时候 Claude 不太擅长 ASCII 艺术。这就是产品感真正发挥作用的地方。我问我的设计伙伴：“嘿，你能帮我审查一下吗？”她给了我很好的反馈。她说：“你把 Claude 变成了像花生先生那样的角色，”因为我试图让他匹配雪景。我说：“好吧，我要做更简单的东西。”所以 Claude 变成了冰蓝色配雪花，但也要记住那种产品感。

I'm really glad if you saw the keynote this morning; Kat talked about it. We definitely leverage Claude Code review heavily. Now what's interesting is where do you trust Claude a lot, but then where do you still want a human? For sure, as Kat showed, Claude also does a great job babysitting PRs. So we definitely have Claude handle all the styling, lint, and PR feedback requests, even catching some bugs and fixing them before it does a full commit. And also adding tests. That's what we've really leaned heavily into Claude for. But where I still definitely want a human is that expertise. It's all about trust but verify. For example, legal review, I always want to make sure I'm getting my legal partner still. It's about risk tolerance. For example, trust boundaries and security-sensitive code, I still want to make sure I'm pulling in the experts. The other area, which is kind of fun, is product sense and taste. I remember one of the fun things I like to use Claude for is decorating Claude for the holidays or seasons. Last holiday, I wanted to update Claude in the terminal to give him a little holiday theme. I asked Claude Code to turn Claude into a snowman. Claude wasn't that good at ASCII art in those days. That's where product sense really comes in. I asked my design partner, 'Hey, can you review this for me?' And she gave me such good feedback. She said, 'You turned Claude into like the Mr. Peanut character,' because I was trying to make him snow match. I was like, 'Okay, I'm going to do something more simple.' So Claude was ice blue with snowflakes, but keep in mind that product sense as well.

我的团队应该由什么样的人组成？

What should my team makeup be?

因为角色正在模糊化，Claude 正在增强。我要和你们分享在 Claude Code 中，我特别看重的两类工程师。一类是有产品感的创意型建设者。通常，你会看到他们是梦想家。他们有很强的好奇心。他们非常热衷于：“哦，这里有个问题。也许我可以推出一个解决这个问题的产品。”但之后会有很多迭代，以确保你提供令人愉悦的体验。另一类是深度系统专家。当我刚加入 Claude Code 团队时，我注意到我们在产品通才和创意人才方面相当不错，但我们缺少具有分布式系统专业知识的人。当你构建像 Claude Code remote 这样的东西，以确保我们能在任何地方运行 Claude 时，你确实仍然需要那种专业知识。所以，我想说，无论你属于或支持哪个软件工程领导团队，都要思考那些你可能想继续加倍投入的难点。但我肯定不太看重的是原始吞吐量，因为得益于模型，我们看到了更高的效率。

Because roles are blurring, Claude is augmenting. I'll share with you on Claude Code, there are two profiles for engineers that I really heavily indexed on. One is creative builders with product sense. Usually, you'll see these are the dreamers. There will be a big sense of curiosity. They're really passionate about, 'Oh, here's a problem. Maybe I could ship a product that solves that problem.' But then there'll be a lot of iteration to make sure you're delivering a delightful experience. The other one is deep systems expertise. When I first joined the Claude Code team, I noticed we were pretty good with product generalists and creative folks, but we were missing folks with distributed systems expertise. When you're building things like Claude Code remote to ensure we can run Claude everywhere, you really still need that expertise. So, I would say, whichever software engineering lead you're part of or supporting, think about those hard parts where you might want to continue to double down. But for sure what I index less on is raw throughput because thanks to the models, we just saw a lot more efficiency.

那跨职能的缺口呢？

What about cross-functional gaps?

跨职能的缺口是另一个有趣的点。例如，我记得我想更新我们处理调查回复的方式，但我没有专门的内容设计师和我合作。我是工程师，我的写作能力相当糟糕。我很难用简短精炼的形式写东西。我不想让调查在终端里让你们负担过重，因为每一行空间都很重要。但这就是 Claude 发挥作用的地方。在过去，我会问：“我能和哪组内容设计师合作？”然后来回修改。但现在 Claude 真的帮助我增强了这个角色，对我来说是一个非常好的内容设计伙伴，确保措辞良好且简洁。另一方面，我看到我们的 PM 也经常写代码，这很有趣。所以，有了 Claude，非传统编码者现在能做更多工程工作，但工程师也能涉足传统上不属于技术方面、而更偏向内容或设计的领域。所以这非常有趣。我发现 Claude 和 AI 确实在各个方面增强了角色。

The cross-functional gaps are another interesting one. For example, I remember that I wanted to do an update to how we do survey responses, but I didn't have a dedicated content designer to work with me. I'm an engineer, my writing skills are quite terrible. I struggle to write things in a short and succinct form. I don't want the surveys to overload you all in the terminal because every line space is really important. But that's where Claude, in the old days I would be, 'Who is a group of content designers I can work with?' And I can have changes back and forth. But now Claude has really helped me to augment that role and was a really good content design partner for me to make sure the verbiage is good and succinct. On the flip side, I see our PMs code a lot, which is really fun to see. So again, with Claude, you have non-traditional coders now being able to do more engineering, but you also have engineers that can now lean in to do things that were traditionally not on the technical side but more where the content or design. So it's very interesting. I found that Claude and AI have really augmented roles all around.

这是个尖锐的问题。你如何看待团队规模？

This was a spicy one. How do you think about team size?

我确实记得当我刚加入 Claude Code 时，每个人都说：“好吧，你要把团队扩大到一定规模。”我能看出招聘人员仍然在用典型的 10 个 IC 配 1 个经理的模式，然后你怎么开始考虑层级嵌套？我确实倾向于保持精简。实际上，也许我要退一步说，无论是在 Anthropic、Meta 还是微软，无论是 Visual Studio、Facebook Marketplace、AR/VR 设备还是 Claude，我发现真正帮助我交付优秀产品的是重度、重度、重度的“吃自己的狗粮”。尤其是对于领导者来说，现在这其实很有趣。我仍然可以参与代码，但有一段时间不是这样。

I definitely remember when I first joined Claude Code, everyone was like, 'Okay, you're going to grow the team by a certain amount.' And I could tell recruiters were still using the typical 10 ICs to one manager and then how do you start thinking about nesting? I really have leaned into keeping it really scrappy. Actually, maybe I would step back to whether it's at Anthropic or Meta or Microsoft, whether it was Visual Studio or Facebook Marketplace or AR/VR devices or Claude, what I have found to really help me ship great product is heavy, heavy, heavy dogfooding. Especially for leaders, nowadays it's actually fun. I can still be in the code, but for a while it wasn't.

当你无法直接接触代码时，我总是会确保自己花时间，日复一日地实际使用我的产品。所以这就是为什么我希望 Claude Code 的每位经理都先以独立贡献者的身份起步，同时也能在团队中赢得一些信誉，真正学会如何成为一名高效的工程师。然后我把组织架构设计得尽可能扁平，因为我希望我们超级敏捷。

And when you can't get your hands on the code, I would always make sure I would make your time so that I'm actually using my product days in and days out. And so that's why I wanted every manager in Claude Code to start out as an IC first. And also like earn some street cred with the team and really learn how to be an effective engineer. And then I really structured the org to be as flat as possible because I want us to be super agile.

我的招聘人员有些担忧，我记得他们说：“你想招经理，但他们得先当独立贡献者。没有经理会感兴趣的。”我说：“嗯，这就是 Claude Code 团队‘吃自己的狗粮’的意义所在。这也是我的期望。如果有人不感兴趣，那我们早点分开反而更好。”

This was just my recruiters had some concerns because I remember they said, "You want to hire managers and they will start as an IC first. No manager would be interested in that." I'm like, "Well, this is what dogfooding on the Claude Code team's about. And this is what I expect. And if someone's not interested, it's better for us to do earlier separation."

但再说一次，如果没有 Claude，我根本没法快速上手或写代码，因为我的时间都花在大量的上下文切换上了。所以在座的各位经理，我真的鼓励你们也积极投入。

But also again, this is like there's no way I would have been able to ramp or be able to do code because my time is, you know, there's just a lot of context switching without Claude. And so for those of you in the room who are managers, I really encourage y'all to kind of like lean in.

说实话，在 Meta 待了很长时间，我每年还是会试着提交一个 PR，但代码和工作流程总在变。比如所有内部工具，等我学会一个命令，它就已经变了。现在，我甚至不记得 git 命令了，我总是让 Claude 帮我处理这些。

I'll be honest, for a long time at Meta, I would still try every year to do one PR a year just to, but the code and the workflows would always change. Like all the internal tools, by the time I learn one command, it would have changed. Nowadays, I don't even remember git commands. I just always ask Claude to help me out with all of that.

那么，分享之后，什么成为你新的真相来源？比如，在我们 Claude Code 团队，代码就是真相来源。所以当我回答客户请求时，我会回到代码。我桌面上有 Claude 和 Claude Code，还有我所有的本地仓库，这样我就能真正回答很多客户问题。

Now with sharing, what becomes your new source of truth? So for example, on our team on Claude Code, the code is the source of truth. That's why I would go back to when I'm answering customer requests. I just have my desktop Claude with desktop Claude Code and then I have all my local repositories so I can actually answer a lot of customer questions.

对我们来说，让代码库成为真相来源，也避免了以前那种为了保持文档与代码同步而出现的滞后。但我想说，这就要看你的团队怎么合理了。

So for us, just having that code base be the source of truth also prevents some of the lag that you might have had before of how to keep up the documentation correct with the code. But I would say this is where it's like do what makes sense for your team.

比如，如果你还有很多很好的规格说明，就把它们检查进仓库，然后让 Claude 参与帮忙，比如“嘿，看看怎么验证我的代码执行，让它符合我在规格里的预期。”

So for example, if you still have a lot of really good specs, check those into the repositories and then have Claude lean in to help, you know, like hey, take a look at how to verify my code execution so it matches what I expect on the spec.

那我们是怎么推广的呢？因为我刚刚经历了一些我们改变的规范。我觉得有趣的是，我们既要强制一些团队规范，比如确保与团队达成一致，又要真正赋能每个小组。我们在 Claude Code 里有各个小组，我希望确保每个小组都能做对他们有意义的事情。

And so how did we roll it out? Because these were like I had just gone through some of the norms that we had changed. And I think it's interesting, there's a blend of what do we kind of like mandate as team norms? Like make sure you're gaining alignment with the team. And then where do I really enable each, you know, like we have pods within Claude Code. Want to make sure I enable each pod to do what makes sense for them as well.

所以在平衡和强制机制方面，就是与团队在必须做的事情上达成一致。这些是我们真正践行的 Claude Code 团队核心原则。

So in terms of the balance, in terms of forcing function, it's align with the teams on the must do. So, these are a few of the core Claude Code team principles that we really live and breathe.

顺便说一句，如果你还记得，我会回到那种成长心态，总是思考某件事是否还在为你服务。我们会不断更新这些原则。所以每隔几个月，我们就会问：“嘿，这还有同样的效果吗？或者还在实现我们当初想要的目的吗？”

And by the way, if you remember again, I'll go back to that growth mindset and always think about something still serving you. We keep these up to date. So, every few months, we'll be like, "Hey, is this still having the same effect or serving the purpose that we wanted when we started it?"

比如，我应该换掉这张幻灯片。并不是每个工程师都用 Claude Code，这很明显。实际上，是每个 Claude Code 团队成员，包括跨职能伙伴。而且，我们其实也经常用 co-work。

So, for example, and I should replace this slide. It's not every engineer uses Claude Code. You know, that's obvious. It's actually every Claude Code team member, including cross-functional partners. And actually, we all use co-work quite a bit, too.

尽可能把所有东西都“Claudify”。这是我们常说的一件事：“你知道什么比我们自己做更好吗？让 Claude 来做。”所以，总是思考：有没有什么方法可以自动化，无论是验证还是更左移，但当你现在做某件事时，总是想想，有没有什么方法能让 Claude 帮你做？

Claudify everything you can. This is one thing where we're like, "You know what's better than one of us doing it? Having Claude." So, always think about: is there some way for you to automate, whether it's verification, more shift left, but always be thinking when you're doing something right now, is there some way that Claude could actually help you do it?

最后一条是我最喜欢的：明确允许淘汰旧流程。因为再说一次，流程会自我消亡。但作为支持团队，重要的是要不断从团队获得快速反馈，了解我们在哪些事情上花了大量时间。

And the last one's my favorite, explicit permission to kill old processes. Because again, processes will kill themselves. But as your supporting teams, it's really important to always get that fast feedback for your team of what are the things that we're spending a lot of time on.

我其实记得我刚加入 Claude Code 时，我们以前会开站会。后来团队变大了一点，于是我们用电子表格，大家把每周的进度放上去。然后我想：“哦，等等，我们应该做一个技能，对吧？比如一个站会脚本。这样我们就可以运行 Claude，我们大家都能更清楚地了解其他人在做什么。”

I actually remember when I first joined Claude Code, we used to do stand-ups. And then the team got a little bit big, so then we had a spreadsheet where we would all put up our weekly process progress. And then I was like, "Oh, wait, we should just do a skill, right? Like a stand-up script. So then we can just run Claude and all of us can always be much more kept aware of what everybody else is doing."

所以这只是另一个例子，有一天我想到电子表格，心想：“这还有意义吗？”所以，总是质疑，总是寻找碎片整理和淘汰旧流程的机会。

So that's just another example of one day I remember the spreadsheet and thought, "Does this still make sense anymore?" So, always question and always look to defrag and kill old processes.

我想确保给各个小组留出很大的适应空间。每个团队确实有很高的自主权，来决定如何处理分诊或利用 Claude 做分诊、任何规划仪式或站会、如何看待值班，以及优先将哪些工作流“Claudify”。

What I want to make sure that I leave a lot of room for pods to adapt. It's each team really has a lot of high agency for how they do triage or leverage Claude to do triage, any planning rituals or stand-ups, how they think about on-calls, and also which workflows to Claudify first.

所以我们通常不会强制规定“你必须自动化这个”。我们有一些建议和经验，但总是给团队留出空间，尤其是他们可能涉及不同的问题领域。

So, we don't usually mandate "thou shalt automate this." We have some suggestions and learnings, but always give room to your team, especially they may be touching on different problem areas.

那么，如果从宏观来看，我加入 Claude Code 时优先做的三件事是什么，我觉得必须产生最大影响？保持团队尽可能扁平。比如经理发布工作小组，但真正保持敏捷。

So, if I zoom out, what were the three things I prioritized on when I joined Claude Code that I felt had to make the biggest difference? Keeping the team as flat as possible. Like managers release pods of work, but really keep it agile.

比如，在 Claude Code 和 co-work 上，我们有一个整体团队使命。因为有时当你开始创建小组时，每个小组可能想设立自己的使命，然后每次需要调整时，可能都要花很多时间向人们解释，但真的尽可能扁平。我觉得这对我们很有帮助。

So, for example, on Claude Code and co-work, we have one overall team mission. Because sometimes when you start creating pods, each pod then wants maybe to set up their own mission, and then anytime you have to shift, it might take a lot of time to walk people through that, but it's really as flat as you can. I felt that served us really well.

第二是“Claudify 一切”，比你自己做更好。我看到 Claude 能如何帮助你。它真的让我们解放出来，去做更多更困难的工作。

The second is Claudify everything, better than you doing it. I see how Claude can help you. It really frees us up to do more of the harder work.

再说一次，流程确实会堆积。所以我鼓励你和团队一起看看，哪些流程你实际上应该能够放手。

And again, the processes, they do pile on. So, I encourage you to kind of like work with your team to see what are the processes that you actually should be able to let go.

那么，这真的有效吗？我不能给出具体数字，但我认为这些是你在团队中推广变革时可以关注的三个通用指标，它们可能会让你觉得“嗯，这似乎开始成功了”。

So, does it actually work? I can't go into the explicit numbers, but I think these are three general kind of metrics that you can look at as you're rolling out changes on your team that might start steering you to yeah, this seems like it's kind of starting to be successful.

入职上手时间大幅缩短。这很有意思，比如工程师、设计师或产品经理能多快开始在团队中发挥作用。

The onboarding ramp-up time has dramatically reduced. So that's an interesting thing, like how soon an engineer or a designer or a PM can start being effective on your team.

PR 周期时间缩短。我觉得这一点值得深入探讨，因为它可能帮助你发现一个差距，不仅仅是 AI 采用不足，而是流程的其他部分可能在扩展方面遇到困难。

The PR cycle time shortening. I think this one's interesting to double click into a bit because it might actually help you identify a gap that's not just in terms of lack of AI adoption, but where the rest of the pipeline might be struggling to scale.

举个例子，随着我们现在提交的代码量大幅增加，有时产品基础设施的构建和 CI 仍然能跟上工程师提交的量。所以，这两项指标应该下降，而云辅助提交应该略有上升。比如对我们来说，默认每次提交都是云辅助的。我想在过去大约 4 个月里，我都没见过非云辅助的提交。但希望这三个指标能让你观察团队并看到它们的共鸣。

So, for example, as we're now putting in so much more code, sometimes a product infrastructure can build and CI still keep up with the amount that engineers are checking in. So, both of those should go down, but then what should go up a little bit is cloud-assisted commit. For example, for us, by default every commit is cloud-assisted. I don't think I've seen a non-cloud-assisted commit in the last 4 months or so. But hopefully these three things are metrics that you can look at your team and see how they resonate.

我还要说，除了提交数量，还要考虑最终目标。如果你退一步看，你想让用户更喜爱的产品是什么？或者你想解决的问题是什么？因为有时你会看到头条说这家公司有 X% 的代码由 AI 生成。我认为吞吐量很棒，但真正要考虑的是如何衡量你实际想解决的问题。比如，我们非常想确保关注质量和可靠性，所以这些也是我们更关注的事情。

I would also say, outside of just number of commits, also think about the end goal. If you zoom out, what is the product you're trying to make more delightful for users? Or what is the problem you're trying to solve? Because sometimes you see headlines saying this company has X percent of code generated by AI. I think throughput is great, but really think about how you measure what you're actually trying to solve. For example, we really want to make sure we're keeping an eye on quality and reliability, so those are some of the things we're paying more attention to as well.

好的，我的最后一部分是审视自己的努力。我会坦诚地告诉你，我仍然有几个问题在问自己。iOS 和 Android 组织非常有趣。当工程师现在能更高效地在不同移动平台间灵活切换时，传统的 iOS 团队和 Android 团队分工方式还有意义吗？这是我仍在思考的问题。

Okay, so my last section is to audit your own effort. I'll share with you transparently, I still have a couple of questions that I'm asking myself. The iOS and Android org is a very interesting one. When engineers can now more efficiently flex across different mobile platforms, does a more traditional way of having an iOS team and an Android team still make sense? That's something I'm still thinking through.

你在多大程度上推动完全自动化的审查？再次，你如何在足够快和失去重要东西之间取得平衡？这又回到了信任但验证。有趣的是，你可能在早些时候 Danella 的演讲中听到，模型能力确实在不断提升。所以即使你在某些工作上可能需要更多验证而非信任，那也可能随着下一个模型而改变。所以重新评估总是重要的。

How much do you push that fully automated review? Again, when do you strike that balance between fast enough and we lost something important? It goes back to the trust but verify. And what's interesting is you might have heard earlier during Danella's talk that model capabilities do keep improving. So even if you might need to do more verify than trust for a certain section of work, that might also change with the next model. So it's always important to re-evaluate.

而且角色正在模糊化，所以你如何确保每个人都感到同样高效？如果我要留给你一个带回去的东西，那就是选择你噪音最大的工作流。所谓噪音最大的工作流，可能是最昂贵的，也可能是你自己害怕的，甚至你的团队不太期待的。然后问，它是否真的还在服务于它的目的？

And roles are blurring, so how do you make sure that everybody feels equally productive? So if I were to leave you with one thing to take back, it's to pick your noisiest workflow. By noisiest workflow, it could be most expensive, what's something that you yourself might be dreading, or even your team might not look forward to it. And ask, is it still really serving its purpose?

实际上，我再分享一个有趣的故事。我曾在一个团队，我们过去有每周评审。那是一个非常昂贵的评审，比如 50 个人在一个大房间里。然后我注意到每个人都在用笔记本电脑，除了轮到他们做状态报告时，他们抬起头，说状态，然后又低下头。我就想，这是一个非常昂贵的会议。我只是问了一个简单的问题：我们为什么要开这个会？就这一个问题，每个人都觉得，是啊，确实如此。于是我们取消了它。所以这就是为什么思考总是重要的。

Actually, I'll share another funny story. There was a team I was on where we used to have this weekly review. It's a very expensive review, like 50 people in this large room. And then I noticed everybody's on their laptops, except for when it's their time to give status report, and then they pop their head up, say the status, and then go back down. And I'm like, this is a very expensive meeting. And I just asked that simple question of why are we having it? And just that one question, everybody's like, yeah, it's true. And so we canceled it. So that's why it's always important to think.

所以，是的，我想这可能是一件有趣的事情，让你带回去看看，考虑一下哪部分工作流，你可以自动化，或者它是否仍然在证明其预期目的。那么，这就是我们演讲的结尾。谢谢。

So, yeah, I figured this might be something fun for you to take back and look and see what's one piece of workflow that you might consider, can you either automate, or maybe even is it still proving to serve its intended purpose. So with that, that's the end of our talk. Thank you.

谢谢。非常感谢大家的出席。我真的以为这个房间会是空的。所以感谢你们没有让我独自一人。我今天和明天都会在这里。所以如果你们有任何问题或想多聊聊，请随时自我介绍。我很乐意聊天。谢谢。

Thank you. Thanks a lot for attending. I really, for sure, thought this room was going to be empty. So thanks for not leaving me by myself. And I'm around here today and tomorrow. So if you have any questions or want to chat more, feel free to introduce yourself. I'm happy to chat. Thank you.