**Fiona Fung：** 大家好，都能听到我说话吗？好的，我发誓这不是什么 Claude Code 的事儿，但你们介不介意我拍张照片？因为 Boris 和 Jared 的那场在两点，我本来真觉得这里会空空如也。我当时想，从那场结束之后不可能还有人跑过来的。所以，天哪。
**Fiona Fung:** Hey folks, do y'all hear me okay? Okay, I I I swear this is not a Claude Code thing, but do you guys mind if I take a photo? Cuz cuz 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.
**Audience：** [screaming]
**Audience:** [screaming]
**Fiona Fung：** 谢谢大家的热情。我保证我和 Boris 不是整天只知道拍合影。
**Fiona Fung:** Thank you, prompt. I promise me and Boris don't just do selfie words all the time.
**Audience：** [laughter]
**Audience:** [laughter]
**Fiona Fung：** 下午好，感谢大家来参加。我叫 Fiona Fung，我负责 Claude Code 和 Co-work 的工程和产品。我和 Boris、Cat 合作非常紧密。在加入 Anthropic 之前，我在 Meta 和 Microsoft 都带过团队、做过扩张。今天这个演讲的主题就是我在帮助 Claude Code 和 Co-work 成长、组建团队过程中学到的一些经验。有意思的是，这些经验哪怕回想我在 Meta 或者 Microsoft 的日子也同样适用。说个好笑的事，这份幻灯片我大概一个月前做的，结果已经有些内容得改了——因为我开始做这份演示的时候，routines 这个功能还不存在，那时候的工作方式对我来说都不一样。
**Fiona Fung:** 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 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 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.
所以我今天想讲五个我观察到的主题。第一个是瓶颈已经转移了。当瓶颈转移之后，我们 Claude Code 团队不得不重写了哪些团队规范？我还想分享一下这些新规范是怎么推行的，以及我看到的一些信号——说明我们正朝着正确的方向前进。对我来说，持续观察这些规范是否仍然在服务于我们非常重要。最后我会分享一些我自己还没有答案的问题，以及一些建议——你们可以带回去跟自己的团队一起讨论。
And so, yeah, like we really want to — like I want to kind of cover five themes that I've noticed. 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 — 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.
那我们先说第一部分——瓶颈已经转移了。我管它叫"The Shift"。你们可能会反复听我说这句话：过去有效的做法，现在可能不再有效。回想我所有的经历——在 Anthropic、Meta 还是 Microsoft——growth mindset 这种持续成长的心态一直是一块让我受益匪浅的肌肉。特别是现在变化的速度——不知道你们有没有感受到——变化速度简直有点疯狂。我记得我去年刚开始做 live coding 的时候，模型还在犯一些让我无语的 bug，我会想"你为什么到处用常量？这不是好的工程实践。"但现在它的能力已经强了太多。这就是我看到的这个有趣的转变：当瓶颈转移之后，你怎么去调整瓶颈周围的一切？
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, 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, you know, just become so much more capable. But that's what 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.
**Audience：** [laughter]
**Audience:** [laughter]
**Fiona Fung：** 先生，这边还有一个座位。欢迎。不过说回来——你想想我们以前怎么做规划的，从瀑布模型到敏捷，所有东西都是因为工程带宽非常昂贵才那样设计的。我这里岔开说一下。
**Fiona Fung:** 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.
这不是我们行业第一次需要适应变化。我带大家坐时光机回到 2000 年代。那是我职业生涯的起点。我当时在做 Visual Studio，我们在发布 Visual Studio 2005。
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.
我不开玩笑，那个年代如果大家还记得的话，我们是把软件刻在 CD-ROM 上发行的。CD-ROM 之前其实是软盘。我清楚地记得 VS 2005 有非常硬的截止日期。我们必须赶上那些日期，因为软件要送到工厂去印 CD、装盒、上架到商店里。所以你想想看，当我们能够在线分发软件之后，整个发布流程也随之改变了。这就是我现在看到的这个新转变中特别有意思的地方：工程带宽不再是最贵的东西了。
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 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 new, you know, shift that I'm seeing: engineering bandwidth is 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 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 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 eng 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 了——P0 bug SLA、高优先级 sub review SLA——总之各种 SLA。过了一段时间我想，"糟了，我们需要给这些 SLA 排个优先级，好让工程师知道哪个 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. Like there was a P0 bug SLA, a high pri — like sub review — 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 um yeah, so these are the processes that might have served you. Do you remember again 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. Uh code ownership, there used to also be a lot of questions of who who who wrote this code? Who owns it? That's a little bit of another question now. Uh code reviews, which we'll get into a little bit.
团队构成也很有意思。不仅仅是角色在模糊化。工程师现在有 AI 来辅助增强非工程类的工作。我的非工程合作伙伴们也都在提交代码。那当角色开始模糊、过去的职能壁垒不复存在的时候，会发生什么？知识共享也是如此。知识共享和入职培训是我们在 Claude Code 注意到的另一个正在发生变化的领域。
Team makeup is interesting, too. It's not only like roles are blurring, right? Like so between — like engineers can also — 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.
在第一部分我们讲了这个转变。那在 Claude Code 团队内部，我们不得不重写了哪些规范呢？我想和大家分享一些，希望其中一些能引起你们的共鸣或者对你们有帮助。
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. Uh 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 的实现方式，还关心它对所有调用方的影响。
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 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.
当我用 Claude 生成三个不同版本的时候，我们可以不仅讨论实现，还能讨论对同事的影响。这是一个非常有意思的关键转变。当构建成本变低、争论反而变得昂贵的时候，你的团队规范怎么调整？我要特别指出的是，这让团队文化和对齐机制变得更加重要。一个绝对不能容忍的反模式就是——因为代码生成变快了，就变成"谁最后提交谁赢"——"我熬到凌晨三点提交这个 PR""我设个 routine 让我拿到最后的话语权"。这绝对不行。这反而让好的团队文化更重要了——能坦诚地进行技术辩论，同时又有好的团队对齐。
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? 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 checks in wins, you know, like I'm going to stay up at 3:00 a.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 good team alignment.
在规划方面我们减少了什么呢？在 Claude Code，我们大幅减少了"每次写代码前先写设计文档"这个仪式。对某些团队和场景来说设计文档当然还是重要的，特别是异步讨论的时候。但在 Claude Code，大部分讨论是用 PR 而不是 doc 进行的。我们的口头禅是"发现一个想法，就去做原型"。我们也不做太多产品评审，因为技术格局变化太快。所以我们做原型、让大量内部用户试用，我特别喜欢的是发布给你们所有人，然后听到那些很棒的反馈，这样我们才能真正迭代。这些改变让我们的规划节奏变成了——更少的设计文档，大部分讨论发生在 PR 或原型中。
Uh 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 words 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 folks 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.
我们减少了那些，但我们加倍投入了什么？我认为这是我们需要做更多、持续做得更好的领域——验证。因为产出量不同了，也有新的出错方式。怎么规模化？我管它叫 shift left。过去你把代码发出去，我希望能在你们任何人发现 bug 之前先找到。而比我找到 bug 更好的是 shift left——更多自动化，在源头就捕获问题。这是我们需要继续加倍投入的方向。
Um 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 be 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 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.
另一个有意思的点也是因为角色在模糊化。我的设计师同事们——我真的希望每个人在提交代码的时候都能有更高的信心，确信自己不会搞坏什么。我记得有一次我修了一个 resume 相关的 bug，第二天我在看 Boris 的消息时发现有人 tag 他说"我发现了一个 bug。"那种心往下沉的感觉，不知道你们有没有经历过——是不是我刚才引入了一个 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. I don't know if y'all have ever — like did I just cause a bug? Like so because of the throughput, like I just really want to make sure everybody, regardless of roles, just has a lot higher confidence um for the change that they're putting in.
"谁做了这个改动？"——我的建议是，因为我们所有的 PR 都是 Claude 辅助的，这个问题本身变得有点奇怪了。对我们来说，比这个问题更有用的是我说的"double click"——深挖一层。过去当你问"谁做了这个改动"的时候，你真正想回答的是什么问题？你是在找谁导致了这个回归？我们当然不想怪罪谁，只是想知道最后碰这段代码的人是谁。还是在找一个专家来回答客户问题？还是想获取上下文？不管你的真正问题是什么，想想是不是有办法自动化它。
Who made this change? And so my advice here is again, because all our PRs are assisted by Claude, it's a little bit of an odd question. And so for us, what is more helpful than just that question is what I call like double clicking into it. Like so in the old days, when you used to ask, "Who made this change?" — what question are you really trying to answer? Are you looking for who caused this regression? 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 is that double click question, also think about is there a way you can automate.
说个好玩的，我提到过我得更新这份幻灯片。大约一个月前我开始准备这个演讲的时候，我每天早上的习惯是打开桌面版 Claude Code，去客户反馈频道，让它帮我做个总结——这是我配着早上那杯咖啡的日常。现在变成了 routines，对吧？我可以直接设置好，而且比之前我自己手动启动的方式还要好。每天早上端着咖啡，我总能拿到一份不错的概览。我的意思是，代码所有权确实变模糊了，但反过来说，深挖你真正想回答的问题是什么，看看 Claude 能不能帮你解决。
It's funny, I mentioned that to change this slide deck. When I started this talk about a month ago, part of my every morning is I would, you know, bring up my desktop Claude Code and go into here's a customer feedback channel and I kind of want to ask it to summarize — and that was just a morning ritual I would do with my morning cup of coffee. Now it's routines, right? Like I can set that up and then even better than what I had done before, which was how I kick it off. I'll be like, with my morning cup of coffee, I always get to kind of a pretty good overview. So that's my point of like code ownership is a little bit more fuzzy, but on the flip side, double click to what question you're really trying to answer and seeing how Claude can actually help you with those.
代码审查怎么跟上？如果你们看了今天早上的 keynote，Kat 讲到了这个。我们确实重度依赖 Claude 做代码审查。有意思的问题是：哪些地方你非常信任 Claude，但哪些地方你仍然需要一个人？
How do you keep up with code reviews? So I'm really glad — if y'all saw the keynote this morning, Kat talked about it. We definitely leverage heavily Claude code review. Now what's interesting is going to be where do you trust Claude like a lot, but then where do you still want a human?
Claude 确实——就像 Kat 展示给大家看的——Claude 在 babysitting PR 方面做得很好。我们让 Claude 处理所有风格和 lint 问题、PR 反馈请求，甚至在做完整提交之前就捕获一些 bug 并修复。还有添加测试。这些是我们重度依赖 Claude 的地方。但我仍然需要人来做的是那些需要专业判断的领域。核心原则是 trust but verify。比如法务审查——我始终需要确保我的法务合作伙伴参与。风险容忍度也是——信任边界和安全敏感代码，我仍然需要把专家拉进来。
And so for sure like, you know — and actually Claude also, as Kat showed y'all — Claude also does a great job babysitting PRs. And so we definitely have Claude handle all the styling and lint and PR feedback requests, even like maybe catching some bugs and fixing them before it even does a full commit. And also adding tests. That's what like really what we've leaned heavily into Claude for. But where I still definitely want a human is that expertise. It's all about trust but verify. So for example, legal review — I always definitely want to make sure I'm getting my legal partner still. Uh it's, you know, like risk tolerance. So for example, trust boundaries and security sensitive code, I still want to make sure I'm pulling in the experts.
另一个有意思的领域是产品品味。我有个爱好是给 Claude 做节日或季节性装饰。我记得去年假期，我想给终端里的 Claude 做个节日主题。我让 Claude Code 把 Claude 变成一个雪人。那时候 Claude 的 ASCII 艺术水平不太行。这正是产品品味发挥作用的地方——我请我的设计师伙伴帮我审查。她给了我特别好的反馈，她说"你把 Claude 变成了 Mr. Peanut 那个角色。"因为我试图让他看起来像雪人。我想好吧，那做简单点——最后 Claude 变成了冰蓝色配雪花。但要记住产品品味的重要性。
Um the other area which is kind of fun is also that product sense and taste. Like I remember one of the hobby — one of the fun things I like to use Claude for is that I like to decorate Claude for the holidays or the seasons. And I remember last holiday, I wanted to update Claude in the terminal to, you know, give him a little holiday theme. And I asked Claude Code to turn Claude into a snowman. Claude wasn't that good at ASCII art in those days. And I remembered asking — 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's like, "You turned Claude into like the Mr. Peanut character." Cuz I was trying to make him snowman-ish. I was like, "Okay, I'm going to do something more simple." So, Claude was like ice blue with snowflake, but keep in mind kind of that product sense as well.
这就引出了团队构成应该是什么样的。因为角色在模糊化，Claude 在增强每个人的能力。在 Claude Code，我特别看重两类工程师。第一类是有产品直觉的创意型 builder。这些人通常是梦想家，充满好奇心，对"这里有个问题，也许我可以做一个产品来解决它"充满热情。然后会有大量迭代来确保交付令人愉悦的体验。
Which leads me to what should my team makeup be? Because roles are blurring, Claude is augmenting. I'll share with you on Claude Code, there's two profiles for engineers that I'd really heavily indexed on. One are like creative builders with product sense. Usually, you'll see these are, you know, the dreamers. There will be a big sense of curiosity. They're really passionate about, "Oh, here's a problem. Here's a — maybe I could, you know, 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.
另一类是深度系统专家。我刚加入 Claude Code 团队的时候发现，我们在产品通才和创意型人才方面其实不错，但缺少有分布式系统专业知识的人。当你在做 Claude Code Remote、需要确保 Claude 能在任何地方运行的时候，你确实还是需要那些专业能力。所以无论你带的是什么样的软件工程团队，想想那些真正困难的部分，你可能需要继续加倍投入。但我明确降低权重的维度是 raw throughput——因为有了模型的帮助，我们的效率已经提升了很多。
Um the other one is deep systems expertise. So, when I first joined Claude Code team, I noticed actually we were pretty good with product generalists and creative folks, but we were missing folks with like distributed systems expertise. And when you're building things like Claude Code Remote to ensure we can run Claude everywhere, you really still need um those expertise. So, I would say, you know, whichever software engineering lead you're part of or supporting, think about those hard parts of where you might want to continue to still double down. But for sure what I index less on is raw throughput because thanks to the models, we just saw a lot more uh efficiency.
跨职能缺口是另一个有意思的点。我记得有一次我想更新我们做用户调查的文案，但没有专门的 content designer 跟我配合。我是工程师，写作能力说实话很差。我很难把东西写得简短精炼。我不想在终端里用调查问卷占太多行——每一行空间都很珍贵。在以前我会去找"有没有一组 content designer 可以跟我合作？"然后来回改。但现在 Claude 充当了那个角色，成了我非常好的 content design 合作伙伴，帮我确保用词精准简洁。
The cross-functional gaps is another interesting one. So, 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. And I'm an engineer, my writing skills are quite terrible. I I struggle to write things in a short and succinct form. I don't want the surveys to like, you know, overload you all in the terminal cuz every line space is really important. But that's where Claude — like in the old days I would be, "Who is a group of content designers I can work with?" And I can kind of do 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 kind of like make sure the verbiage is good and succinct.
反过来说，我们的 PM 写了大量代码，这看着很有意思。Claude 让非传统的编码者能做更多工程工作，同时也让工程师能涉足传统上属于内容或设计领域的事情。这非常有趣。我发现 Claude 和 AI 真的在各个方向上增强了角色的能力。
And on the flip side, like I say, our PMs code a lot, which is really fun to see. So again, like I would say with Claude, you have non-traditional coders now being able to do more engineering, but you also have engineers that we can also now lean in to do things that were traditionally, you know, not on the technical side but more of where the content or design side is. So it's very interesting. I found that Claude and AI has really augmented roles kind of like all around.
这是个辛辣话题。我记得我刚加入 Claude Code 的时候，大家说"好，你要把团队扩大到某个规模。"我能看出招聘团队还在用传统的 10 个 IC 配 1 个管理者的比例来思考分层。我真的坚持保持精简。其实不管是在 Anthropic、Meta 还是 Microsoft——无论是 Visual Studio、Facebook Marketplace、AR/VR 设备还是 Claude——我发现真正帮助我交付好产品的是重度、重度、重度的 dogfooding。
This was a spicy one. Uh so I'm definitely — like I remember when I first joined Claude Code, everyone's like, "Okay, you're going to grow the team by certain amount." and I could tell recruiters were still using the typical, you know, 10 ICs to one manager and then how do you start to think about nesting? Um I really have leaned into keeping it really scrappy. And actually maybe I would step back to whether it's at Anthropic or Meta or Microsoft, whether it was like Visual Studio or Facebook Marketplace or AR/VR devices or Claude, like what I have found to really help me ship great product is heavy heavy heavy dogfooding.
特别是对于领导者来说，现在其实是件开心的事——我又能在代码里了。但有一段时间是做不到的。当你没法亲手碰代码的时候，我总会确保自己日复一日地使用自己的产品。所以我要求 Claude Code 的每位管理者入职后先做 IC，在团队里建立信任、学习如何成为一名有效的工程师。
Especially for leaders where nowadays it's actually fun. I can still be in the code, but for a while it wasn't. And when you can't get your hands on the code, I would always make sure I would make time so that I'm actually using my product days in 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.
然后我把组织架构压得尽可能扁平，因为我希望我们保持极度敏捷。我的招聘合作伙伴有些担忧，我记得他们说"你想让新招的管理者先做 IC？没有管理者会对这种安排感兴趣的。"我说"这就是在 Claude Code 团队做 dogfooding 的含义，这是我的期望。如果有人不接受，那早点分道扬镳对双方都更好。"而且说实话，如果没有 Claude 的帮助——我的时间充满了 context switching——我根本不可能上手或者写代码。所以在座如果有管理者的话，我真的鼓励你们去尝试。
Uh and then I really structured the org to be as flat as possible cuz I want us to be super agile. This was — my recruiters had some concerns cuz 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 uh earlier separation." But also again, this is like — there's no way I would have been able to ramp or be able to do code cuz 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, you know, like encourage y'all to kind of like lean in.
说实话，在 Meta 的很长一段时间里，我每年还会努力做一个 PR——但工作流程总在变。那些内部工具，我刚学会一个命令它就变了。现在呢，我连 git 命令都不记了，我就直接让 Claude 帮我搞定。
It'll — 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 workflows would always change. Like all the internal tools, like 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.
那在知识共享方面，什么成为你新的 source of truth？在我们 Claude Code 团队，代码就是 source of truth。这也是为什么当我回答客户问题的时候，我就打开桌面版 Claude Code，加上本地代码仓库，就能回答很多客户问题。代码库作为 source of truth 也避免了过去那种文档和代码不同步的滞后问题。
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 like answering customer requests. I just have my desktop Claude with desktop Claude Code and then I have all my, you know, like local repository so I can actually answer a lot of customer questions. So for us, just having that code base be the source of truth also like prevents some of the lag that you might have had before of how to keep up the documentation, you know, correct with the code.
但我也要说，做对你团队有意义的事。比如如果你们有很好的 spec 文档，把它们 check in 到代码仓库里，然后让 Claude 来帮忙验证——看看代码执行是否符合 spec 的预期。
But I would say this is where it's like do what makes sense for your team. 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, you know, take a look at how to verify my code execution so it matches what I expect on the spec.
那这些新规范是怎么推行的？我刚刚讲了一些我们改变了的规范。我觉得有意思的是，这里面有一个平衡——哪些是我们作为团队规范强制要求的？要确保跟团队达成共识。同时我又要给每个 Pod 留出空间做对他们有意义的事。
And so how did we roll it out? Cuz 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. I want to make sure I enable each pod to do what makes sense for them as well.
在平衡方面，在强制推动方面，核心是跟团队对齐那些"必须做"的事。这里是 Claude Code 团队几条我们真正践行的核心原则。顺便说一句——回到那个 growth mindset——我们会持续更新这些原则。每隔几个月我们会问"这条原则还在发挥它当初设立时的作用吗？"
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, you know, the same effect or serving the purpose that we wanted when we started it?"
比如这一条，我应该更新这张幻灯片了——不是"每个工程师使用 Claude Code"，这太显然了。应该是每个 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 everything you can"——能用 Claude 做的就用 Claude。我们的态度是"什么比我们自己做更好？让 Claude 来做。"不管是验证、shift left 还是其他自动化，当你在做一件事的时候，永远想一下 Claude 能不能帮你做。
Uh "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?
最后一条是我最喜欢的——明确授权淘汰旧流程。因为流程不会自我终结。但作为团队的支持者，你需要持续从团队获取快速反馈。我记得我刚加入 Claude Code 的时候，我们做站会。后来团队变大了，改成每周往电子表格里填进度。然后我想"等等，我们应该做个 skill 对吧？做个站会脚本。这样大家跑一下 Claude 就能随时了解其他人在做什么。"这就是另一个例子——有一天我看着那个电子表格想"这还合理吗？"所以，永远保持质疑，永远寻找机会去整理碎片、淘汰旧流程。
And the last one's my favorite, explicit permission to kill old processes. Cuz again, processes will not kill themselves. But as you're supporting teams, it's really important to always get that fast feedback from your team of what are the things that — you know, like are we spending — I'm actually, I 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, you know, like weekly 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 spreadsheet — wait, "Does this still make sense anymore?" So, always question and always look to defrag and kill old processes.
我想确保的是给每个 Pod 留出足够的空间去适应。每个团队在怎么做分诊、怎么用 Claude 做分诊、规划节奏和站会、on-call 安排、以及先 Claudify 哪些工作流方面都有很高的自主权。我们通常不会下令"你必须自动化这个"。我们有一些建议和经验，但总要给团队留出空间，特别是他们可能在处理不同的问题领域。
What I want to make sure is that I leave a lot of room for pods to adapt. Each team really has a lot of high agency for how, you know, 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, you know, touching on different problem areas.
拉远来看，我加入 Claude Code 后觉得产生了最大影响的三件事是什么？保持团队尽可能扁平。管理者带领各个 Pod，但核心是保持敏捷。比如 Claude Code 和 Co-work 共享一个整体团队使命。因为一旦你开始创建 Pod，每个 Pod 可能都想设立自己的使命，然后每次要调整方向都要花大量时间去沟通。尽可能扁平——这确实对我们很有效。
So, if I zoom out, what were the three things I prioritize on — you know, when I joined Claude Code that I felt has made the biggest difference? Keeping the team as flat as possible. Um like managers release a pop — pods of work, but really keep it agile. So, for example, on Claude Code and co-work, we have one overall team mission. Cuz 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 everything——Claude 做比你做更好"——看看 Claude 怎么帮到你。这真的让我们释放出来去做更难的工作。还有那些流程，它们确实会堆积起来。我鼓励你们跟团队一起看看，哪些流程其实可以放手了。
The "Claudify everything — better than you doing it" — 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 actually you should be able to let go.
那这些做法到底有没有用？我不能分享具体数字，但我觉得有三个通用指标，你在自己团队推行变革的时候可以用来看是不是朝着正确方向走。入职上手时间——这大幅缩短了。一个工程师、设计师或 PM 多快能开始有效地为团队做贡献？这是个很有意思的指标。
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, you know, changes on your team that might start steering you to yeah, this seems like it's kind of uh starting to be successful. The onboarding ramp-up time that has dramatically reduced. Uh so, that's an interesting thing — like how soon an engineer or a designer or, you know, like a PM can start being effective on your team.
PR 周期时间缩短。这个指标值得深挖一下，因为它不仅能衡量 AI 采用度，还能暴露管道中其他环节的瓶颈。比如当我们提交了这么多代码之后，产品基础设施的构建和 CI 有时候跟不上工程师提交代码的速度。
Uh the PR cycle time shortening. I think this one's interesting to double click into a bit cuz 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. So, for example, again, as we're now, you know, just putting in so much more code, sometimes a product infrastructure build and CI still can't keep up with the amount uh that engineers are checking in.
这两个指标应该下降，但有一个应该上升——Claude 辅助提交的占比。对我们来说，默认状态就是每次提交都是 Claude 辅助的。我大概有 4 个月没见过非 Claude 辅助的提交了。希望这三个指标对你们的团队也有参考价值。
Uh so, both of those should go down, but then what should go up a little bit is Claude-assisted commit. For example, for us, it's by default every commit is Claude-assisted. I don't think I've seen a non-Claude-assisted commit probably in the last 4 months or so. Um, but hopefully these three things are kind of like metrics that you can take a look at at your team and see how it resonates.
我还想说的是，不要只看提交数量，也要想想最终目标。拉远来看，你想让什么产品对用户更好？你想解决什么问题？有时候你看到头条说"这家公司 X% 的代码现在由 AI 生成。"产出量固然好，但要认真想想你到底在衡量什么、你真正要解决的是什么。比如我们特别关注质量和可靠性，这些是我们也在密切关注的维度。
I would also say though, um, outside of just number of commits, also think about the end goal. Like if you zoom out, what is the product that you're trying to make more delightful for users? Or what is the problem you're trying to solve? Cuz sometimes you see it on all the headlines of "this company said X percent of code is now generated by AI." I think throughput is great, but really think about how you measure what it is that you're actually really trying to solve. Like for example, we really want to make sure we're keeping an eye on quality and reliability, so those are some of the things that 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, actually, I still have a couple of questions that I'm still asking myself. Um, the iOS and Android org is a very interesting one. Like when engineers can now more efficiently kind of flex across different mobile platforms, does a more traditional way of, you know, uh, having an iOS team and an Android team still make sense? That's something that I'm still kind of thinking through.
自动化审查推到多远？什么时候你能找到"够快"和"不丢重要东西"之间的平衡？还是 trust but verify。有意思的是你们今天可能也在 Danella 的演讲里听到了，模型能力在持续提升。所以即便现在某些领域你需要更多人工验证，下一个模型出来之后可能就不一样了。这就是为什么持续重新评估很重要。还有角色模糊化的问题——怎么确保每个人都觉得自己同样有效率和归属感？
How much do you push that fully automated review? Again, like when do you kind of 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 even might have heard today in earlier during Danella's talk, the model capabilities do keep improving. So also, 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 why it's always important to re-evaluate. And roles are blurring, so how do you make sure that everybody feels equally uh, productive?
如果让我给你们留一个可以带走的行动建议的话——找到你最"noisy"的工作流。所谓 noisy，可能是最昂贵的、你最害怕的、或者你的团队最不期待的那个。然后问一个问题：它还在服务于最初的目的吗？我再分享一个故事。我之前所在的团队有一个周例会，非常昂贵——50 个人在一个大房间里。然后我注意到所有人都在看笔记本电脑，只有轮到自己汇报进度的时候才抬头说两句，然后又低头继续。我想，这是一个非常昂贵的会议。我就问了一个简单的问题："我们为什么要开这个会？"就这一个问题，所有人都说"确实啊。"然后我们就取消了。
So if I were to leave you with one, you know, thing to take back — is, you know, pick your noisiest workflow. And by noisiest workflow, it could be most expensive, what's something that, you know, what you yourself might be dreading, or even your team might not really look forward to it. And ask, is it still really serving — what's the purpose of there? Like, 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, you know, 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 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 to think. And so, yeah, like I 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, you know, proving — is it still serving its intended purpose.
我的演讲就到这里了。谢谢大家。
So, with that, that's the end of our talk. I'm like, thank you.
**Audience：** [applause]
**Audience:** [applause]
**Fiona Fung：** 谢谢。真的非常感谢大家来参加。我本来真的觉得这个房间会空无一人。所以谢谢大家没有让我一个人在这儿。我今天和明天都在这里，如果有任何问题或者想多聊聊，随时来找我，很高兴认识大家。
**Fiona Fung:** Thank you. Thanks a lot for attending. I really, really for sure thought this room was going to be empty. So, thanks for not having 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.
