Running an AI-native Engineering Org

"Good afternoon, and thanks for attending. My name is Fiona Fung, and I lead Claude Code and co-work 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 Microsoft."

「下午好,谢谢各位的出席。我叫 Fiona Fung,负责 Claude Code 和 co-work 的工程与产品,所以我和 Boris、Cat 配合得非常紧密。来 Anthropic 之前,我在 Meta、之后又在 Microsoft 带过、也带大过一些团队。」

"For today's talk, the whole idea is: what are some of the lessons I learned helping Claude Code and co-work grow, as we're building out this team? And it's interesting — these are lessons I learned even thinking back to my time at Meta or Microsoft, but also at Anthropic."

「今天这场的核心想法是:在我帮 Claude Code 和 co-work 成长、搭建这支团队的过程中,学到了哪些经验?有意思的是,这些经验有些是我回看在 Meta、在 Microsoft 的时候学到的,但也有不少就来自 Anthropic。」

"It's funny — I made this slide deck maybe a month ago, and already I've had to change some of the content. For example, when I started this deck, there were no routines, and even that way of working was different for me."

「挺好笑的——这套幻灯片我大概是一个月前做的,结果已经得改掉一些内容了。比如说,我开始做这套 deck 的时候,还没有 routines(例行自动化)这个东西,而那种工作方式对我来说本身就是新的。」

"I want to cover five themes I've noticed. One: the bottlenecks have moved, they've shifted. So when bottlenecks shift, what are some of the team norms we had to rewrite within the Claude Code team? I also want to share how we rolled them out, and what are some of the signals I get that, yeah, we're trending in the right direction."

「我想讲我观察到的五个主题。第一:瓶颈移动了、转移了。那么当瓶颈转移时,我们在 Claude Code 团队里不得不重写哪些团队规范?我也想分享我们是怎么把这些规范推行下去的,以及有哪些信号让我判断:嗯,我们正朝着对的方向走。」

"And it's always going to be important for me to keep checking: is it still serving us, still trending in the right direction? Then I'll end with a few questions that I still have for myself, and some suggestions for you to maybe take back to your teams and have conversations together."

「而且对我来说,持续地回头检查永远很重要:这套东西还在帮我们吗?还在朝对的方向走吗?最后我会以几个我自己仍在追问的问题收尾,再给你们一些可以带回团队、一起讨论的建议。」

"So, the first section: the bottlenecks have moved. I call it the shift. You'll probably hear me repeat this subtitle a lot: what served you prior may not serve you any longer."

「那么,第一部分:瓶颈移动了。我管它叫『the shift』(转移)。你大概会听到我反复重复这句副标题:对你过去有用的,现在未必还有用。」

"Even when I think about all my experience — whether at Anthropic, Meta, or Microsoft — the constant growth mindset is just a muscle that has served me really well. Especially right now, when the rate of change is just a little bit crazy, right?"

「就算回看我所有的经历——不管是在 Anthropic、Meta 还是 Microsoft——那种持续的成长心态(growth mindset),都是一块对我帮助极大的『肌肉』。尤其是现在,变化的速度有点疯,对吧?」

"I remember the first time I started doing some live coding was last year, and it was still making bugs where I'm like, 'Why are you using constants everywhere? That's not good engineering practice.' And now it's become so much more capable. That's the interesting shift: when the bottleneck moves, how do you think about adapting everything else around that bottleneck?"

「我记得我第一次开始做 live coding(现场写代码)还是去年,那会儿它还会写出一些 bug,我会想:『你干嘛到处用常量?这不是好的工程实践啊。』而现在它的能力已经强了太多。这就是那个有意思的转移:当瓶颈移动了,你要怎么去思考——围绕这个瓶颈的其他一切,该如何相应调整?」

"Maybe y'all are feeling this too: for years, engineering bandwidth was the expensive thing. Coding throughput was really expensive. And when you think about all the processes we have for shipping software, a lot of it was built around that."

「也许你们也有同感:很多年来,工程带宽(engineering bandwidth)一直是那个『贵』的东西。编码吞吐量非常昂贵。而当你回想我们交付软件的那一整套流程,很多都是围绕这一点建起来的。」

"When you think about how we used to do planning — remember we used to do waterfall, and then agile — all of that was because engineering bandwidth was really expensive."

「想想我们过去是怎么做规划的——记得吗,先是瀑布(waterfall),后来是敏捷(agile)——这一切之所以这样,都是因为工程带宽真的很贵。」

"I'll take a little segue. This is not the first time our industry has had to adapt. Let me put you all in a time machine, back to the year 2000s — that's when I started my career. I worked on Visual Studio, and we were shipping Visual Studio 2005."

「我稍微岔开讲一下。我们这个行业要适应变化,这不是第一次。我把你们都放进一台时光机,回到 2000 年代——那是我职业生涯开始的时候。我当时做 Visual Studio,我们正在发布 Visual Studio 2005。」

