Anthropic Reshapes Engineering Norms to Solve AI Code Glut

Anthropic重塑工程规范以应对AI代码过剩 当AI消除了编码瓶颈，传统的敏捷与瀑布方法论便不再适用，组织必须放弃长期规划，转向自动化验证与即时原型制作。 演讲指出，鉴于Claude Code等AI工具已消除作为软件开发首要瓶颈的工程吞吐量问题，组织必须将重心转向验证、审查与维护等下游挑战。Claude Code团队已放弃长期路线图规划，转而采用即时（Just-In-Time）规划，用快速构建原型的Pull Request取代抽象的白板争论，并高度依赖高置信度的自动化测试。此外，传统的团队角色界限正日益模糊，招聘重点转向平衡富有创造力的产品构建者与深谙底层的系统专家，他们利用AI处理跨职能任务。最后，演讲鼓励工程管理者保持扁平的组织架构，大力推行产品内部试用（dogfooding），并持续审查和淘汰过时、繁杂的工作流程。 软件工程的核心瓶颈已从编写代码的吞吐量转移至下游的验证、代码审查与维护，团队需主动清理和淘汰不断堆叠的陈旧流程。 (4:51) 团队放弃了快速过时的数月长期规划并转向即时规划（JIT planning），技术争议也转由让 AI 快速生成多套原型 PR 进行具象化评估，替代抽象的白板辩论。 (8:28) 研发模式全面转向自动化测试左移（Shift-left）并大幅削减设计文档，同时借助 AI 自动检索业务上下文与追溯代码回归，重新定义了代码所有权。 (10:41) 工程团队招聘重心从纯编码速度转向“具备产品品味的创意构建者”与底层系统专家；过去四个月该团队近 100% 的代码提交均由 AI 辅助完成。 (15:40)

Anthropic's Fiona Fung argues that because AI tools have eliminated raw coding throughput as software engineering's primary constraint, organizations must replace legacy planning and development rituals with rapid prototyping, shift-left automated verification, and targeted human oversight. Shifting Bottlenecks from Coding to Verification (4:51) For decades, software development methodologies like Waterfall and Agile were designed to optimize scarce engineering bandwidth. Fung asserts that with tools like Claude Code, authoring, refactoring, and test generation are no longer the bottleneck. Instead, the constraint has moved downstream to verification, code review, and long-term maintenance. When organizations fail to recognize this shift, they risk accumulating competing processes and service level agreements (SLAs) that quietly stop functioning. To counter this, Fung's team has reduced pre-implementation artifacts like formal design documents and product reviews. Development instead prioritizes early prototyping and shifting verification left through automated testing. High-confidence automated verification becomes essential as code throughput accelerates and non-traditional contributors, such as designers and product managers, begin shipping changes. Furthermore, traditional concepts of code ownership change: rather than relying on git blame to identify authors, teams can automate regression tracing, context gathering, and user feedback summarization using AI routines. Just-in-Time Planning and Code-Driven Debates (8:28) Because rapid AI prototyping makes planning assumptions obsolete quickly, Fung's organization abandoned long-term, multi-month roadmaps in favor of Just-In-Time (JIT) planning. An initial six-month roadmap Fung requested upon joining Anthropic became outdated within three months due to fast-moving AI capabilities, reinforcing a preference for immediate building over prolonged speculation. This dynamic also alters technical disagreements. Instead of debating architectural choices abstractly on whiteboards, engineers generate multiple concrete pull requests (PRs) via Claude to compare implementations and downstream API impacts directly. Fung notes that when implementation becomes cheap, prolonged debate becomes the more expensive activity. However, she cautions that this practice requires high cultural alignment to avoid an unhealthy dynamic where engineers race to submit late-night commits simply to win an argument. Evolving Team Roles and Specialized Systems Hiring (15:40) As AI expands individual capabilities, cross-functional responsibilities are blending. Fung observes engineers using AI as an ad hoc content designer for constrained terminal interfaces, while product managers regularly commit production code. Consequently, Fung de-emphasizes raw coding speed during hiring, viewing throughput as an augmented baseline rather than a differentiator. Instead, hiring on the Claude Code team indexes heavily on two profiles: creative generalists with sharp product sense who can identify problems and iterate rapidly, and deep systems specialists. Fung notes that while AI models easily assist product features, specialized distributed systems expertise remains essential for architecting complex, remote execution infrastructure. Human-in-the-Loop Reviews and Process Pruning (13:53) The Claude Code team practices a 'trust but verify' approach to review. Claude operates as a PR caretaker by managing styling, linting, generating initial tests, and addressing surface-level feedback before commit. However, Fung stresses that human judgment remains indispensable for security trust boundaries, legal compliance, and subjective product taste—such as catching flawed ASCII terminal art that AI fails to evaluate aesthetically. Operationally, Fung advocates for flat hierarchies, requiring engineering managers to start as individual contributors to maintain technical context through heavy dogfooding. Teams are given explicit permission to kill outdated rituals; for example, status meetings were replaced with spreadsheets and then automated Claude stand-up scripts. While virtually 100% of the team's commits over four months were AI-assisted and PR cycles shortened, Fung cautions that faster cycles often expose secondary bottlenecks in CI/CD systems, and teams must measure success by product quality rather than raw code volume. Fung challenges engineering leaders to audit their costliest, most bureaucratic processes and discard those that no longer serve their original purpose. Unresolved operational questions remain, including the optimal boundary for automated code review and whether platform-specific team silos, such as separate iOS and Android divisions, remain necessary as AI enables engineers to work across unfamiliar codebases.

