Claude Code 团队的负责人最近写了一篇博客，复盘 Anthropic 内部把工程组织从"敏捷范式"重构成 "AI-native engineering org" 的全过程。文章不长，但讲得彻底——哪些流程悄悄失效了、新规则是什么、怎么知道新规则生效了、起步该做什么。下面是完整解读。
起点：旧的组织假设是"工程带宽贵"
文章开头就点出关键判断：过去几十年软件工程所有流程（瀑布、敏捷）建立在一个前提上——工程带宽是稀缺资源。Visual Studio 时代要刻 CD 光盘，发布有硬截止日期；后来网络分发，发布可以持续滚动；现在又一次工作范式在变，这次是写代码本身的时间和人在变。
Claude Code 团队的现状：写代码、写测试、重构已经不再是瓶颈。消失的瓶颈让位给新的瓶颈——verification、code review、security。这是整个文章的"假设倒转"。
四件停止运作的旧流程
Anthropic 团队把以下四件事明确点出"已经失效"：
Planning：从六个月 roadmap 改成 just-in-time planning
旧规则：花大量时间预规划，因为编码时间昂贵。Claude Code 团队加入时写过一份相当不错的六个月 roadmap，结果因为 Claude Code 本身，三个月时这份规划就完全过时了。
新规则：JIT planning——像 JIT 编译一样，在正确的时间做刚好够的事。设计文档的仪式被 PR 里的讨论和 prototype 取代。这个领域动得飞快，他们不做太多产品 review——"做 prototype → 拉内部用户 → 听反馈行动"。
Context gathering：问 Claude，别问作者
旧规则：要弄清任何问题，第一步是找写这段代码的人。
新规则：所有 PR 都由 Claude 协助，"谁改的"这个问题不再有用——你得再往深一层问"你到底想知道什么"。是找引入 regression 的人？是找能回答客户问题的专家？是找决策的上下文背景？先问 Claude，再问"这事能不能自动化"。
作者给了一个具体例子：他之前每天早上手动汇总客户反馈渠道信息，现在这段是 Claude 在后台自动跑的。手动仪式被自动化直接消化。
Code review：信任但验证
Anthropic 内部重度使用 Claude Code Review。Claude 处理所有 style、linting、PR 反馈请求、bug 捕获、pre-commit 修 bug、加测试。
但人类的 review 不是消失、而是重新定位到"需要专业领域知识"的地方：
- 法务 review → 永远要法务 partner 介入
- 信任边界、安全敏感代码 → 领域专家
- 产品 sense、taste → PM 和 designer
新规则的关键："信任 vs. 验证"的平衡会随着模型变强而不断漂移，今天需要人类的事，到下一个模型就不一定。
Team makeup：角色在模糊
AI 重塑了团队角色：
- PM 现在写很多代码——"很好玩"（作者原话）
- 非传统编码者能承担更多工程工作
- 工程师开始承担内容和设计这些"传统不在技术侧"的工作
Claude Code 工程团队现在重仓两个画像：
- 有产品 sense 的创意 builder——deeply curious、passionate about shipping 解决问题的东西
- 有深度系统专业知识的工程师——比如在 Web 版 Claude Code 时，他们缺系统背景专家，模型可以 24/7 跑、但"everywhere" 运行的工程问题需要这些专业经验
作者明确点出自己不重仓的能力：raw throughput。"模型处理那些事；你该 focus 的是哪里还需要人类专业能力"。
三条铁律 + pod 自治
Anthropic 内部把"必须做"的核心原则定下来，但怎么落地交给小团队（pods）自治：
- Relentlessly dogfood your product — 跨职能伙伴全部日常用 Claude Code 和 Claude Cowork
- Keep the team flat as possible — 新 manager 先做 IC，从工程师身份学起，ship 完才真正理解工程师在 Anthropic 是什么体验。Manager 支持 pod 工作，保持敏捷让成员能跟着工作流动
- Don't hesitate to kill processes that no longer work — 不断问"为什么这样做"。当事情不再合理时，团队成员有明确的权限质疑和杀掉旧流程
这三条之外，每个 pod 拥有大量自主权——怎么用 Claude 跑 triage、怎么安排 planning ritual、哪个 workflow 先"Claudify"，都是 pod 自己定。
三个必追踪的数字
文章建议工程 leader 立刻开始盯三个数字：
1. Onboarding ramp time 下降。 工程师、designer、PM 多快能开始 productive？Claude Code 团队说比一年前快得多，新工程师第一周就能 ship 真代码。
2. PR cycle time 下降。 这个数字值得深挖——代码生成量大增时，build 系统和 CI 可能成为新瓶颈。这是 pipeline scaling 的早期信号。
3. Claude-assisted commits 上升。 默认每个 commit 都由 Claude 协助。作者说过去四个月他已经没见到非 Claude-assisted 的 commit。
第三条的提醒很关键：别把 throughput 当成功。Throughput 是一个 metric，真正的 metric 是你在试图解决的那个问题。对齐对了，throughput 只是顺带的副产品。
起步：一句话建议
Pick your noisiest workflow.
问三个问题：
- 这是不是你最贵的 workflow？
- 这是不是你最不想做、团队最不期待的 workflow？
- 它还在 serve 它的目的吗？如果是，能自动化吗？
作者举了一个亲身例子：他曾在某团队参加一个昂贵周会——一堆人挤在会议室，除了轮到汇报的人抬头外，其他时间所有人都在低头看笔记本。汇报的人抬头说完状态就低下去。他问了一个问题："这个会为什么还要开？"，所有人才意识到确实没必要——直接 cancel 了。
最后的落点很 Anthropic 风格：
"Ask yourself: what's one piece of your engineering workflow that you might consider automating or even dropping altogether?"
挑一个 piece，搞定它。从噪音最大的地方开始。
一句话总结
当编码不再是瓶颈，组织设计的所有假设都要重写。 旧假设是"工程带宽贵"，流程围着转；新假设是"工程带宽不贵了，verification / review / security 才是瓶颈"，流程跟着变。角色、planning horizon、review 责任、招聘画像、所有 metric 都要重新对齐——但不是一刀切的顶层设计，是铁律 + pod 自治的混合模式。