"And I kid you not — in those days we used to ship software on CD-ROMs. Before CD-ROMs, it was actually floppy disks. I still remember VS 2005: there were really hard deadlines, because we had to get the software to the manufacturing lab to print on the CDs, put them in boxes, and ship them to stores."

「我可没夸张——那时候我们是用 CD-ROM 光盘发布软件的。在 CD-ROM 之前,其实是软盘(floppy disk)。我还记得 VS 2005:有非常硬的截止日期,因为我们必须赶在期限前把软件送到生产车间,压制到光盘上,装进盒子,再铺到商店里。」

"So when we were able to distribute software online, that also changed how we ship software. And that's what I find really interesting about this new shift: engineering bandwidth is no longer the expensive thing. On the Claude Code team, coding is rarely the slow part anymore."

「所以当我们能够在线分发软件时,这本身就改变了我们交付软件的方式。这也是我觉得这次新转移特别有意思的地方:工程带宽不再是那个『贵』的东西了。在 Claude Code 团队,编码已经很少是拖慢进度的那一环了。」

"And it's not even just that it's not the slow part — the throughput has really, really increased. So it's not only 'yay, we all get to build more.' The amount that we're generating has also changed a lot."

「而且,它不仅仅是『不再拖后腿』——吞吐量是真的、真的大幅上升了。所以这不只是『耶,我们都能造更多东西了』,我们生成的总量本身也变了很多。」

"It used to be that writing code was expensive, or writing tests, or refactoring. I remember all those conversations: 'We have to schedule time to do refactoring. Oh, but we have product work — when are you going to find that time?' All of that has shifted. That is no longer the bottleneck."

「过去,写代码是昂贵的,写测试、做重构也是。我还记得那些对话:『我们得排出时间来做重构。可是还有产品工作要做啊——你哪有空去搞重构?』这一切都转移了。那已经不再是瓶颈了。」

"And when that happens, the bottlenecks end up shifting toward other areas. For example: verification, review, cross-functional partners, security. Because coding is no longer the bottleneck — and we're doing so much more of it — these are the new bottlenecks we're seeing."

「而当这种情况发生时,瓶颈最终会转移到别的地方。比如:验证(verification)、评审(review)、跨职能伙伴、安全(security)。正因为编码不再是瓶颈,而且我们写的代码量又多了那么多,这些就成了我们看到的新瓶颈。」

"So it's always us asking: is this code correct? Who reviews this code? That's probably one of the top questions I get from fellow eng leaders: how are humans keeping up with the code reviews? And also, how is it maintained — because now it's a lot easier for us all to generate a lot of code, so think about that maintenance cost too."

「所以我们一直在问:这段代码对吗?谁来评审这段代码?这大概是我从其他工程负责人那里最常被问到的问题之一:人类怎么跟得上你们这种速度的代码评审?还有,它要怎么维护——因为现在我们所有人生成大量代码都容易多了,所以那份维护成本也要一并考虑。」

"These are some of the processes that I noticed quietly stop working. And I love that phrase — quietly stop working. A lot of times we all put in processes for a reason, right? We think 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."

「这些就是我注意到会『悄悄失效』(quietly stop working)的一些流程。我特别喜欢这个说法——悄悄失效。很多时候我们设立流程都是有理由的,对吧?我们觉得这里有个缺口,或者想做改进。但这些年我发现:流程极少会自我了结。我们往往只是一层、一层、又一层地往上叠流程。」

"I remember on one team we had so many SLAs — a P0 bug SLA, a high-pri review SLA — so many SLAs that after a while I'm like, 'Oh no, we need to stack-rank priorities so engineers know which SLA is even more important.' And even then I thought: we should start thinking about what to defrag a little bit."

「我记得有一个团队,我们有特别多的 SLA(服务级别承诺)——P0 bug 的 SLA、高优先级评审的 SLA……SLA 多到后来我都想:『糟了,我们得给优先级排个座次,好让工程师知道哪个 SLA 更重要。』就算到了那个时候,我就在想:我们该开始考虑——有什么是可以稍微『碎片整理』(defrag)掉的。」

"So these are processes that might have served you — remember, what may have served you may not serve you any longer. Planning norms: we used to spend a lot more time pre-planning, because coding time was expensive. Code ownership: there used to be a lot of questions about who wrote this code, who owns it — that's a bit of a different question now."

「所以这些都是曾经对你有用的流程——记住,曾经对你有用的,现在未必还有用。规划规范:我们过去花在前期规划上的时间多得多,因为编码时间很贵。代码所有权:过去常有很多关于『这段代码谁写的、谁拥有它』的问题——现在这是个有点不一样的问题了。」

"Code reviews — we'll get into that. Team makeup is interesting too: roles are blurring. Engineers can do more, and now we have AI to augment non-engineering roles — my non-engineering partners are all shipping code. So what happens when roles blur and you don't have those silos anymore? And then there's knowledge sharing and onboarding — another signal we're noticing at Claude Code that how we used to do things is changing a little too."