Anthropic 的 Claude Code 与 Cowie 团队负责人 Fiona Fung 指出，随着 AI 使得代码生成成本大幅降低，软件工程的核心瓶颈已从编码吞吐量转移至验证、代码审查与维护。企业不能再沿用过去针对稀缺工程资源制定的流程，必须全面重构规划方式、人机分工与组织规范。 即时规划与代码原型的决策机制 (8:28) Fung 指出，敏捷与瀑布等传统软件流程原本是为了优化稀缺的工程带宽而生；而在 Claude Code 时代，编写与重构代码的速度极快，导致长达六个月的技术路线图在三个月内就会失效。因此，团队转向类似即时编译的“即时规划”（JIT planning），放弃冗长的前期设计文档，通过快速构建原型来验证可行性。在架构争议的处理上，团队不再在会议室白板前展开抽象辩论，而是利用 Claude 快速生成多个代表不同方案的具体拉取请求（PR），直接对比具体实现及其对下游 API 的影响。Fung 强调“当构建极其廉价时，争论反而是昂贵的”，但这种模式也依赖互信的团队文化，以避免演变成靠深夜突击提交 PR 来强行胜出的竞争。 验证左移与代码库单一事实来源 (10:41) 在高吞吐的代码生成环境下，Claude Code 团队大幅削减了设计文档和前期评审，转而全力推进“验证左移”，通过高置信度的自动化测试在代码源头捕获缺陷，以减轻高频变更带来的回归隐患。针对 AI 深度参与下的代码所有权模糊问题，团队不再依赖传统的责任人追溯（git blame），而是利用 AI 自动化完成缺陷归因、上下文提取以及客户反馈摘要。此外，团队将代码库本身视为终极事实来源，工程师通过在本地运行桌面版 Claude 直接检索代码库来解答客户支持问题，从而避免了静态文档与快速演进的代码脱节；团队还建议将产品规范直接检入代码仓库，便于 Claude 验证代码执行是否符合规格要求。 人机审查边界与产品审美价值 (13:53) 在代码审查环节，团队采取“信任但验证”（trust but verify）的标准。Claude 能够高效承担基础的代码照管工作，包括代码风格排查、编写单元测试以及拦截浅层缺陷；但在涉及高风险架构、法律合规以及系统安全信任边界时，仍必须由人类专家严格把关。此外，人类的产品直觉与审美依然不可替代。Fung 举例称，团队此前尝试用终端 ASCII 艺术将 Claude 装扮成节日雪人，但因模型早期的 ASCII 绘图能力不足，被设计师调侃为“像花生先生（Mr. Peanut）”，最终只得推翻并改由人类设计师选定典雅的冰蓝与雪花主题。这表明关键的用户体验设计仍需人类品味进行纠偏与把控。 团队画像重塑、跨职能融合与深度试用 (15:40) 随着 AI 放大个人效能，团队在招聘时的重心不再偏向纯粹的编码产出，而是聚焦于两类关键画像：一类是具备敏锐产品直觉、擅长快速试错的“创意构建者”；另一类则是能够掌控底层远程运行架构的“深层分布式系统专家”。同时，AI 正在模糊传统角色边界，工程师能够利用 Claude 协作撰写紧凑的终端文案，弥补内容设计短板，而产品经理等非技术角色也开始常规提交代码。在管理结构上，团队倡导扁平化，摒弃严格的管理者与下属配比，并推行极致的内部试用（dogfooding）。该团队要求所有工程管理者必须先作为独立贡献者（IC）入职编码以建立威信，而 Claude 抹平了内部工具与 Git 操作的复杂摩擦，使管理者能长期紧密参与一线开发。 流程淘汰机制与效能度量维度 (21:02) 团队推行“尽可能 Claudify 一切”的准则，并确立了“淘汰旧流程的明确权限”，定期评估各项规范是否仍有存在价值。例如，团队逐步将传统的日常站会演进为共享表格，最终替换为由 Claude 脚本自动汇总与分发进展，同时赋予各个子小组在排班和分流上的自主权。在效能度量方面，团队主要跟踪三项指标：新员工（含工程师、设计师与 PM）的入职磨合期大幅缩短；PR 周期时间显著减少（但也暴露出 CI/CD 系统吞吐能力的新瓶颈）；以及近四个月内 AI 辅助提交的比例已近乎 100%。Fung 提醒，度量成效切忌单看 AI 生成代码的比例，而应始终以终端质量、可靠性与用户体验为核心标准。 Fung 总结指出，团队仍在探索前沿组织边界，例如跨平台 AI 工具是否会打破 iOS 与 Android 团队的物理区隔，以及随着模型能力提升，自动化审查与人工监督的平衡边界该如何动态推移。她建议各团队主动审查并剔除内部成本极高且流于形式的“高噪音工作流”（noisy workflow），勇于停办无意义的大型评审会议，促使工程机制与现代开发工具的能力相匹配。

[0:03] Fiona Fung: what served you prior may not serve you any longer. [4:51] Fiona Fung: is this code correct? [4:51] Fiona Fung: who reviews this code? [4:51] Fiona Fung: how is it maintained? [4:51] Fiona Fung: who wrote this? [8:28] Fiona Fung: When building is cheap, arguing is expensive, [8:28] Fiona Fung: last person to check in wins [10:41] Fiona Fung: Did I just cause a bug? [10:41] Fiona Fung: who made this change? [13:53] Fiona Fung: trust but verify [13:53] Fiona Fung: babysitting PRs [14:48] Design partner: You turned Claude into like the Mr. Peanut character. [15:40] Fiona Fung: creative builders with product sense [15:40] Fiona Fung: deep systems expertise [17:55] Fiona Fung: earn some street cred [21:02] Fiona Fung: Claudify everything you can [21:02] Fiona Fung: explicit permission to kill old processes. [25:51] Fiona Fung: why are we having it?

