运行AI原生的工程组织

多年来，工程带宽一直是构建应用程序的昂贵部分。我们过去围绕软件规划和交付的每一个流程，先是瀑布式，然后是敏捷式，都是围绕这一成本建立的。

我在21世纪初开始了我的职业生涯，在Visual Studio工作。那时我们以CD-ROM形式发布软件，并有严格的制造期限。一旦我们能够在线分发软件，我们便开始增加持续更新的频率。现在我们再次改变工作方式，这次是围绕编写软件所需的时间和人力。

在Claude Code团队，编写代码、编写测试和重构很少再让我们放慢脚步。但当代理式编码消除了实际输入代码的需求时，瓶颈并没有消失。验证、代码审查和安全取而代之。

我们现在都能非常快速地生成大量代码，但这引出了新问题：这段代码正确吗？如何维护？还有我从同行工程领导者那里经常收到的一个问题：“人类如何跟上你们进行代码审查的方式？”

悄悄失效的流程

我们都会出于某个原因制定流程，以弥补差距或使某些工作更好。但当那个差距不复存在、流程变得过时时，它们很少自行消失。当Claude Code团队开始将代理式编码作为我们的默认工作方式时，我们许多现有流程都失效了。以下是我们重写的准则及其原因。

规划：将路线图转为及时制

旧准则是在编码时间昂贵时花费大量时间进行预先规划。当我最初加入Claude Code团队时，我们制定了一个相当不错的六个月路线图，然后因为Claude Code，很多变化如此之快，以至于到第三个月时路线图已经过时。

工程速度和吞吐量现在不同了，所以我们规划冲刺的方式也改变了。我称之为及时（JIT）规划，几乎就像JIT编译：如何在正确的时间做适量的事情？我们的规划仪式从设计文档转向了在PR或原型中的讨论。这个领域变化很快，所以我们不做很多产品评审。我们现在流程是：先做原型，让大量内部用户参与，然后根据他们的反馈采取行动。

获取背景：问Claude，而不是问作者

当工程师编写代码时，回答大多数问题的第一步是找到编写该代码的人。现在，由于我们所有的PR都由Claude辅助，“谁做了这个更改？”已不够。我们的新准则是更深入一层：你实际需要知道什么？例如：你是在寻找谁导致了回归？找一位专家回答客户问题？还是了解某个决策的背景？你向Claude提问，并考虑Claude是否能直接回答，也能提供更多数据和背景。

在Claude Code团队，无论问题是什么，我们的流程也都是问：“有没有办法自动化？”例如，让Claude每天早上总结客户反馈渠道，从我喝咖啡时手动做的仪式变成了我在后台自动运行的东西。

代码审查：信任但要核实

我们大量使用Code Review。Claude处理所有风格和lint检查、PR反馈请求、在完整提交前捕获错误和修复它们，以及添加测试。在哪些方面我们仍然肯定需要人类？是专业知识。

新准则是在重要之处进行人工审查：对于法律审查，我总希望我的法务合作伙伴参与风险承受。对于信任边界和安全敏感的代码，我需要领域专家。产品经理和设计师也需要参与产品判断和品味。

不过，持续评估很重要，因为随着模型改进，信任与核实的适当平衡会不断变化。今天你需要人类做的事情，下一代模型可能需要不同的方式。

团队构成：模糊角色

Claude和AI已重塑了团队的角色。我们的PM现在经常编码，这很有趣。有了Claude，非传统编码者现在能做更多工程工作，工程师也承担了内容和设计等传统上不属于技术方面的工作。

在Claude Code工程团队，我特别看重两类人。一类是有产品意识的创意建设者：那些深具好奇心、热爱发布解决问题产品的梦想家。另一类是拥有深厚系统专长的工程师。例如，当我加入团队时，我注意到我们缺少系统背景的专家，而在构建Claude Code on the Web时，我们需要确保Claude能在任何地方运行。

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

我们如何推行新准则

随着这些准则的变革，有些方面作为团队原则被强制要求，其他则让小团队（小组）自行摸索。有一组Claude Code核心团队原则是不可谈判的“必须做”：

• 不懈地使用自己的产品：每个Claude Code团队成员，包括跨职能合作伙伴，都使用Claude Code（以及Claude Cowork）。我们总在思考如何让Claude帮助我们更快、更高效地完成工作。
• 保持团队尽可能扁平化。当我加入 Claude Code 时，我希望每位经理都先以个人贡献者身份开始，通过交付产品学会如何成为团队中高效的工程师，并真正亲身体验和理解在 Anthropic 当工程师是什么感受。我们在 Claude Code 和 Claude Cowork 上有一个整体的团队使命。经理们支持各个工作单元，同时保持团队敏捷，以便人员能够转移到有工作的地方。
• 毫不犹豫地终止不再有效的流程：最后，我们不断质疑为什么我们要以现在的方式做事。当某件事不再有意义时，团队成员明确有权质疑并终止旧流程。

然而，在这些少数规则之内，每个单元都有很大的自主权。他们有空间调整如何使用 Claude 来做分类、如何开展规划仪式或站会，以及哪些工作流首先被“Claud化”。

如何知道你的新流程正在被采纳

以下是每位工程领导者在推出变更时现在就应该开始跟踪的三个数字。

• 入职上手时间缩短：工程师、设计师或产品经理能多快开始发挥作用？在我们团队，这比一年前快得多，现在工程师们能在第一周内就写出真实的代码。
• PR 周期时间缩短：这个指标值得深入探讨，因为它可能帮助你找出流水线在扩展方面的问题。随着我们生成的代码量大大增加，构建系统和持续集成有时可能难以跟上。
• Claude 辅助的提交数量上升：对我们来说，默认情况下，每次提交都是 Claude 辅助的。我想在过去的四个月里，我还没见过非 Claude 辅助的提交。

关于第三点，不要把吞吐量误认为是成功。吞吐量只是一个指标，但真正的指标是衡量你试图解决的问题。如果目标对齐，吞吐量可以帮助你更快地解决问题。

入门

如果只让我给你一点建议：选择你最繁忙的工作流。这可能是你最昂贵的工作流，可能是你害怕的，或者你的团队不期待的。然后问：它是否仍在达到其目的？如果是，你能自动化它吗？

我曾经在一个团队，每周有一次昂贵的评审，会议室里有很多人。我注意到每个人都在用笔记本电脑，除非轮到他做状态汇报。他们会抬起头，说状态，然后又低头用电脑。我问了一个简单的问题：“我们为什么又开这个会？这似乎是在浪费我们的时间。”仅仅这一个问题就让所有人意识到这个会议没有必要，所以我们取消了它。

所以，问问自己：你的工程工作流中有什么可能考虑自动化甚至完全放弃的？

‍