「代码评审——这个我们待会儿细讲。团队构成也很有意思:角色正在模糊。工程师能做的更多了,而现在我们又有 AI 来增强非工程角色——我那些非工程的伙伴们现在都在提交代码。那么当角色开始模糊、不再有那些壁垒(silos)时,会发生什么?还有知识共享和 onboarding(新人上手)——这是我们在 Claude Code 注意到的又一个信号,我们过去的做法也在悄悄改变。」

"In the first section we talked about the shift. So within the Claude Code team, what are some of the norms we had to rewrite? Number one is code review — human judgment of who actually needs it. Onboarding has changed. How we do planning. Hiring, especially with roles blurring and team makeup. And also org shape — that's one of my favorite spicy topics. I'll share the story of when I started proposing that at Anthropic; one recruiting partner really did think I was crazy."

「第一部分我们讲了『转移』。那么在 Claude Code 团队里,我们不得不重写哪些规范?第一个是代码评审(code review)——对『到底谁真正需要它』做人为判断。Onboarding 变了。我们做规划的方式变了。招聘也变了,尤其是在角色模糊、团队构成变化的情况下。还有组织形状(org shape)——这是我最喜欢的『辣味』话题之一。我会讲讲我在 Anthropic 开始提这件事时的故事;有位招聘伙伴是真的觉得我疯了。」

"So how has planning changed? Planning — we do a lot less of it. And the timing too: I call it JIT planning, almost like JIT compiling. Because even when I first joined, I'm like, 'Don't we need a six-month roadmap?' We put 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 already changed."

「那么规划是怎么变的?规划——我们做得少多了。时机也变了:我管它叫 JIT planning(即时规划),几乎就像 JIT 编译(JIT compiling)。因为我刚加入的时候还想:『我们难道不需要一个六个月的路线图吗?』我们花了功夫,把它写出来了,前三个月还挺好用——结果我过完新年回来,好多事情已经变了。」

"So I realized a six-month roadmap just seems a little too long. It's about doing just the right amount at the right time — because, again, prototyping and code generation is just not the bottleneck it used to be."

「所以我意识到,六个月的路线图似乎就是太长了点。关键在于:在对的时间,只做刚好够的量——因为,还是那句话,原型和代码生成已经不是过去那个瓶颈了。」

"The technical-debate one is fun too. In technical debates, code wins. When I first joined the Claude Code team, I wanted to do a refactoring — I wanted to learn the code base. Me and Boris had a healthy technical debate about which way to go, and I almost leaned into my old toolbox. I almost tapped him on the shoulder: 'Let's go to that room and whiteboard it.'"

「技术争论那条也很有意思。在技术争论里,代码说了算(code wins)。我刚加入 Claude Code 团队时,想做一次重构——想借此熟悉代码库。我和 Boris 有过一场健康的技术争论,争该走哪条路,而我差点又拿起了我那套老工具。我差点拍他肩膀说:『走,我们去那个房间,在白板上画一画。』」

"And I'm like — 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 for the technical debate is: I cared not only about the implementation of the API, but also the impact to all the callers into the API. When Claude helps me generate the three versions, it lets us debate not just implementation, but impact to the callers."

「然后我就想——等等、等等、等一下。如今我完全可以直接把我们一直在讨论的各种方案都生成出来。我生成了三个 PR。而对这场技术争论来说,最妙的地方是:我在意的不只是这个 API 的实现,还有它对所有调用方(callers)的影响。当 Claude 帮我把三个版本都生成出来,我们就能不只辩论实现,还能辩论它对调用方的影响。」

"So when building is cheap and arguing is expensive — how does that shift your team norms? I do want to call out: this makes it even more important to set up team culture for how you think about alignment. What totally won't fly is, because code is so fast to generate, it becoming 'the last person who checks in wins' — like I'm going to stay up to submit this PR, or I set up a routine so I get the last word in. Definitely a no-no."

「所以当『构建变便宜、争论变昂贵』时——这会怎样改变你的团队规范?我特别想强调一点:这反而让『建立关于如何对齐(alignment)的团队文化』变得更重要了。绝对行不通的是:因为代码生成太快,就变成『最后 check-in 的人赢』——比如我熬夜也要把这个 PR 提交了,或者我设个 routine 让我能抢到最后发言权。这绝对是禁忌。」

"That makes it even more important to have good team culture that can hold open, honest technical debates, plus good team alignment."

「正因如此,拥有一个能进行开放、诚实的技术争论、同时又有良好对齐的团队文化,就更加重要了。」

"I talked about what we reduce in planning. On Claude Code, we've definitely reduced the design-doc-before-every-code ritual. For certain teams and scenarios, design docs are still really important — especially for async discussions. But on Claude Code, most of our discussions are, instead of a doc, a PR. That's one of our sayings: 'Hey, we found an idea — go prototype.'"

「我讲了我们在规划上做的减法。在 Claude Code,我们明确减少了『每写代码前先写设计文档』这个仪式。对某些团队、某些场景,设计文档仍然很重要——尤其是做异步讨论的时候。但在 Claude Code,我们的大多数讨论,与其说是一份文档,不如说是一个 PR。这就是我们的一句口头禅:『嘿,我们有个想法——去做个原型。』」