[0:03] [music] [0:08] >> Hey folks, do y'all hear me okay? [0:11] Okay, I I I swear this is not a Claude [0:14] Code thing, but do you guys mind if I [0:15] take a photo? Cuz cuz Boris and Jared [0:19] had their session at 2:00 and I really [0:20] thought this was going to be empty. I'm [0:22] like, there is just no way people would [0:23] still be coming in from that session. [0:25] So, [0:26] Oh my gosh. [0:28] >> [screaming] [0:29] >> Thank you, prompt. I promise me and [0:30] Boris don't just do selfie words all the [0:32] time. [0:33] >> [laughter] [0:34] >> But good afternoon and thanks for [0:36] attending. So, yeah, my name is Fiona [0:37] Fung and I lead Claude Code and Cowie [0:40] engineering and product. So, I work [0:42] really closely with Boris and Cat. And [0:44] before Anthropic, I had led and grown [0:46] teams at Meta and then also Microsoft. [0:52] And so, for today's talk, this is kind [0:54] of like overall agenda, but the whole [0:56] idea is what are some of the lessons I [0:58] learned and helping Claude Code and [1:01] Cowie kind of like grow and as we're [1:02] building out this team. And kind of like [1:05] what things I and it's it's interesting [1:07] as lessons I learned even if I think [1:08] about my time at Meta or even Microsoft, [1:11] but even Anthropic. Like it's funny, I [1:13] did this slide deck maybe like a month [1:14] ago and also already I've had to change [1:17] some of the content cuz for example, [1:19] when I started this deck, there were no [1:21] routines and that even like that way of [1:23] working was different for me. [1:24] And so, yeah, like we really want to [1:26] like I want to kind of cover five themes [1:28] that I've noticed. One which is the [1:31] bottlenecks have moved, they've shifted. [1:33] And so, when bottlenecks shift, what are [1:36] then some of the team norms that we had [1:37] to rewrite within the Claude Code team? [1:40] I also wanted to share a little bit [1:41] about all these team norms we had to [1:43] rewrite, how we rolled them out, and [1:45] also what are some of the proof as some [1:47] of the you know, like some some signals [1:49] that I get of well, yeah, we're trending [1:51] in the right direction. And it's always [1:53] going to be important for me to kind of [1:55] look at to see is it still serving us, [1:56] trending in the right direction? And [1:58] then I'll end it with a few kind of like [2:01] questions that I still have for myself, [2:03] and then also some suggestions for you [2:05] to maybe take an action and embark uh to [2:07] your teams to have conversations [2:09] together. [2:11] So with that, the first section, the [2:13] bottlenecks have moved. I call it the [2:16] shift. But you'll probably hear me [2:17] repeat this kind of subtitle text a lot, [2:20] which is what served you prior may not [2:22] serve you any longer. And when actually [2:24] even when I think about all my [2:25] experience, whether it was like at [2:26] Anthropic or Meta or Microsoft, the [2:29] constant growth mindset is just a muscle [2:32] that has served me really well. And [2:33] especially right now when the rate of I [2:35] don't know if y'all are feeling it, the [2:36] rate of change is just a little bit [2:38] crazy, right? Like I remember the first [2:40] time I started doing some live coding [2:42] was last year, and it was still making [2:44] some some, you know, bugs that I'm like, [2:45] "Ah, why why are you using constants [2:47] everywhere? That's not good engineering [2:49] practice." And now it's it's, you know, [2:51] just become so much more capable. But [2:53] that's that's what I I'm seeing as this [2:55] interesting shift of when the [2:56] bottlenecks moved, how do you think [2:58] about adapting uh in terms of everything [3:01] else around that bottleneck? [3:03] So maybe y'all are feeling this too, but [3:05] like for years engineering bandwidth was [3:08] the expensive thing. Like coding [3:10] throughput was really expensive. And [3:12] when you think about all the processes [3:14] we have of shipping software, a lot of [3:16] it was around Hi, welcome. There's a [3:18] chair. Take away those reserved tags. [3:20] There's no one sitting. [3:23] >> [laughter] [3:23] >> And there's another one right here, sir. [3:25] Welcome. Um but yeah, like all of that, [3:28] like even when you think about how we [3:29] used to do planning, like remember we [3:30] used to do like waterfall and then [3:32] agile, everything was used to be because [3:34] engineering bandwidth was really [3:36] expensive. Actually, I'll take a little [3:37] segue here. [3:39] This is not the first time our Like when [3:41] you think about our industry, we've [3:42] always had to adapt. Like I'm going to [3:44] put you all in a time machine. Come back [3:47] with me all the way to the year 2000s. [3:49] That was when I started my career. I [3:51] worked on Visual Studio, and we were [3:53] shipping Visual Studio 2005. [3:56] And I kid you not, in those days, if [3:57] folks remember, we used to ship software [4:00] on like CD-ROMs. Before CD-ROMs, it was [4:02] actually floppy disk. And so, I still [4:04] remember VS 2005, there were really hard [4:06] deadlines. We had to hit those deadlines [4:08] cuz we had to get the software to the [4:10] manufacturing lab to print on the CDs, [4:12] to put in the boxes, to ship in the [4:14] stores. And so, when you when you even [4:16] think about that, when we were able to [4:17] distribute software online, that also [4:20] changed how we ship software. And so, [4:22] that's what I'm finding really [4:23] interesting of this this new, you know, [4:25] shift that I'm seeing is engineering [4:27] bandwidth. It's no longer the expensive [4:29] thing. [4:31] So, for example, on the Cloud Code team, [4:33] for sure, coding is rarely the slow part [4:36] anymore. [4:37] Um and I would say it's not even that [4:39] it's not the slow part, it's just also [4:41] the throughput has really, really [4:43] increased. So, it's not only like, "Yay, [4:45] we're all all getting to build more." [4:46] It's just the amount that we're [4:47] generating has also changed a lot. [4:51] And so, what we saw was, you know, when [4:53] your your bottleneck shifts from kind of [4:55] the coding and the actual act of typing, [4:57] like if you remember, it used to be [4:59] writing code was expensive or writing [5:01] tests or refactoring. I remember all of [5:03] these conversations of, "We have to [5:05] schedule some time to do refactoring. [5:07] Oh, but we have to do product work, and [5:08] this is expensive. When are you going to [5:10] find that time to do it?" All of that [5:12] has shifted now. That is no longer the [5:13] bottleneck. And so, when that happened, [5:16] sometimes I notice the bottlenecks end [5:18] up shifting towards other areas. [5:21] And so, what happened? Like, for [5:22] example, verification, review, [5:25] cross-functional partners, security. [5:27] Because coding is no longer the [5:28] bottleneck, and also we're doing so much [5:31] more of it, these are some of the new [5:33] bottlenecks that we're seeing. So, it's [5:34] really always us asking, "Is this code [5:36] correct? Who reviews this code?" That's [5:38] like probably one of the top questions I [5:40] get from all fellow end leaders. Like, [5:42] "How are humans keeping up with how you [5:45] guys are doing like code reviews. [5:47] And interestingly, also how is it [5:49] maintained? Because now it is also a lot [5:52] easier for us all to generate a lot of [5:53] code. So also thinking about that [5:55] maintenance cost, too. [5:59] So with that, these were some of the [6:00] processes that I noticed quietly stops [6:03] working. And I love that phrase quietly [6:05] stops working cuz I don't know if you [6:07] all like a lot of times we all put in [6:09] processes hopefully for a reason, right? [6:11] Like we're thinking, "Hey, there was a [6:12] gap here or we want to improve." But [6:15] what I've found over the years is rarely [6:16] do processes kill themselves. We tend to [6:19] just layer more and more and more [6:21] processes on. Like I remember that on [6:23] one team, we had so many SLAs. Like [6:25] there was a P0 bug SLA, a high pri- like [6:28] sub review instead of like Anyways, [6:30] there's so many SLAs. After a while I'm [6:32] like, "Oh no, we need to stack rank [6:33] priorities so that all the engineers [6:35] knew which SLA was going to be even more [6:37] important." And I remember even at that [6:39] time I thought, "Hey, we should start [6:41] thinking about what things we should [6:42] defrag a little bit." But um yeah, so [6:45] these are the processes that might have [6:47] served you. Do you remember again is [6:48] that line of what may have served you [6:50] may not serve you any longer. But like [6:51] the planning norms. We used to spend a [6:53] lot more time, you know, pre-planning [6:55] because coding time was expensive. Uh [6:58] code ownership, there used to also be a [6:59] lot of questions of who who who wrote [7:01] this code? Who owns it? That's a little [7:03] bit of an other question now. Uh code [7:05] reviews what we'll get into a little [7:07] bit. [7:08] Team makeup is interesting, too. It's [7:10] not only like roles are blurring, right? [7:12] Like so between like engineers can also [7:15] So now now have AI to help augment [7:17] non-engineering roles. My [7:19] non-engineering partners are also all [7:21] shipping code. So what happens when [7:23] roles start blurring and you don't have [7:24] those, you know, like the silos anymore? [7:28] And then that also goes to knowledge [7:29] share. Knowledge sharing and onboarding [7:31] and everything is another signal that [7:33] we're noticing at Cloud Code how we used [7:35] to do things change a little bit, too. [7:39] And so, you know, in the first section [7:40] we talked about the shift. So, within [7:43] the Cloud Code team, what are some of [7:45] the norms that we have to rewrite? So, I [7:47] want to share some of those with you and [7:48] then, you know, hopefully some of them [7:49] will resonate with you or you might find [7:51] helpful. [7:53] And so, number one is code review. Uh [7:56] like human judgment of like who actually [7:59] needs it and we'll kind of go through [8:01] all of these, but you know, like the [8:02] onboarding is also changed, how we do [8:04] planning, you heard about me talk about [8:05] like planning a lot, hiring, especially [8:08] with roles blurring and kind of team [8:09] makeup how that has changed for us, too. [8:12] And also org shape, that's kind of one [8:14] of my favorite spicy topics. I'll share [8:16] that story with y'all when I start [8:18] proposing that at Anthropic. I love my [8:20] recruiting partners, they're awesome, [8:21] but I remembered, you know, one [8:23] recruiting partner really did think I [8:24] was crazy. Um so, I want to share that [8:26] with y'all, too. [8:28] So, how have planning changed? But also [8:30] technical debates. [8:32] Planning, we do a lot less of it. Like I [8:34] would also say and also the timing, I [8:36] call it like JIT planning, almost like [8:38] JIT compiling because even when I first [8:40] joined, I'm like, "Don't we need a [8:42] six-month roadmap?" And we, you know, we [8:44] put some effort in, we wrote it, it was [8:45] pretty good for three months, and then I [8:47] came back over the new year and and so [8:49] many things had changed already. So, I [8:51] realized well, six-month roadmap just [8:53] seems like a little bit too long. So, [8:55] again, it's how do you make sure you [8:57] kind of like do just the right amount in [8:59] the right time because again, [9:00] prototyping and code generation is just [9:02] not the bottleneck that it used to be. [9:05] The technical debate one is a fun one, [9:07] too. [9:08] So, in technical debates, code wins. [9:11] I'll share with y'all when I first [9:12] joined the Cloud Code team, I wanted to [9:14] do a refactoring. I wanted to like get [9:16] to learn about the code base. And me and [9:18] Boris had a healthy technical debate of, [9:20] you know, which which way to go, and I [9:23] almost leaned into my old toolbox. I [9:25] almost tapped him on the shoulder to go, [9:27] "Let's go to that room and have a [9:29] whiteboard and we can and I'm like, wait [9:31] wait wait wait wait a minute. Nowadays, [9:33] I can just generate all the different [9:35] options we've been discussing. I [9:36] generated three PRs. And the cool part [9:39] about that for the technical debate is I [9:42] really cared not only about the [9:44] implementation of the API, but also the [9:46] impact to all the callers into the API. [9:49] And so when I can have Claude help me [9:51] generate the three different versions, [9:52] it allowed us to have a debate of not [9:54] only implementation, but also impact to [9:56] the colleagues. So I think that's [9:58] another really interesting kind of [10:00] pivotal change. Um so yeah, like you [10:02] know, when building is cheap, arguing [10:05] expensive, again, how does that shift [10:06] your team norms a bit? I do want to call [10:09] out this makes it even more important to [10:11] make sure you set up team culture for [10:13] how you think about alignment. For [10:15] example, what totally won't fly is [10:17] because code is, you know, so much [10:19] faster for us to generate, it shouldn't [10:21] be like the last person who check in [10:22] wins, you know, like I'm going to stay [10:24] up at 3:00 p.m. to submit this PR. I set [10:26] up a routine so that I get the last word [10:28] in. So definitely a no-no. That makes it [10:30] even more important to make sure you [10:32] have good team culture that can have [10:33] open, honest technical debates, but also [10:36] a good team alignment. [10:41] Uh so I talked a lot about kind of what [10:43] we reduce in in planning. On Cloud Code, [10:46] we definitely have reduced the design [10:48] doc before every code ritual. I would [10:51] say certain teams and for definitely [10:52] certain scenarios it's still really [10:54] important to think about design docs, [10:56] especially as we're doing like kind of [10:57] like async discussions. But on Cloud [11:00] Code, most of our discussions is like [11:02] instead of a doc, a PR. That's kind of [11:04] like one of the word we have of "Hey, we [11:06] found an idea, go prototype." That's the [11:08] other thing. We don't really do a lot of [11:09] product reviews because the landscape is [11:11] changing fast. So let's prototype, let's [11:13] actually get a lot of internal ants [11:15] using it, and I'm really a big fan of [11:17] shipping it out to all of you, and then [11:18] hearing all the excellent feedback so [11:20] that we can really And And again, like [11:22] that that has changed our planning [11:24] ritual to be a lot less design docs, and [11:27] mostly discussions are in PRs or [11:29] prototypes. [11:30] Um so we reduced that, but what did we [11:32] double down on? And I think this is an [11:34] area where we actually need to do more [11:36] and continue to being better, it's the [11:37] verification. Cuz again, it's like the [11:40] throughput is different. Um, and there [11:42] are new ways to break. So, how can you [11:44] scale out? And I call it kind of shift [11:46] left. Like in the old days, you would [11:48] get code out and and I would love to for [11:50] me to find bugs before any of you find [11:52] it. And what's better than me finding a [11:54] bug is actually what I call shift left, [11:56] like more more automation, so we catch [11:58] it earlier to the source. So, that is [12:00] something that I think we need to [12:01] continue to double down on. And the [12:03] other thing that's interesting is also [12:05] because roles are blurring. For example, [12:07] my designers like I would love to have [12:09] more confidence that when I checked in [12:11] this code, I don't break something. Like [12:13] I remember it, I fixed a I fixed a bug [12:15] in resume or something and the next day [12:17] I was catching up on Boris's, you know, [12:19] threads and I saw someone tag him up, [12:21] "I'm noticing a bug." I remembered [12:23] having that sinking feeling. I don't [12:25] know if y'all have ever like [12:26] Did I just catch a bug? Like so because [12:29] of the throughput like I just really [12:30] want to make sure everybody, regardless [12:32] of roles, just has a lot higher [12:34] confidence um for the change that [12:36] they're putting in. [12:38] Who made this change? And so my advice [12:41] here is again, because a lot all our all [12:43] our PRs are assisted by Claude, it's a [12:45] little bit of an odd question. And so [12:47] for us, what is more helpful than just [12:49] that question is what I call like double [12:51] clicking into it. Like so in the old [12:53] days, when you used to ask, "Who made [12:54] this change?" What question are you [12:56] really trying to answer? Are you looking [12:57] for who caused this regression? [12:59] Definitely don't want to blame, but just [13:01] want to know who was the last person [13:03] that touched this code that might have [13:04] caused this break. Or are you looking [13:06] for an expert to answer customer [13:07] question? Or are you looking to gain [13:09] context? So, whatever is that double [13:11] click question, also think about is [13:13] there a way you can automate. It's [13:15] funny, I mentioned that to change this [13:16] slide deck. When I started this talk [13:18] about a month ago, part of my every [13:20] morning is I would, you know, bring up [13:21] my desktop code and go into here's a [13:23] customer feedback channel and I kind of [13:25] want to ask it to summarize and and that [13:27] was just a morning ritual I would do [13:28] with my morning cup of coffee. Now it's [13:30] routines, right? Like I can set that up [13:32] and then even better than what I had [13:34] done before, which was how I kick it [13:35] off. I'll be like, with my morning cup [13:37] of coffee, I always get to kind of a [13:39] pretty good overview. So that's my point [13:42] of like code ownership is a little bit [13:44] more fuzzy, but on the flip side, double [13:46] click to what question you're really [13:47] trying to answer and seeing how Claude [13:49] can actually help you with those. [13:53] How do you keep up with code reviews? So [13:55] I'm really glad if y'all saw uh the [13:57] keynote this morning, Kat talked about [13:59] it. We definitely leverage heavily [14:02] Claude code review. Now what's [14:04] interesting is going to be where do you [14:06] trust Claude like a lot, [14:08] but then where do you still want a [14:09] human? [14:11] And so for sure like, you know, and [14:13] actually Claude also, as Kat showed [14:14] y'all the the Claude also does a great [14:16] job babysitting PRs. And so we [14:18] definitely have Claude handle all the [14:20] styling and lint and PR feedback [14:22] requests, even like maybe catching some [14:24] bugs and fixing them before it even uh [14:27] does a full commit. And also uh adding [14:30] tests. That's what like really what [14:31] we've leaned heavily into Claude for. [14:34] But where I still definitely want a [14:35] human is that expertise. It's all about [14:37] trust but verify. So for example, legal [14:40] review, I always definitely want to make [14:42] sure I'm getting my legal partner still. [14:44] Uh it's you know, like risk tolerance. [14:46] So for example, trust boundaries and [14:48] security sensitive code, I still want to [14:49] make sure I'm pulling in the experts. Um [14:52] the other area which which is kind of [14:54] fun is also that product sense and [14:56] taste. Like I remember one of the hobby [14:59] like one of the fun things I like to to [15:00] use Claude for is that I like to [15:02] decorate Claude for the holidays or the [15:05] seasons. And I remember last uh holiday, [15:08] I wanted to update Claude in the [15:09] terminal to, you know, give him a little [15:11] holiday theme. And I asked Claude code [15:14] to you turn Claude into a snowman. [15:16] Claude wasn't that good at ASCII art in [15:18] those days. And I remembered asking, [15:20] that's where product sense really comes [15:21] in. I asked my design partner, "Hey, can [15:23] you review this for me?" And she gave me [15:25] such good feedback. She's like, "You [15:27] turned Claude into like the Mr. Peanut [15:29] character." Cuz I was trying to [15:31] make him snow match. I was like, "Okay, [15:32] I'm going to do something more simple." [15:33] So, Claude was like ice blue with [15:35] snowflake, but keep in mind kind of that [15:37] product sense as well. [15:40] Which leads me to what should my team [15:42] makeup be? Because roles are blurring, [15:45] Claude is augmenting. [15:47] I'll share with you on Claude Code, [15:48] there's two profiles for engineers that [15:50] I'd really heavily indexed on. One are [15:52] like creative builders with product [15:54] sense. Usually, you'll see these are, [15:56] you know, the dreamers. There will be a [15:57] big sense of curiosity. They're really [16:00] passionate about, "Oh, here's a problem. [16:01] Here's a Maybe I could, you know, ship a [16:03] product that solves that problem." But [16:05] then there'll be a lot of iteration to [16:06] make sure you're delivering a delightful [16:08] experience. Um the other one is deep [16:10] systems expertise. So, when I first [16:12] joined Claude Code team, I noticed [16:14] actually we were pretty good with [16:16] product generalists and creative folks, [16:18] but we were missing folks with like [16:19] distributed systems expertise. And when [16:21] you're building things like Claude Code [16:23] remote to ensure we can run Claude's [16:24] everywhere, you really still need um [16:27] those expertise. So, I would say, you [16:29] know, whichever software engineering [16:30] lead you're part of or or supporting, [16:32] think about those hard parts of where [16:34] you might want to continue to still [16:36] double down. But for sure what I index [16:38] less on is raw throughput because thanks [16:41] to the models, we just saw a lot more uh [16:43] efficient. [16:45] The cross-functional gaps is another [16:47] interesting one. So, for example, I [16:49] remember that I wanted to do an update [16:51] to how we do survey responses, but I [16:53] didn't have a dedicated content designer [16:55] to work with me. And I'm a engineer, my [16:58] writing skills are quite terrible. I I [17:00] struggle to write things in a short and [17:02] succinct form. I don't want the surveys [17:04] to like, you know, overload you all in [17:06] the terminal of cuz every line space is [17:08] really important. But that's where [17:10] Claude, like in the old days I would be, [17:12] "Who is a group of content designer I [17:14] can work with?" And I can can of changes [17:16] back and forth. But now Claude has [17:18] really helped me to augment that role [17:19] and was a really good content design [17:21] partner for me to kind of like make sure [17:23] the verbage is is good and succinct. And [17:27] on the flip side, like I say a PM our PM [17:29] code a lot, which is really fun to see. [17:31] So again, like I I would say with Claude [17:33] like you have non-traditional coders now [17:36] being able to do more engineering, but [17:38] you also have engineers that we can also [17:40] now lean in to do things that was [17:41] traditionally, you know, like not on the [17:44] technical side but more of where the [17:45] content or design. So it's very [17:47] interesting. I found that Claude and AI [17:49] has really augmented roles kind of like [17:52] all around. [17:55] This was a spicy one. Uh [17:57] so I'm definitely like I remember when I [17:58] first joined Claude Code everyone's [18:00] like, "Okay, you're going to grow the [18:01] team by certain amount." and I could [18:02] tell recruiters were still using the [18:04] typical, you know, 10 ICs to one manager [18:07] and then how do you start think about [18:09] nesting? Um I really have leaned into [18:11] keeping it really scrappy. And actually [18:13] maybe I would step back to whether it's [18:15] at Anthropic or Meta or Microsoft, [18:18] whether it was like Visual Studio or [18:20] Facebook Marketplace or AR/VR devices or [18:23] Claude, like what I have found to really [18:25] help me ship great product is heavy [18:27] heavy heavy dogfooding. Especially for [18:29] leaders where nowadays it's actually [18:31] fun. I can still be in the code, but for [18:33] a while it wasn't. And when you can't [18:34] get your hands on the code, I would [18:36] always make sure I would make your time [18:38] so that I'm actually using my product [18:39] days in days out. And so that's why I [18:42] wanted every manager in Claude Code to [18:44] start out as an IC first. And also like [18:46] earn some street cred with the team and [18:48] and really learn how to be an effective [18:50] engineer. [18:51] Uh and and then I really structured the [18:53] org to be as flat as possible cuz I want [18:55] us to be super agile. This was just my [18:58] my recruiters had some concerns cuz I [19:00] remember they said, "You want to hire [19:02] managers and they will start as an IC [19:04] first. No manager would be interested in [19:06] that." I'm like, "Well, this is what [19:07] dogfooding on the Claude Code team's [19:09] about. And this is what I expect. And if [19:11] someone's not interested, it's better [19:13] for us to do uh earlier separation. But [19:16] also again, this is like there's no way [19:18] I would have been able to ramp or be [19:20] able to do code cuz my time is, you [19:22] know, there's just a lot of context [19:23] switching without Claude. And so for [19:25] those of you in the room who are [19:27] managers, I really, you know, like [19:29] encourage y'all to kind of like lean in. [19:31] It's I'll I'll be honest for for a long [19:33] time at Meta, I would still try every [19:34] year to do one PR a year just to but the [19:38] the code the the workflows would always [19:40] change. Like I all the internal tools, [19:42] like by the time I learn one command, it [19:43] would have changed. Nowadays, I don't [19:45] even remember get commands. I just [19:47] always ask Claude to to help me out out [19:49] with all of that. [19:52] Now with sharing, what becomes your new [19:54] source of truth? [19:56] So for example, on our team on Claude [19:58] Code, the code is the source of truth. [20:00] That's why I would go back to when I'm [20:01] like answering customer requests. I just [20:03] have my desktop Claude with desktop [20:06] Claude Code and then I have all my, you [20:08] know, like local repository so actually [20:10] answer a lot of customer questions. So [20:12] for us, just having that code base be [20:14] the source of truth also like prevents [20:16] some of the lag that you might have had [20:18] before of how to keep up the [20:19] documentation, you know, correct with [20:21] the code. But I would say this is where [20:23] it's like do what makes sense for your [20:24] team. So for example, if you still have [20:26] a lot of really good specs, check those [20:28] into the repositories and then have [20:30] Claude lean in to help, you know, like [20:32] hey, you know, like take a look at how [20:33] verify my code execution so matches what [20:36] I expect on the spec. [20:40] And so how did we roll it out? Cuz these [20:42] were like I had just gone through some [20:44] of the norms that we had changed. And I [20:46] think it's interesting, there's a blend [20:48] of what do we kind of like mandate as [20:50] team norms? Like make sure you're [20:52] gaining alignment with the team. And [20:54] then where do I really enable each, you [20:56] know, like we have pods within Claude [20:58] Code. Want to make sure I enable each [20:59] pod to do what makes sense for them as [21:01] well. [21:02] So in terms of the balance, in terms of [21:04] forcing function, it's align with the [21:07] teams on the must do. So, these are a [21:08] few of the core Claude code team [21:10] principles that we really live and [21:12] breathe. And by the way, if you remember [21:14] again, I I'll go back to that growth [21:15] mindset and always think about something [21:17] still serving you. We keep these up to [21:19] date. So, every few months, we'll be [21:20] like, "Hey, is this still having, you [21:22] know, the same effect or serving the [21:24] purpose that we wanted when we started [21:26] it?" So, for example, and I should [21:28] replace this slide. It's not every [21:29] engineer uses Claude code. You know, [21:31] that's obvious. It's actually every [21:33] Claude code team member, including [21:34] cross-functional partners. And actually, [21:36] we all use co-work quite a bit, too. [21:39] Uh Claudify everything you can. This is [21:41] one thing where we're like, "You know [21:42] what's better than one of us doing it? [21:44] Having Claude." So, always think about [21:46] Is there some way for you to automate, [21:48] whether it's verification, more shift [21:50] left, but always be thinking what you're [21:52] doing something right now? Is there some [21:54] way that Claude could actually help you [21:55] do it? [21:56] And the last one's my favorite, explicit [21:58] permission to kill old processes. Cuz [22:00] again, processes will kill themselves. [22:03] But as your supporting teams is really [22:05] important to always get that fast [22:06] feedback for your team of what are the [22:08] things that, you know, like are we spend [22:10] We're spending a lot of I'm actually I [22:11] remember when I first joined Claude [22:13] code, we used to do stand-ups. And then [22:15] the team got a little bit big, so then [22:16] we had a spreadsheet where we would all [22:18] put up our, you know, like weekly [22:20] process progress. And then I was like, [22:22] "Oh, wait, we should just do a [22:24] skill, right? like a a stand-up script. [22:26] So, then we can just run Claude and all [22:28] of us can always be very be much more [22:30] kept aware of what everybody else is [22:32] doing." So, that's just something [22:33] another example of one day I remember [22:35] spreadsheet Wait, "Does this still make [22:37] sense anymore?" So, always question and [22:40] always look to defrag and kill old [22:42] processes. [22:43] What I want to make sure that I leave a [22:45] lot of room for pods to adapt. It's For [22:48] each team really has a lot of high [22:49] agency for how, you know, they do triage [22:52] or leverage Claude to do triage, any [22:54] planning rituals or stand-ups, how they [22:56] think about on-calls, and also which [22:59] workflows to Claudify first. So, we [23:01] don't usually mandate thou shalt [23:03] automate this. We have some suggestions [23:05] and learnings, but always give room to [23:07] your team, especially they may be, you [23:09] know, touching on different problem [23:10] areas. [23:13] So, if I zoom out, what were the three [23:15] things I prioritize on, you know, I I [23:18] when I joined Cloud Code that I felt has [23:19] to make the biggest difference? Keeping [23:21] the team as flat as possible. [23:23] Um like managers release a pop pods of [23:25] work, but really keep it agile. So, for [23:28] example, on on Cloud Code and co-work, [23:30] we have one overall team mission. Cuz [23:32] sometimes when you start creating pods, [23:33] each pod then wants maybe to set up [23:35] their own mission, and then anytime you [23:37] have to shift, it might be take a lot of [23:39] time to to walk people through that, but [23:41] it's really as flat as you can. I felt [23:43] that served us really well. [23:45] The cloudify everything better than you [23:48] doing it. I see how Cloud can help you. [23:50] It really frees us up to do more of the [23:52] harder work. And again, the processes, [23:54] they do pile on. So, I encourage you to [23:56] kind of like work with your team to see [23:58] what are the processes that actually you [24:00] should be able to let go. [24:05] So, does it actually work? [24:07] I can't go into the explicit numbers, [24:09] but I think these are three general kind [24:11] of metrics that you can look at as [24:13] you're rolling out, you know, changes on [24:15] your team that might start steering you [24:16] to yeah, this seems like it's kind of uh [24:19] starting to be successful. The [24:20] onboarding ramp-up time that has [24:22] dramatically reduced. Uh so, that's an [24:24] interesting thing like like how soon an [24:26] engineer or a designer or, you know, [24:28] like a PM can start being effective on [24:30] your team. [24:32] Uh the PR cycle time shortening. I think [24:34] this one's interesting to double click [24:35] into a bit cuz it's it might actually [24:38] help you identify a gap that's not just [24:40] in terms of lack of AI adoption, but [24:42] where the rest of the pipeline might be [24:44] struggling to scale. So, for example, [24:46] again, as as we're now like, you know, [24:48] just putting in some through so much [24:49] more code, sometimes a product [24:51] infrastructure can build and CI still [24:53] keep up with the amount uh that [24:55] engineers are checking in. [24:57] Uh so, both of those should go down, but [24:59] then what should go up a little bit is [25:01] cloud-assisted commit. For example, for [25:03] us, it's by default every commit is [25:05] cloud-assisted. I don't think I've seen [25:07] a non-cloud-assisted commit probably in [25:09] the last 4 months or so. Um, but [25:12] hopefully these three things are are [25:13] kind of like metrics that you can kind [25:15] of take a look at at your team and see [25:17] how it resonates. I would also say [25:19] though, um, outside of just number of [25:22] commit, also think about the end goal. [25:24] Like if you zoom out, [25:25] what is the product that you're trying [25:26] to make more delightful for users? Or [25:28] what is the problem you're trying to [25:30] solve? Cuz sometimes you see it on all [25:31] the headlines of this company said X [25:34] percent of code is now generated by AI. [25:37] I think throughput is great, but really [25:38] think about how you measure what it is [25:40] that you're actually really trying to [25:41] solve. Like for example, we really want [25:43] to make sure we're keeping an eye on [25:44] quality and reliability, so those are [25:47] some of the things that we're paying [25:48] more attention to as well. [25:51] Okay, so the my last section is to audit [25:54] your own effort. I'll share with you [25:56] transparently, actually, I still have a [25:58] couple of questions that I'm still [25:59] asking myself. Um, the iOS and Android [26:02] org is a very interesting one. Like when [26:04] engineers can now more efficiently kind [26:07] of flex across different mobile [26:08] platforms, does a more traditional way [26:11] of, you know, uh, having an iOS team and [26:14] an Android team still make sense? That's [26:16] something that I'm still kind of [26:17] thinking through. How much do you push [26:19] that fully automated review? Again, like [26:21] when do you kind of strike that balance [26:23] between fast enough and we lost [26:25] something important? It goes back to the [26:27] trust but verify. And what's interesting [26:29] is you even might have heard today in [26:31] earlier during Danella's talk, the model [26:33] capabilities do keep improving. So also, [26:35] even if you might need to do more verify [26:38] than than trust for a certain section of [26:40] work, that might also change with the [26:42] next model. So it's why it's always [26:43] important to re-evaluate. And roles are [26:46] blurring, so how do you make sure that [26:48] everybody feels equally uh, productive? [26:52] So if I were to leave you with one, you [26:55] know, thing to take back of is, you [26:56] know, pick your noisiest workflow. And [26:58] by noisiest workflow, it could be most [27:00] expensive, what's something that, you [27:02] know, what you yourself might be [27:05] dreading, or even your team might not [27:06] really look forward to it. And ask, is [27:08] it still really serving what's the [27:10] purpose of there? Like, actually, I'll [27:11] share another funny story. There was a [27:13] team I was on where we used to have this [27:15] weekly review. It's a very expensive [27:17] review, like 50 people, you know, in [27:19] this large room. And then I noticed [27:20] everybody's on their laptops. Except for [27:22] when it's their time to give status [27:24] report, and then they they pop their [27:25] head up, say the status, and then go [27:27] back down. And I'm like, this is a very [27:29] expensive meeting. And I just asked that [27:31] simple question of why are we having it? [27:33] And just that one question, everybody's [27:34] like, yeah, it's true. And so we [27:36] canceled it. So, that's why it's always [27:38] important to to think. And And so, yeah, [27:40] like I I figured this might be something [27:42] fun for you to take back and look and [27:44] see what's one piece of workflow that [27:46] you might consider, can you either [27:48] automate, or maybe even is it still, you [27:51] know, proving is it still serving its [27:53] intended purpose. [27:56] So, with that, that's the end of our [27:57] talk. I'm like, thank you. [28:00] >> [applause] [28:01] >> Thank you. [28:03] Thank um thanks a lot for thanks a lot [28:06] for attending. I really, really for sure [28:09] thought this room was going to be empty. [28:10] So, thanks for not having by myself. And [28:13] I'm around here today and tomorrow. So, [28:15] if you have any questions or want to [28:16] chat more, feel free to introduce [28:17] yourself. I'm happy to chat. [28:19] Thank you.