Claude Code 工程一号位亲自给 Agent 热潮降温：狂烧 Token 时代已过，现在该算ROI了

在关于 AI 编程的讨论里，外界最常关注的是模型能写多少代码、工程师效率提升了多少、AI 是否会替代程序员。但在 Anthropic Claude Code 与 Cowork 团队负责人 Fiona Fung 看来，真正的变化已经越过了“代码生成”本身。 Lenny’s Podcast 这期对话提供了一个少见的内部视角：当一个工程团队的代码交付量在一年内被 AI 拉升到原来的 8 倍之后，软件工程的瓶颈并没有消失，而是转移到了别的地方。写代码不再是最稀缺的能力，验证质量、判断优先级、衡量真实产出、管理异步 agent、保持团队文化，开始成为新的难题。 Fiona 领导 Claude Code 和 Cowork 背后的团队，并监管 Boris Cherny 以及整个工程和 PM 团队。基本上在这条业务线/产品线里，Fiona 是 Boris 的上级或至少是组织管理上的负责人。 在加入 Anthropic 之前，Fiona 曾在 Microsoft 参与 Visual Studio 和 TypeScript 相关工作，后来加入 Meta，创立 Facebook Marketplace 团队，并参与 Meta 智能眼镜、AR 眼镜以及 Instagram 基础设施、增长、安全等团队建设。超过 25 年的工程经历，让她既经历过从 Vim 到 IDE、从 CD 发版到在线发布的软件工程变迁，也正在亲身经历 AI 对工程组织的重塑。 这场谈话中，Fiona 具体讲到了 Anthropic 内部如何使用 Claude 管理团队输出，如何让 routines 在每天早上自动读取反馈、启动 agent、生成 PR；如何用 bad vs. sad 框架定义产品质量，甚至通过用户脏话频率观察挫败感；如何从 token maxing 转向 ROI 衡量，避免把工具使用量误认为真实进展；以及为什么管理者必须亲自 dogfooding，甚至先从 IC 做起，才能不被 dashboard 和会议汇报隔离在真实产品之外。 她也谈到了 AI 编程的另一面：工程师可能失去过去写代码时的心流，团队协作可能变得孤独，新人工程师可能跳过亲手理解架构和底层系统的阶段。与此同时，PM、设计师、数据科学家等角色正在被卷入编码工作流，工程师也被要求拥有更强的产品感。岗位边界不再清晰，团队运作方式也不得不随之改变。 以下为完整版对话，经 InfoQ 编译： 2026年，一个被 AI “浸透”了的软件团队什么样？ Lenny：Fiona，谢谢你来参加节目。我之前在 Code with Claude 活动上听了你的演讲，当时就觉得必须把你请到节目里。你对 AI 和软件工程未来的思考已经非常超前。你做工程师已经 25 年了。我看了你的 LinkedIn，你最早是在 IBM，这和今天的软件世界已经完全不一样了。尤其是过去两年，工程师这个职业变化太剧烈了。大家可能都忘了，不久前 100% 的代码还是人写的，而现在已经越来越接近大量代码由 AI 生成。Boris 曾经说过，coding is solved。 Anthropic 最近还发了一张图，说 Anthropic 工程师平均每季度交付的代码量，相比 2025 年已经增长到 8 倍。你作为一个经历了很长工程周期的人，能不能回顾一下：在你的职业路径中，哪些关键时刻改变了你对工程工作的理解，也塑造了你今天的工作方式？ Fiona：我很喜欢这种回顾。最早我在 IBM 做 DB2，在操作系统服务团队。当时我的想法很简单：越靠近底层、越靠近操作系统，就越“硬核”，也能学到更多东西。所以我很幸运能进入 IBM 实习。 从 IBM 到 Microsoft，对我来说已经是一次很大的变化。在 IBM 时，我主要用 Vim，没有真正使用 IDE。可能当时有 Eclipse 授权，但我们大多数人并不用，更多是在终端里调试。 后来我加入 Microsoft。那是 2000 年互联网泡沫破裂之后，很多公司冻结招聘，所以我能拿到 Microsoft offer 非常幸运。当时他们告诉我会去 Visual Studio 团队，但我其实并不知道 Visual Studio 是什么。我来自一个偏 Unix 的学校，听到 Visual Studio 这个名字，我甚至以为它是不是一个更好的画图软件。我能看出经理当时脸上的表情是：“这是什么情况？” 但后来，Visual Studio 成了我职业生涯前 11 年里最重要的部分。那是我第一次真正使用 IDE，第一次看到调试器、断点、多线程调试等能力。那种体验对我来说非常震撼。 我在 Visual Studio 编辑器团队工作，用 Visual Studio editor 来构建 Visual Studio editor，也正是从那里开始，我真正喜欢上了 dogfooding，也就是自己深度使用自己团队做的产品。我们希望先为自己和队友创造非常好的开发体验。那个年代还没有今天这样的社交媒体反馈机制，工程师很难快速听到客户反馈。虽然会有用户研究、客户拜访，但没有今天这种即时反馈。幸运的是，在 Visual Studio 团队里，我们自己就是重度用户，因此团队内部就能形成非常快的反馈循环。 Lenny：大家现在讨论工程师角色变化时，常常只关注最近两年 AI 带来的冲击，但其实软件工程历史上也经历过很多重要变化。比如 Visual Studio 这类 IDE 的出现，本身就大幅改变了工程师的工作方式。你提醒了我们这些历史节点。 Fiona：是的。我在 Visual Studio 工作时，我们还会把软件刻在 CD 上发布。那时有非常硬的 deadline，因为软件必须准备好交给制造环节，再刻录到 CD，最后放到货架上销售。 后来，软件可以在线发布，这又是一次变化。过去工程时间是非常稀缺的资源，同时又有印刷 CD 这样的硬截止日期，所以大家会做大量规划，确保在有限时间里尽量把事情做好。 现在在 Claude Code 和 Cowork 上，我们看到的是另一种变化：Coding 不再是瓶颈。你刚才提到的那张图也说明了这一点。问题变成了：瓶颈转移到了哪里？ 现在不只是工程师在提交代码，Claude Code 团队里的设计师、PM，几乎所有人都在 check in code。提交代码的人更多，角色更混合，吞吐量也变得非常高。因此新的问题是：我们如何做 verification？如何确认这些高速生成和提交的东西是正确的、高质量的？ Lenny：这正是我想展开的主线。很多人都在想，未来的软件工程、工程管理、产品团队管理到底会是什么样子。你现在其实正在亲身经历这一切。你刚才提到一个更强的 Verification 需求，也就是说，当代码量增长 8 倍时，团队必须更关注质量和正确性。那我先问一个很大的问题：到 2026 年，一个真正 AI-pilled 的软件团队会是什么样？ Fiona：角色边界正在变得模糊，越来越多人会成为 builder。我最近做的一个变化是，我有一个 Claude Code remote session，会把它接入我们所有 repo。这样我可以全面看到团队正在做什么。这个实例也能访问我们的 S