"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 get a lot of internal Ants using it, and I'm a big fan of shipping it out to all of you and then hearing the excellent feedback. That has changed our planning ritual to be a lot less design docs, and mostly discussions in PRs or prototypes."

「另一件事:我们其实不怎么做产品评审(product reviews),因为局势变化太快。所以我们就去做原型,让大量内部的『Ants』(Anthropic 同事)先用起来,而我特别喜欢把它直接发布给在座各位,然后听到那些精彩的反馈。这就让我们的规划仪式变成了:设计文档少很多,讨论大多发生在 PR 或原型里。」

"So we reduced that — but what did we double down on? And this is an area where we actually need to do more and keep getting better: verification. Because the throughput is different, and there are new ways to break. So how can you scale out? I call it shift left."

「所以那些我们做了减法——但我们在哪里加倍投入了?而且这是一个我们其实还需要做得更多、继续做得更好的领域:验证(verification)。因为吞吐量变了,而且出错的方式也变多了。那你要怎么扩展应对?我管它叫 shift left(把质量关口往源头左移)。」

"In the old days, you'd get code out, and I would love to find bugs before any of you find them. But what's better than me finding a bug is shift left — more automation, so we catch it earlier, closer to the source. That's something we need to keep doubling down on."

「在过去,你把代码发出去,而我最希望的是在你们任何人发现之前先把 bug 找出来。但比『我来抓 bug』更好的,是 shift left——更多自动化,让我们更早、更靠近源头就把它接住。这是我们需要持续加倍投入的事。」

"And because roles are blurring — my designers, for example — I'd love everyone to have more confidence that when they check in code, they don't break something. I remember I fixed a bug in resume or something, and the next day I was catching up on Boris's threads and saw someone tag him: 'I'm noticing a bug.' I had that sinking feeling — did I just cause a bug?"

「而且因为角色在模糊——比如我的设计师们——我特别希望每个人在 check in 代码时,都能更有信心:我没把别的东西弄坏。我记得我修了个 bug,好像是关于恢复(resume)的,第二天我在补看 Boris 的讨论串,看到有人 @ 他:『我发现一个 bug。』我心里就一沉——是不是我刚才捅出来的?」

"Because of the throughput, I really want everybody — regardless of role — to have a lot higher confidence in the change they're putting in."

「正因为吞吐量变大了,我真的希望每个人——无论什么角色——对自己提交的改动都有高得多的信心。」

"'Who made this change?' Because all our PRs are Claude-assisted, that's a bit of an odd question now. What's more helpful than that question is what I call double-clicking into it. In the old days, when you asked 'who made this change,' what are you really trying to answer? Are you looking for who caused this regression — definitely not to blame, just to know who last touched the code that might have caused the break? Are you looking for an expert to answer a customer question? Or are you looking to gain context?"

「『这改动是谁做的?』因为我们所有的 PR 都是 Claude 协助的,这个问题现在有点怪了。比这个问题更有用的,是我说的『双击进去』(double-click into it)。过去你问『谁做了这个改动』,你真正想回答的是什么?你是想找出谁造成了这次回归(regression)——绝不是要追责,只是想知道最后碰过这段、可能导致出错的代码的是谁?你是想找一个专家来回答客户的问题?还是你想补上下文(context)?」

"Whatever that double-click question is, also think about: is there a way you can automate it? When I started this talk about a month ago, part of my every morning was to bring up my desktop Claude, go into a customer-feedback channel, and ask it to summarize — a morning ritual with my cup of coffee. Now it's routines. I can set that up, and it's even better than how I used to kick it off."

「不管那个『双击之后』的真问题是什么,也想想:有没有办法把它自动化?大约一个月前我准备这场演讲时,我每天早上的一部分,就是打开我的桌面端 Claude,进到一个客户反馈频道,让它做个总结——这是我配着咖啡的晨间仪式。现在它变成 routines 了。我可以把它设好,而且比我以前手动开启的方式还要好。」

"So my point is: code ownership is a bit more fuzzy now, but on the flip side — double-click to the question you're really trying to answer, and see how Claude can help you with those."

「所以我的意思是:代码所有权现在变得模糊了一些,但反过来——双击到你真正想回答的那个问题上,再看看 Claude 能怎么帮你解决它们。」

"How do you keep up with code reviews? If you saw the keynote this morning, Kat talked about it. We leverage Claude code review heavily. What's interesting is: where do you trust Claude a lot, but where do you still want a human?"

「你要怎么跟上代码评审的节奏?如果你看了今早的主题演讲,Kat 讲过这个。我们大量使用 Claude 来做代码评审(Claude code review)。有意思的是:哪些地方你高度信任 Claude,而哪些地方你仍然想要一个人?」

"As Kat showed, Claude also does a great job babysitting PRs. We have Claude handle all the styling and lint and PR feedback requests, even catching some bugs and fixing them before a full commit, and adding tests. That's what we've leaned heavily into Claude for."

