打造 AI 原生工程组织

多年来，工程带宽一直是构建应用程序中最昂贵的部分。我们过去围绕软件规划和发布的每一个流程，从瀑布模型到敏捷开发，都是围绕这一成本建立的。

我在 2000 年代初开始职业生涯时，参与的是 Visual Studio 的开发。那时候，我们通过 CD-ROM 发布软件，有着严格的制造截止日期。后来，当软件可以在线分发时，我们开始持续发布更新。现在，我们再次改变了工作方式，这次是为了适应编写软件所需的时间和人力。

在 Claude Code 团队中，编写代码、编写测试和重构代码很少再拖慢我们的进度。但当代理编码消除了实际敲代码的需求后，瓶颈并没有消失。验证、代码审查和安全取而代之。

我们现在都能非常快速地生成大量代码，但这也带来了新的问题：这段代码正确吗？它如何维护？以及我从其他工程负责人那里听到的最多的问题之一是：“人类是如何跟上你们的代码审查速度的？”

1、那些悄然失效的流程

我们建立流程都是有原因的，为了弥补某个缺口或让某些事情运转得更好。但当那个缺口不复存在、这些流程变得过时时，它们很少会自行消失。当 Claude Code 团队开始将代理编码作为默认工作方式时，许多现有流程都失效了。以下是我们重写的一些规范，以及原因。

1.1 规划：将路线图转向即时规划

过去的规范是花大量时间进行预先规划，因为编码时间很昂贵。当我刚加入 Claude Code 团队时，我们制定了一份相当不错的六个月路线图，但因为 Claude Code 的存在，太多事情发生了变化，到第三个月时路线图就已经过时了。

现在的工程速度和吞吐量已经不同，所以我们规划冲刺的方式也发生了变化。我称之为即时规划（JIT），有点像 JIT 编译：如何在正确的时间做恰到好处的规划？我们的规划仪式从设计文档转向了 PR 讨论或原型。这个领域变化很快，所以我们不会做很多产品评审。我们现在的流程是：先制作原型，让大量内部用户使用，然后开始根据他们的反馈行动。

1.2 上下文收集：问 Claude，而不是问作者

当工程师编写代码时，获取大多数问题答案的第一步是找到写代码的人。现在，由于我们所有的 PR 都有 Claude 辅助，“谁做了这个改动？”已经不再足够。我们的新规范是再深入一层：你真正需要知道什么？例如：你是在找导致回归的人？一个能回答客户问题的专家？还是某个决策的背景？你向 Claude 提出这个问题，并考虑 Claude 是否能直接回答，而且可能拥有更多的数据和上下文。

在 Claude Code 团队中，无论那个问题是什么，我们的流程还会问：“有没有办法将其自动化？”例如，让 Claude 每天早上总结客户反馈渠道，这从我用咖啡时手动完成的仪式，变成了我只需在后台自动运行的事情。

1.3 代码审查：信任但验证

我们大量使用 Code Review。Claude 处理所有的风格和代码规范检查、PR 反馈请求、在完整提交前捕获并修复 bug，以及添加测试。我们仍然明确需要人类的地方是专业知识。

新的规范是在重要的地方进行人工审查：对于法律审查，我总是希望我的法律合作伙伴参与风险评估。对于信任边界和安全敏感代码，我需要领域专家。产品经理和设计师也需要参与产品判断和品味把控。

不过，持续评估很重要，因为随着模型的改进，信任与验证之间的正确平衡会不断变化。今天需要人类参与的事情，在下一个模型出现时可能会有所不同。

1.4 团队构成：角色模糊化

Claude 和 AI 重塑了整个团队的角色。我们的 PM 现在写很多代码，这很有趣。有了 Claude，非传统编码者现在能够做更多工程工作，而工程师则承担内容创作和设计等工作，这些传统上不属于技术范畴。

在 Claude Code 工程团队中，我非常看重两种人才画像。一种是具有产品意识的创意构建者：那些充满好奇心、热衷于发布解决问题的产品的梦想家。另一种是拥有深厚系统专业知识的工程师。例如，当我加入团队时，我注意到我们缺少系统背景的专家，而我们在构建 Claude Code on the Web 时需要这些专家，以确保我们能在任何地方运行 Claude。

另一方面，我不太看重原始吞吐量，模型会处理这个。更重要的问题是哪里仍然需要人类专业知识，那才是我会关注的地方。

2、我们如何推广新规范

随着这些规范的改变，有些方面被规定为团队原则，有些则让小型子团队（pods）自行决定。Claude Code 核心团队有一套不可协商的“必须做”原则：

• 不间断地用自己的产品进行“狗食测试”。每一位 Claude Code 团队成员，包括跨职能合作伙伴，都使用 Claude Code（以及 Claude Cowork）。我们一直在思考如何让 Claude 帮助我们更快、更高效地完成工作。
• 尽可能保持扁平化的团队结构。当我加入 Claude Code 时，我希望每位管理者都从 IC 做起，通过实际交付来学习如何成为团队中高效的工程师，真正经历并理解在 Anthropic 做工程师是什么感觉。我们在 Claude Code 和 Claude Cowork 上有一个整体的团队使命。管理者支持工作 pods，同时保持团队敏捷，让人们可以转移到工作需要的地方。
• 果断终止不再有效的流程。最后，我们不断质疑为什么我们要以现在的方式做事。当某件事不再有意义时，团队成员有明确的权限去质疑并淘汰旧流程。

不过，在这几条规则之内，每个 pod 都有很大的自主权。他们可以灵活调整如何使用 Claude 进行问题分类、如何运行任何规划仪式或站会，以及哪些工作流程优先“Claudify”。

3、如何知道你的新流程正在落地

以下是每位工程领导者在推广变革时都应该开始跟踪的三个数字。

• 新员工上手时间会缩短。工程师、设计师或 PM 多久能开始发挥作用？在我们团队中，这比一年前快得多，工程师现在在第一周内就能交付真正的代码。
• PR 周期会缩短。这一点值得深入研究，因为它可能帮助你识别管道在哪里难以扩展。由于我们生成的代码量大幅增加，有时构建系统和持续集成（CI）可能难以跟上。
• 使用 Claude 辅助的提交量增加。对我们来说，默认情况下，每一次提交都有 Claude 辅助。我想我在过去四个月里没有见过一次非 Claude 辅助的提交。

关于第三点，不要把吞吐量与成功混淆。吞吐量是一个指标，但真正的指标是衡量你试图解决的问题。有了正确的对齐，吞吐量可以帮助你更快地解决问题。

4、入门指南

如果我要留给你一句话：选择你噪音最大的工作流程。这可能是你最昂贵的工作流程，可能是你畏惧的，或者是你的团队不期待的那个。然后问：它还在服务于它的目的吗？如果是，你能自动化它吗？

我曾经在一个团队中，有一个昂贵的每周评审，大量人员聚集在会议室里。我注意到每个人都在自己的笔记本电脑上，除了轮到自己汇报状态时。他们会抬起头来说一下状态，然后又低下头继续看电脑。我问了一个简单的问题：“我们为什么又要开这个会？这似乎是对我们时间的昂贵使用。”就这一个简单的问题让所有人意识到它并不必要。于是我们取消了它。

所以，问问自己：你的工程工作流中，有哪一部分你可能会考虑自动化甚至完全取消？

原文链接: Running an AI-native engineering org

汇智网翻译整理，转载请标明出处