AI 原生工程组织
当 agentic coding 成为工程团队的默认工作方式后，哪些原有流程会失效？应该用什么替代？瓶颈会转移，但不会消失。
核心论点
工程带宽曾经是构建应用最昂贵的部分。瀑布流、敏捷开发——所有这些流程都是围绕"写代码很贵"这个前提设计的。现在 agentic coding 把"写代码"这个瓶颈打掉了，但瓶颈没有消失——它转移到了验证、代码审查和安全上。
"We can all generate a lot of code really fast now, but this also brings up new questions: Is this code correct? How is it maintained?"
我们现在都能很快生成大量代码，但这也带来了新问题：这些代码正确吗？怎么维护？
| 维度 | Before | After |
|---|---|---|
| 规划 | 六个月产品路线图 | Just-in-Time 规划：做原型，内部用户试用，根据反馈行动 |
| 上下文获取 | 找写代码的人问 | 先问 Claude，然后问能不能自动化 |
| 代码审查 | 人工审查一切 | Claude 处理风格、bug、测试；人审需要专业判断的部分 |
| 团队构成 | 固定角色：工程师写代码、PM 规划、设计师设计 | 角色模糊：PM 做原型，工程师做设计和内容。招有产品感的创造者和深度系统专家 |
四个流程变革
当编码不再是瓶颈，规划方式、上下文获取、代码审查和团队构成都需要重新设计。
六个月路线图 → Just-in-Time
旧做法：花大量时间做前置规划，因为编码时间很贵。新做法：JIT 规划——先做原型，让内部用户用起来，然后根据反馈行动。作者加入 Claude Code 团队时写了一份不错的六个月路线图，但三个月后就过时了——因为 Claude Code 本身让开发速度变了。
找作者问 → 先问 Claude
旧做法：有问题找写代码的人。新做法：先问 Claude，因为现在 PR 都是 AI 辅助的，"谁写的"已经不重要了。更重要的是：你到底想知道什么？是回归的根因？客户问题的答案？还是某个决策的上下文？
全面人审 → 信任但验证
旧做法：人审一切。新做法：Claude 处理风格、lint、bug 检测、测试。人只审需要专业判断的部分——法律审查、安全敏感代码、产品品味。
固定角色 → 角色模糊化
PM 现在写代码了。工程师也做设计和内容了。招聘时看重两个画像：有产品感的创造者和深度系统专家。不看重什么？原始吞吐量——模型已经处理了。
"What you need humans for today might look different with the next model."
今天需要人做的事，下一个模型出来后可能就不一样了。
三个核心原则
不可协商的原则——每一个团队成员都必须遵守的底线。
疯狂 dogfood 自己的产品
每个团队成员（含跨职能合作者）都用 Claude Code 和 Claude Cowork。不是"建议用"，是"必须用"。只有深度使用自己的产品，才能发现真正的痛点。
尽可能保持团队扁平
经理先从 IC 做起，先学会在团队里有效地产出代码。扁平不是目的，而是确保每个决策者都理解一线工作状态的手段。
毫不犹豫地砍掉不再有效的流程
团队成员有明确的授权去质疑和杀死旧流程。找到你最吵闹的流程，问它是否还在服务于它的目的。如果不是，砍掉它或自动化它。
"I asked one simple question: 'Why are we having this meeting again?' And just that one question made everyone realize it wasn't needed. So we canceled it."
我只问了一个简单的问题：'我们为什么还要开这个会？'就这一个问题让所有人意识到它不需要了。所以我们取消了它。
压力测试
这篇文章没告诉你的——三个最致命的假设，以及沉默的证据。
三个致命假设
- 假设一："编码不再是瓶颈" —— 只在特定类型的工作上成立。新功能原型、well-defined 的任务确实如此。但对于遗留系统维护、复杂架构决策、性能关键路径上的优化，AI 辅助的效果远没有这么乐观。
- 假设二："JIT 规划比路线图好" —— 这假设团队足够小、足够对齐。在更大的组织中，JIT 规划可能导致方向不清和资源浪费。Claude Code 团队能 JIT 是因为他们有清晰的使命和极强的执行力文化。
- 假设三："角色模糊化是好事" —— PM 能写代码 ≠ PM 应该写代码。专才的深度在许多领域仍然不可替代。模糊化可能在短期内提高速度，但长期可能导致"什么都能做但什么都不精"的团队。
沉默的证据
- 失败案例 —— 有多少团队尝试了类似转型但失败了？失败的原因是什么？文章完全没有提及。
- 技术债务 —— AI 生成的代码带来的技术债务积累速度如何？半年后回头看代码库质量如何？
- 初级工程师成长 —— 初级工程师如何在没有"手写代码"这个学习路径的情况下建立专业能力？
- 安全事故 —— AI 生成代码引入的漏洞？安全事件？文章一片空白。
这篇文章发表在 Anthropic 的官方博客上。每个案例都在说"用 Claude Code 让我们更好了"。这不是独立研究，是产品营销 + 真实经验的混合体。
苏格拉底对话
用问答形式深入探讨这篇文章的核心论点，揭示隐藏的假设和盲点。
PM 能写代码，靠谱吗？
学生：Anthropic 说他们团队 PM 都能写代码了，这听起来很酷，但靠谱吗？
老师：关键不在 PM 能不能写代码，而在 Claude Code 降低了"写代码"这件事的门槛到什么程度。如果 PM 用 Claude Code 写的是原型和内部工具——这些对质量要求没那么高——那确实可以。但你要注意作者的措辞："PMs code a lot now"，而不是 "PMs ship production code now"。这里面的差距很大。
JIT 规划真的更好？
学生：JIT 规划真的比六个月路线图好吗？
老师：这取决于你的产品处于什么阶段。Claude Code 是一个快速迭代的产品，六个月路线图确实会过时。但如果你在做的是一个需要长期架构演进的基础设施项目——比如数据库内核、编译器——六个月甚至一年的架构规划仍然是必要的。问题不是"JIT 好不好"，而是"你的产品需要什么级别的可预测性"。
100% AI 辅助的 commit 可信？
学生：作者说过去四个月没见过非 Claude 辅助的 commit，这个数据可信吗？
老师：在一个 dogfood 文化极强的团队里，这是完全可信的。但要注意 survivorship bias——这是一个 AI 公司的 AI 产品团队。他们的日常工作就是让 AI coding 更好。这个数据点有参考价值，但不能直接推而广之。
最大的价值是什么？
学生：那这篇文章对我最大的价值是什么？
老师：不是具体的工具或流程，而是那个结构性洞察：瓶颈会转移。你现在工作中的瓶颈是什么？是编码？是测试？是部署？是需求沟通？找到它，然后问：AI 能帮我解决这个瓶颈吗？如果能，解决之后下一个瓶颈会出现在哪里？提前准备。这才是这篇文章真正想说的。
个性化洞察
这篇文章最有价值的不是"用 Claude Code"，而是它揭示的一个结构性规律：当你的核心瓶颈被移除后，次级瓶颈会立刻上位。
"瓶颈转移"框架可以用到工作流设计里
编码已经不慢了，新瓶颈在哪？可能是：prompt engineering 的质量、验证 AI 输出的正确性、跨文件改动的协调。给 Claude 更好的项目上下文（CLAUDE.md）、建立自动化验证流程、用 subagent 处理跨文件改动。
"问 Claude 而不是问作者"
遇到代码问题时，先让 Claude 分析整个上下文（文件结构、调用链、git blame），再决定是否需要找人。这比直接问"这个谁写的"效率高得多。这个习惯现在就能建立。
三个追踪指标值得自己用
特别是 PR cycle time 和 AI-assisted commits 的比例。前者帮你发现 CI/CD 瓶颈，后者帮你衡量 AI 辅助的渗透率。工作流效率直接影响产出。
未来竞争力不在"能写多少代码"
"有产品感的创造者" + "深度系统专家" > "高吞吐量的码农"。未来的竞争力在"能定义什么问题"和"能理解多深的系统"。
砍掉不再有效的流程需要制度化
考虑建立一个定期的"流程审计"——每季度问一次：我们还在做的哪些事情已经不再服务于它的目的了？跟经济学里的李比希最小定律一样：生长不取决于总量最多的养分，而取决于最稀缺的那个。
画出你的工程流程瓶颈图
标注每个步骤的时间占比 → 找到当前最慢的那个环节 → 问那个环节能不能被自动化。如果不能，为什么？作者的最后一条建议是全文最好的：找到你最吵闹的流程，问它是否还在服务于它的目的。
不要把吞吐量和成功混淆。吞吐量是一个指标，但真正的指标是你衡量你在解决什么问题。