「正如 Kat 演示的,Claude 在『看管 PR』(babysitting PRs)这件事上也做得很好。我们让 Claude 处理所有的样式、lint 和 PR 反馈请求,甚至在正式 commit 之前就抓出一些 bug 并修掉,还有补测试。这些就是我们重度依赖 Claude 去做的事。」

"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 my legal partner. Risk tolerance — for trust boundaries and security-sensitive code, I still want to pull in the experts."

「但有些地方我仍然绝对想要一个人,那就是专业判断。一切都是『信任但要核实』(trust but verify)。比如法务评审——我永远要拉上我的法务伙伴。风险容忍度——涉及信任边界(trust boundaries)和安全敏感代码,我仍然要把专家拉进来。」

"The other area, which is kind of fun, is product sense and taste. One of the fun things I like to use Claude for is decorating Claude for the holidays. Last holiday, I wanted to give Claude in the terminal a little holiday theme, so I asked Claude Code to turn Claude into a snowman. Claude wasn't that good at ASCII art in those days."

「另一个领域挺好玩的,就是产品 sense 和品味(taste)。我喜欢用 Claude 做的一件趣事,是给 Claude 做节日装饰。上个假期,我想给终端里的 Claude 加一点节日主题,于是我让 Claude Code 把 Claude 变成一个雪人(snowman)。那会儿 Claude 的 ASCII 字符画还不太行。」

"That's where product sense comes in. I asked my design partner, 'Hey, can you review this?' And she gave me such good feedback. She's like, 'You turned Claude into the Mr. Peanut character.' I was trying to make him snow-themed, so I was like, okay, I'll do something simpler — Claude in ice blue with a snowflake. But keep that product sense in mind."

「这时候产品 sense 就派上用场了。我问我的设计伙伴:『嘿,你能帮我看看这个吗?』她给了我特别到位的反馈。她说:『你把 Claude 变成 Mr. Peanut(花生先生)那个卡通形象了。』我本来是想把它做成雪的主题,于是我想,行吧,那我搞个更简单的——冰蓝色的 Claude 配一片雪花。但记住,要带着那份产品 sense。」

"Which leads me to: what should my team makeup be? Because roles are blurring and Claude is augmenting. On Claude Code, there are two profiles of engineers I've heavily indexed on. One is creative builders with product sense — usually the dreamers, a big sense of curiosity, passionate about 'here's a problem, maybe I could ship a product that solves it,' with a lot of iteration to deliver a delightful experience."

「这就引到:我的团队构成该是什么样?因为角色在模糊,而 Claude 在做增强。在 Claude Code,我重点押注两类工程师。一类是有产品 sense 的创意 builder(creative builders with product sense)——通常是那些『做梦的人』,有强烈的好奇心,对『这里有个问题,也许我能做个产品来解决它』充满热情,并且会反复打磨,只为交付一种令人愉悦的体验。」

"The other is deep systems expertise. When I first joined Claude Code, I noticed we were pretty good with product generalists and creative folks, but we were missing people with distributed-systems expertise. When you're building things like Claude Code remote — to run Claudes everywhere — you really still need that expertise."

「另一类是深度的系统专长(deep systems expertise)。我刚加入 Claude Code 时,注意到我们在产品通才和创意型人才上挺强,但缺少有分布式系统(distributed systems)专长的人。当你要做 Claude Code remote 这类东西——让 Claude 能在任何地方运行——你真的仍然需要那种专长。」

"So whichever software-engineering area you're part of, think about the hard parts where you might want to keep doubling down. But what I index less on is raw throughput, because thanks to the models, we're just a lot more efficient."

「所以不管你所在的是哪个软件工程领域,都去想想那些『难的部分』——你可能想在那里继续加倍投入。而我越来越少看重的,是原始吞吐量(raw throughput),因为有了这些模型,我们的效率本来就高多了。」

"The cross-functional gaps are interesting too. I wanted to update how we do survey responses, but I didn't have a dedicated content designer, and I'm an engineer — my writing skills are quite terrible. I struggle to write things short and succinct, and I didn't want surveys to overload you all in the terminal, because every line of space matters."

「跨职能的空缺也很有意思。我想改一改我们做问卷回复(survey responses)的方式,但我手头没有专职的内容设计师,而我是个工程师——我的文笔相当糟糕。我很难把东西写得又短又精炼,而我又不想让问卷在终端里把大家淹没,因为每一行空间都很宝贵。」

"In the old days I'd be asking, 'Who's a content designer I can work with?' But now Claude has really helped augment that role — it was a really good content-design partner, helping me make the verbiage good and succinct. And on the flip side, our PMs code a lot, which is really fun to see."

「放在过去,我会到处问:『有哪个内容设计师能跟我合作?』但现在 Claude 真的帮我补上了那个角色——它是个相当不错的内容设计伙伴,帮我把措辞打磨得既准确又精炼。而反过来,我们的 PM 们写了很多代码,看着特别有意思。」

