Claude Code 工程团队的流程和结构在代理式编码成为默认工作方式后发生了怎样的变化。
多年来，工程带宽是构建应用中昂贵的部分。我们围绕软件规划和发布使用的每个流程，从瀑布到敏捷，都是围绕这个成本建立的。
在 Claude Code 团队上，编写代码、编写测试和重构很少再拖慢我们的脚步。但当代理式编码消除了实际键入代码的需要时，瓶颈并没有消失。验证、代码审查和安全取代了它们的位置。
悄然失效的流程
规划：将路线图转向即时制
旧规范是花更多时间预规划，因为编码时间很贵。当我刚加入 Claude Code 团队时，我们写了一份相当不错的六个月路线图，然后因为 Claude Code，很多事情变化了，到第三个月就过时了。
工程速度和吞吐量现在不同了，所以我们规划 Sprint 的方式也改变了。我称之为即时制（JIT）规划，几乎像 JIT 编译。我们的规划仪式从设计文档转向 PR 或原型中的讨论。
上下文收集：问 Claude，而不是问作者
当工程师编写代码时，获得大多数问题答案的第一步是找到写代码的人。现在，由于我们所有的 PR 都有 Claude 辅助，"谁做了这个更改？"已经不够了。我们的新规范是深入一层：你实际需要知道什么？你让 Claude 回答那个问题。
代码审查：信任但验证
Claude 处理所有风格和 linting、PR 反馈请求、捕获 bug 并在完整提交前修复它们，以及添加测试。我们仍然确定需要人类的地方是专业知识。
新规范是人类在重要的地方进行审查：法律审查、信任边界和安全敏感代码、产品品味和审美。
团队构成：模糊角色
Claude 和 AI 重塑了团队中的角色。我们的 PM 现在写很多代码。有了 Claude，非传统编码者现在可以做更多工程工作，工程师也承担了内容和设计等工作。
| 之前 | 之后 | |
|---|---|---|
| 规划 | 六个月产品路线图 | 即时制规划：原型，让内部用户使用，并根据反馈行动 |
| 上下文收集 | 找到写代码的人问他们 | 先问 Claude。然后问你所问的是否可以自动化 |
| 代码审查 | 人类审查一切 | Claude 处理风格、bug 和测试。人类审查需要领域专业知识的地方 |
| 团队构成 | 固定角色 | 角色模糊：PM 做原型，工程师承担设计和上下文工作 |
如何知道新流程正在生效
以下是每个工程领导者在推出变革时应该开始跟踪的三个数字：
- 入职提升时间缩短：工程师、设计师或 PM 多快可以开始产生效果？在我们的团队上，这比一年前快得多，工程师现在在第一周内就发布真正的代码。
- PR 周期时间缩短：随着我们生成更多代码，有时构建系统和持续集成可能难以跟上。
- Claude 辅助提交增加：对我们来说，默认每个提交都是 Claude 辅助的。过去四个月我没见过非 Claude 辅助的提交。
入门
如果我要给你留下一个建议：选择你最嘈杂的工作流。 那可能是你最昂贵的工作流，你可能在恐惧的工作流，或者你的团队不期待的工作流。然后问：它是否仍在服务于它的目的？如果是，你能自动化它吗？
所以，问问自己：你的工程工作流中哪一部分你可能考虑自动化甚至完全放弃？
评论
还没有评论
欢迎留下第一条评论，帮助这篇内容更快形成讨论。