以前大家总说 AI 会改变写代码的方式，但 Fiona Fung 讲得更狠一点：它连工程组织的默认假设都一起改了。
这场分享里最有价值的，不是“Claude Code 很强”这种结论。这个结论现在已经不新鲜了。
真正值得记住的是另一句：当编码吞吐不再是最贵的资源时，很多沿用了十几年的工程流程，会在你没注意的时候悄悄失效。
这句话听起来像管理层口号，但 Fiona 讲得很具体。她不是在抽象谈未来，而是在复盘 Anthropic 的 Claude Code 团队到底哪里开始不对劲：规划变慢了、review 跟不上了、ownership 变模糊了、跨职能协作的边界也开始融化。代码变快之后，组织反而更容易卡住。
过去的软件流程，大多默认“写代码很贵”
Fiona 提醒了一个很容易被忽略的事实：工程流程从来不是天降真理，它们只是对某一代瓶颈的适配。
以前为什么会有那么重的 roadmap、那么多前置 planning、那么强调设计文档、ownership、层层 review？因为那时候最贵的是工程带宽。写代码慢，改代码也慢，重构更慢，所以整个组织自然会围绕“别乱动、先想清楚、一次做对”来设计流程。
她举了一个很老派、但很有力量的例子。早年做 Visual Studio 时，软件真的是要压到 CD 里发货的。发布节奏、协作方式、截止日期，都是按那个物理分发时代塑形的。后来能在线分发，软件交付方式就变了。今天 AI coding 带来的变化，本质上也是同一类事：不是单点提效，而是底层约束换了。
所以她的核心判断很简单：工程组织里最贵的资源，已经不再是“有人把代码敲出来”。
这不是说工程师不重要了。我的意思是，以前很多流程保护的那个瓶颈，已经不在原地了。
新瓶颈不是写，是验、审、协同和维护
这一段我觉得是整场最扎实的部分。
Fiona 没把重点放在“AI 让开发更快”，而是往前推了一步：如果生成代码这件事便宜了，那什么开始变贵？她给出的答案很现实：verification、review、cross-functional partner、security，还有后续 maintenance。
说白了，今天团队不太缺“能产出更多代码”的能力，缺的是：
- 这些代码到底对不对
- 谁来 review 这么多变化
- 安全、法务、产品、设计怎么跟上节奏
- 生成出来的大量代码，未来谁负责维护
这个观察很重要，因为它把“AI 提效”从个人效率问题，拉回到了系统吞吐问题。
以前一个团队一天只能推进 1 倍产出，review 流程、CI、协作机制都还能顶住。现在产出突然变成 3 倍、5 倍，旧管道就会显得特别窄。很多团队不是不会用 AI，而是后半段流水线还是旧时代配置，于是前面加速，后面堵死。
这也是为什么 Fiona 说，有些流程不会轰然失败，它们只是 quietly stop working。这个说法很准。多数组织不是哪天突然宣布流程崩了，而是大家慢慢感觉越来越别扭：会开了很多，文档写了很多，review 也走了，但整体速度和质量并没有变好。
在 AI 原生团队里，planning 会缩，verification 得扩
Fiona 讲 Claude Code 团队怎么改 planning，我很认同。
她提到自己刚加入时还会本能地想要六个月 roadmap，结果写完没多久环境就变了。不是 roadmap 写得不认真，而是外部变化太快，生成和原型试错又太便宜，长周期预规划的收益明显在下降。
所以他们开始转向一种更接近 JIT planning 的做法：少做远距离规划，多做贴近当前窗口的判断。很多讨论不再先写一大坨 design doc，而是直接做 prototype、开 PR、让内部真实使用，再根据反馈继续调。
这不是“不要思考”，而是把思考从纸面预演，往真实产物上迁移。
但 planning 变轻，不代表团队变散。Fiona 反而反复强调，他们真正加码的是 verification。因为现在最危险的不是写不出来，而是写得太容易、改得太快、破坏面也更大。
她提到一个非常真实的情绪：修了一个 bug，第二天看到用户反馈里又冒出问题，会有那种“不会是我刚改坏的吧”的下沉感。这个细节让我觉得她讲的是一线经验，不是包装过的管理演讲。
所以 AI-native engineering org 的重点，不是减少约束，是把约束往更靠前、更自动化的位置挪。也就是她说的 shift left：尽量让错误更早暴露，最好在接近源头时就被抓住。
技术争论不会少，但争论方式会变
这场分享里还有一个很有意思的点：当构建成本下降之后，争论本身会变贵。
她举了自己和 Boris 讨论重构方案的例子。按旧习惯，本来是该拉去白板前辩半天的。但她突然意识到，现在完全可以把几套方案都做出来，甚至直接生成三版 PR，然后拿真实 diff、真实调用影响去讨论。
这个变化很关键。
以前技术争论很多时候是“谁的抽象更漂亮”“谁的经验更可信”。现在越来越可能变成“先把几个候选实现拉出来，再基于结果讨论”。这会让争论更接地，也更容易把“实现本身”和“对上下游的影响”一起纳入判断。
不过 Fiona 也点了一个边界：代码生成变快，不等于“最后一个提交的人赢”。如果团队文化没跟上，低成本生成反而可能把组织带进一种更隐蔽的混乱：谁先跑出 PR 谁就占上风，谁设置了自动化 routine 谁就抢到最后发言权。
所以她强调，AI 不是替代 alignment，恰恰会把 alignment 的重要性放大。这个判断我觉得很成熟。很多团队的问题根本不是工具不够强，而是共识机制太弱。
code ownership 这件事，已经开始变形了
她还讲了一个我很喜欢的观察：当大家的 PR 基本都被 Claude 辅助过之后，“这段代码是谁写的”这个问题本身就没以前那么有信息量了。
这个变化很微妙。
以前问 ownership，常常是在问三件事里的某一件：
- 谁最后改过它，可能引入了回归
- 谁最懂这块，可以回答问题
- 谁能提供上下文，帮助继续推进
现在如果继续停留在“谁写的”这个表层问题，可能反而会卡住。更有效的方式，是把问题继续往下点开：你到底是在找责任、找专家，还是找上下文？一旦问题被说清楚，很多事情就能被自动化或者被更直接地路由出去。
这也是 AI 原生团队一个很明显的特征：不是简单把老问题交给新工具，而是连提问方式都得更新。
code review 不会消失，但人类 review 会被重新分配到更值钱的地方
关于 code review，Fiona 的态度并不激进，反而挺务实。
她说得很清楚：Claude 很适合接手样式、lint、PR feedback request、补测试、提前抓一些明显 bug。这些都属于高频、模式化、可以规模化的 review 劳动。
但她仍然坚持一些地方必须上人：
- 法务判断
- 信任边界和安全敏感代码
- 产品 sense 和体验判断
- 高风险场景下的最终把关
也就是说，review 不是消失，是分层。
机器先吞掉大量重复工作，让人类 review 不再浪费在格式和低级错误上；人类再把精力集中到那些真正依赖经验、责任和判断的地方。这个框架其实很适合很多团队参考。因为多数团队现在不是“要不要 AI review”，而是“哪些 review 该自动化，哪些 review 必须升级成人的判断节点”。
她讲到请设计同事 review 一个节日版 Claude 终端形象时，我反而觉得这段很有代表性。产品 taste 这种东西，不是模型完全没有，但很多时候仍然需要真正有审美和场景感的人来拍板。AI 能把你带到八十分，最后那二十分，往往还是人的品味在决定。
招人、分工、组织形状，也都会被连带改写
Fiona 对团队画像的描述也挺值得抄作业。
她特别看重两类工程师：
- 有产品感觉、喜欢搭东西的 creative builders
- 在关键硬问题上有深系统能力的人
这其实很能说明问题。因为当“纯粹拼手速”不再是核心竞争力后，组织会更重视方向感、产品判断、系统边界感，还有在复杂基础设施上真正能兜底的人。
她还提到一个更激进的组织设计：让管理者先以 IC 身份进入团队，再逐步承担管理责任，整体结构尽量保持扁平。她给出的理由不是管理哲学，而是非常实际的 dogfooding——领导如果不亲自用，不亲自写，不亲自卡在那些具体 workflow 上，就很难判断哪些流程已经该删了，哪些摩擦是真问题。
我觉得这里最有启发的，不是“所有公司都该照搬 flat org”，而是：AI 工具一旦把管理者重新带回一线操作面，很多原本理所当然的组织层级设计，都值得重看。
真正的 source of truth，也在往代码本身回流
她后面讲 knowledge sharing 时也给了一个很有现实感的判断：在 Claude Code 团队里，代码本身越来越像 source of truth。
这不是说文档没用了，而是说如果代码和规格的更新速度差太大，文档天然会滞后。AI 工具的加入，会让更多人直接围绕代码、PR、原型来获取上下文，而不是先翻很多二手摘要。
这里我自己的感受是，未来更有价值的文档，可能不是“替代代码解释代码”，而是那些帮助团队表达约束、意图、决策边界的文档。至于“系统当前到底怎么工作”，越来越多时候代码本身加上 AI 辅助检索，就能回答掉。
这场分享最值得带走的，不是技巧，是一套组织诊断方法
Fiona 最后留给听众的动作建议，我觉得非常实用：去找你团队里最吵、最贵、最让人烦的 workflow，然后问一句，它现在到底还在不在服务原来的目的？
这个问题看似简单，其实很锋利。因为很多流程不是坏，只是它对应的旧瓶颈已经没了。你继续供着它，最后就会变成一种昂贵的习惯。
她举了一个例子：一个每周 50 人参加的大 review meeting，大多数人都低头忙自己的，轮到自己报状态才抬头。这种会，放在任何时代都贵，但在 AI 让很多同步成本进一步下降之后，就更显得不合时宜了。
所以我看完这场 talk 的最大感受，不是“Anthropic 已经进入未来了”，而是：AI-native engineering org 真正难的地方，不是让大家开始用模型，而是敢不敢系统性地删掉那些已经失效、但还挂着合理外衣的老流程。
工具升级很快，组织惯性升级很慢。后者才是大头。
我自己的结论
如果你今天带团队，或者你正在一个工程组织里推动 AI coding，这场分享值得看，不是因为里面有多少新术语，而是因为它把一个现实说透了：代码生成能力上去之后，团队的竞争力不再主要取决于谁写得更快，而取决于谁更早发现瓶颈已经换位置了。
有些团队会继续在“怎么多生成一点代码”上卷很久。
有些团队会更早把注意力转到验证、协作、组织形状、review 分层和流程清理上。
后者大概率会走得更远。