"So with Claude, you have non-traditional coders now able to do more engineering, but you also have engineers who can now lean into things that traditionally weren't on the technical side — more content or design. It's very interesting. I've found Claude and AI have really augmented roles all around."

「所以有了 Claude,一方面非传统的写代码者现在能做更多工程的事,另一方面工程师们现在也能往一些传统上不属于技术侧的事情上靠——更偏内容或设计。非常有意思。我发现 Claude 和 AI 真的把各个角色全方位地增强了一圈。」

"This was a spicy one. When I first joined Claude Code, everyone's 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 nest from there. I really leaned into keeping it scrappy."

「这条比较『辣』。我刚加入 Claude Code 时,大家都说:『好,你要把团队扩张到某个规模。』而我看得出来,招聘官们还在用那套典型的『10 个 IC 配 1 个经理』,然后再从这里往上嵌套。而我特别坚持把团队保持得『精简凑合』(scrappy)。」

"Stepping back — whether at Anthropic, Meta, or Microsoft, whether Visual Studio or Facebook Marketplace or AR/VR devices or Claude — what I've found really helps 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, and when you can't get your hands on the code, I'd always make the time to actually use my product day in, day out."

「往回退一步看——不管是在 Anthropic、Meta 还是 Microsoft,不管是 Visual Studio、Facebook Marketplace、AR/VR 设备还是 Claude——我发现真正帮我做出好产品的,是极其、极其、极其重度的 dogfooding(自己吃自己的狗粮、亲自用自家产品)。对领导者尤其如此。如今这其实挺有乐趣的:我还能待在代码里。但有一阵子并非如此,而当你没法亲手碰代码时,我总会专门挤出时间,日复一日地真正去用我自己的产品。」

"That's why I wanted every manager in Claude Code to start out as an IC first — to earn some street cred with the team, and really learn how to be an effective engineer. And I structured the org to be as flat as possible, because I want us to be super agile."

「这就是为什么我希望 Claude Code 里的每一位经理,都先从 IC(个人贡献者)做起——好在团队里挣到一点『街头信誉』(street cred),并真正学会怎么当一名高效的工程师。我还把组织结构搭得尽可能扁平,因为我想让我们超级敏捷。」

"My recruiters had concerns. I remember they said, 'You want to hire managers, and they'll 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 is about, and this is what I expect. If someone's not interested, it's better for us to do an earlier separation."

「我的招聘官们有顾虑。我记得他们说:『你要招经理,可他们得先从 IC 干起?没有经理会愿意干这个。』我就说,行吧,这正是 Claude Code 团队 dogfooding 的意义所在,也是我的期望。如果有人不愿意,那对我们双方来说,早点分手反而更好。」

"There's no way I would have been able to ramp or do code, because my time has so much context switching, without Claude. So for those of you who are managers, I really encourage you to lean in. I'll be honest — for a long time at Meta, I'd try to do one PR a year, but the workflows would always change. By the time I learned one internal command, it would have changed. Nowadays I don't even remember git commands — I just ask Claude to help me out."

「要不是有 Claude,我根本不可能把状态拉起来、也写不了代码,因为我的时间里充满了上下文切换(context switching)。所以在座如果你是经理,我真心鼓励你扑进去。说实话——在 Meta 很长一段时间,我会尽量一年做一个 PR,但工作流总在变。我刚学会一条内部命令,它就又变了。如今我连 git 命令都不记得了——我直接让 Claude 帮我搞定。」

"With knowledge sharing — what becomes your new source of truth? On the Claude Code team, the code is the source of truth. That's why, when I'm answering customer requests, I just have my desktop Claude with Claude Code and all my local repositories, and I actually answer a lot of customer questions that way."

「关于知识共享——你新的『真相之源』(source of truth)是什么?在 Claude Code 团队,代码就是真相之源。所以当我在回复客户请求时,我只要打开桌面端的 Claude、配上 Claude Code 和我所有的本地代码库,我其实就能这样回答很多客户的问题。」

"Having that code base be the source of truth also prevents some of the lag you might have had before — keeping documentation correct and in sync with the code. But this is where you should do what makes sense for your team. If you still have a lot of really good specs, check those into the repositories, and have Claude lean in — 'hey, verify my code execution matches what I expect from the spec.'"

「让代码库成为真相之源,还能避免过去那种滞后(lag)——也就是费力让文档保持正确、跟代码同步。但这一点,你该按对你团队合理的方式来做。如果你仍然有很多很好的规格说明(specs),就把它们 check 进代码库,然后让 Claude 介入——『嘿,帮我核实一下,我的代码执行结果是否跟我在 spec 里预期的一致。』」

"So how did we roll it out? There's a blend of what we mandate as team norms — making sure you gain alignment with the team — and where I really enable each pod within Claude Code to do what makes sense for them. In terms of forcing function, align with the teams on the must-dos."

「那我们是怎么把这些落地的?这里有一个混合:哪些是我们作为团队规范去『强制』(mandate)的——确保你和团队达成对齐;哪些是我真正『赋能』(enable)Claude Code 里每个 pod(小组)去做对他们合理的事。在『推动机制』(forcing function)上,在那些『必须做的事』(must-dos)上要和团队对齐。」

"These are a few of the core Claude Code team principles we live and breathe. And remember the growth mindset — always ask whether something is still serving you. We keep these up to date. Every few months we ask, 'Is this still having the same effect, still serving the purpose we wanted when we started it?'"

「这是我们身体力行的几条 Claude Code 团队核心原则。还记得那个成长心态吗——永远问一句:这东西还在帮你吗?我们会让这些原则保持更新。每隔几个月我们就问:『它还有当初那个效果吗?还在服务于我们当初设立它时想要的目的吗?』」

"For example — I should replace this slide — it's not 'every engineer uses Claude Code,' that's obvious. It's that every Claude Code team member, including cross-functional partners, uses it. And we all use co-work quite a bit too."

「举个例子——这张幻灯片我该换了——原则不是『每个工程师都用 Claude Code』,那太显然了。而是:每一个 Claude Code 团队成员,包括跨职能的伙伴,都在用它。而且我们也都相当多地在用 co-work。」

"'Claudify everything you can.' This is one where we're like, what's better than one of us doing it? Having Claude do it. So always think: is there some way to automate — verification, more shift left — whatever you're doing right now, is there some way Claude could help you do it?"

「『能 Claude 化的都 Claude 化』(Claudify everything you can)。这条的意思是:有什么比我们自己动手更好?让 Claude 来做。所以永远想一想:有没有办法把它自动化——验证、更多的 shift left——你此刻在做的任何事,有没有某种方式让 Claude 来帮你做?」

"And the last one's my favorite: explicit permission to kill old processes. Because processes won't kill themselves. As you support teams, it's really important to get fast feedback on what things you're spending a lot of time on. When I first joined Claude Code, we used to do stand-ups. The team got big, so we had a spreadsheet where we'd all put our weekly progress. Then I was like, wait — we should just do a skill, a stand-up script, so we run Claude and everyone stays much more aware of what everybody else is doing."

「最后一条是我最爱的:明确授权去杀掉旧流程(explicit permission to kill old processes)。因为流程不会自我了结。当你在支撑团队时,快速拿到反馈、看清你们到底在哪些事上花了大量时间,非常重要。我刚加入 Claude Code 时,我们会开站会(stand-ups)。后来团队大了,于是我们搞了个电子表格,大家都把每周进展填进去。然后我就想,等等——我们直接做个 skill、做个站会脚本(stand-up script)不就好了,这样跑一下 Claude,所有人都能更清楚地了解彼此在做什么。」

"That's another example of: one day I remember the spreadsheet, and — does this still make sense anymore? So always question, always look to defrag and kill old processes."

「这又是一个例子:某天我看着那个电子表格,就想——这玩意儿现在还有意义吗?所以永远去质疑,永远去『碎片整理』、去杀掉旧流程。」

"What I want to leave a lot of room for is pods to adapt. Each team 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 which workflows to Claudify first. We don't usually mandate 'thou shalt automate this.' We have suggestions and learnings, but always give room to your team, especially since they may be touching different problem areas."

「我想为之留出大量空间的,是让 pod 去自我调整。每个团队在很多事上都有很高的能动性(high agency):怎么做 triage(问题分诊)、或者用 Claude 来做 triage、任何规划仪式或站会、怎么看待 on-call(值班)、以及先把哪些工作流 Claude 化。我们通常不会强制『尔等必须自动化此项』。我们有建议、有经验沉淀,但永远给你的团队留出空间,尤其是因为他们可能正在处理不同的问题领域。」

"So if I zoom out, what were the three things I prioritized when I joined Claude Code that I felt made the biggest difference? Keeping the team as flat as possible — managers release pods of work, but keep it agile. On Claude Code and co-work we have one overall team mission, because when you create pods, each pod might want its own mission, and then anytime you have to shift, it takes a lot of time to walk people through it. As flat as you can — that served us really well."

「所以拉远来看,我刚加入 Claude Code 时,优先做的、我觉得带来最大不同的三件事是什么?第一,把团队保持得尽可能扁平——经理们放出一个个 pod 去做事,但保持敏捷。在 Claude Code 和 co-work,我们只有一个整体的团队使命(team mission),因为一旦你建起 pod,每个 pod 可能都想立自己的使命,那么每次你需要转向时,就要花很多时间把人一个个讲明白。尽可能扁平——这一点对我们帮助极大。」

"Claudify everything — better than you doing it, see how Claude can help. It frees us up to do more of the harder work. And the processes — they pile on, so I encourage you to work with your team to see which ones you should actually let go."

「能 Claude 化的都 Claude 化——比你自己做更好,看看 Claude 能怎么帮你。它把我们解放出来,去做更多更难的工作。还有流程——它们会不断堆积,所以我鼓励你和团队一起看看,究竟哪些是你真正该放手的。」

"So does it actually work? I can't go into explicit numbers, but here are three general metrics you can look at as you roll out changes. Onboarding ramp-up time — that has dramatically reduced: how soon an engineer, designer, or PM can start being effective on your team."

「那它到底有没有效?我没法讲具体数字,但这里有三个通用指标,你在团队里推行变化时可以看。第一,onboarding 上手时间——这个大幅下降了:一名工程师、设计师或 PM 能多快开始在你的团队里产生效用。」

"PR cycle time shortening. This one's interesting to double-click into, because it might help you identify a gap that's not just lack of AI adoption, but where the rest of the pipeline is struggling to scale. For example, as we put in so much more code, sometimes the product infrastructure and CI can't keep up with the amount engineers are checking in."

「第二,PR 周期时间(PR cycle time)缩短。这个值得双击进去看,因为它可能帮你发现一个缺口——不只是 AI 采用不足,而是流水线的其余部分在艰难地扩展。比如说,随着我们投入多得多的代码,有时产品基础设施和 CI 跟不上工程师 check in 的量。」

"Both of those should go down. But what should go up a little is Claude-assisted commits. For us, by default every commit is Claude-assisted — I don't think I've seen a non-Claude-assisted commit in probably the last four months."

「这两个指标都应该往下走。而该往上走一点的,是 Claude 协助的 commit(Claude-assisted commits)。对我们来说,默认情况下每一个 commit 都是 Claude 协助的——我大概有四个月没见过一个非 Claude 协助的 commit 了。」

"I'd also say: beyond number of commits, think about the end goal. If you zoom out, what's the product you're trying to make more delightful, or the problem you're trying to solve? Sometimes you see headlines — 'this company says X% of code is now AI-generated.' Throughput is great, but really think about how you measure what you're actually trying to solve. We really want to keep an eye on quality and reliability."

「我还想说:除了 commit 的数量,要想想最终目标(end goal)。拉远来看,你想让哪个产品变得更令人愉悦?你想解决的是什么问题?有时你会看到那种标题——『某公司说现在 X% 的代码由 AI 生成』。吞吐量当然很好,但要认真想想:你该如何衡量你真正想解决的东西。我们非常想盯住质量和可靠性(quality and reliability)。」

"My last section: audit your own effort. I'll share transparently — I still have a couple of questions I'm asking myself. The iOS and Android org is an interesting one. When engineers can now more efficiently flex across mobile platforms, does the traditional way of having a separate iOS team and Android team still make sense? That's something I'm still thinking through."

「我的最后一部分:审视你自己的投入。我坦白分享——我自己还有几个仍在问自己的问题。iOS 和 Android 组织就是个有意思的例子。当工程师现在能更高效地在不同移动平台之间灵活切换,那么传统上『分一个 iOS 团队、一个 Android 团队』的做法,还成立吗?这是我仍在思考的问题。」

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

「你要把完全自动化的评审(fully automated review)推到多深?你在哪里取得『够快』和『我们丢掉了某些重要东西』之间的平衡?这又回到了 trust but verify。而且你可能在早些时候 Danella 的演讲里听到过——模型能力在持续提升。所以即便对某一块工作,你现在需要『核实多于信任』,这也可能随着下一代模型而改变。这正是为什么持续地重新评估永远重要。」

"And roles are blurring — so how do you make sure everyone feels equally productive?"

「还有,角色在模糊——那么你要怎么确保每个人都感到同样地有生产力(productive)?」

"If I were to leave you with one thing to take back: pick your noisiest workflow. By noisiest, it could be the most expensive, something you yourself dread, or something your team doesn't look forward to. And ask: is it still serving its purpose?"

「如果只让我留给你一件可以带回去做的事:挑出你最『吵』的那个工作流(noisiest workflow)。所谓最吵,可能是最昂贵的、是你自己最怵的、或者是你的团队最不期待的那一个。然后问:它还在服务于它的目的吗?」

"Another funny story: there was a team I was on where we had a weekly review — very expensive, like 50 people in a large room. And I noticed everybody's on their laptops, except when it's their turn to give a status report — they pop their head up, say the status, and go back down. I'm like, this is a very expensive meeting. I just asked the simple question: why are we having it? And just that one question — everybody's like, yeah, it's true. So we canceled it."

「再讲个好笑的故事:我待过一个团队,我们有个每周评审会——非常昂贵,差不多 50 个人挤在一个大房间里。我注意到所有人都在低头看自己的笔记本,只有轮到自己做状态汇报时,才把头抬起来,报一下状态,然后又低下去。我就想,这是一个非常昂贵的会。我只问了一个简单的问题:我们为什么要开这个会?就这一个问题——所有人都说,对啊,确实。于是我们就把它取消了。」

"So that's why it's always important to think. This might be something fun to take back: what's one piece of workflow you might consider — can you either automate it, or is it still serving its intended purpose? And with that, that's the end of our talk. Thank you."

「所以,持续地去思考永远很重要。这也许是个可以带回去做的有趣练习:有哪一段工作流是你可以考虑的——你要么把它自动化,要么问问它是否还在服务于它原本的目的?那么,我们的演讲就到这里。谢谢大家。」