AI · MM · 408
AI编码新瓶颈
AI Coding New Bottlenecks · ai-coding-new-bottlenecks--mike-krieger
所属簇 AI 时代的工程组织与管理
解决什么问题
当一个团队的代码有 90% 由 AI 写出来之后,团队会本能地以为"工程执行"仍是最大瓶颈,继续按老思路优化写代码环节。这个模型指出瓶颈已经系统性转移到了别处,帮团队把优化力气用对地方。
核心内容
Anthropic 内部(尤其是 Claude Code 团队,他们用 Claude Code 开发 Claude Code 本身,PR 中 95%+ 由 Claude Code 生成)观察到瓶颈依次转移:
- 上游瓶颈:决策与对齐。写代码本身不再稀缺,稀缺的是"该往哪个方向投入探索"的最小可行策略(minimum viable strategy)——如何让团队既有方向感又敢在模型能力边界放手去试,作者坦言这一点自己也还没做对。
- 中游瓶颈:合并队列(merge queue)与代码评审方式改变。PR 数量暴增到系统扛不住,不得不重新架构合并队列。评审方式也从"逐行 review 每个 PR"转向"用另一个 Claude 做验收测试(acceptance testing)而非逐行审查"——Claude Code 团队自己就是这样运作的,虽然作者承认这也存在"代码库变得不可维护、甚至 Claude 自己都读不懂"的风险,但目前运行良好。
- 下游瓶颈:打包发布与协调。即便个体功能开发很快,仍然需要"航空管制"式的协调——确保发布是连贯的一个时刻(launch moment),让人知道你做了什么、并从反馈中学习,这个环节的本质需求没变,只是被大幅提效了。
作者引用经典运营优化著作《The Goal》里的"约束理论"(critical path theory)类比:解决一个瓶颈后,系统里会暴露出新的瓶颈,需要持续寻找"当前的那一个"约束点。
适用边界
- 这个瓶颈迁移模型的前提是团队已经把"写代码"这个环节的效率提升到很高水平(90% 代码由 AI 写),对代码 AI 化程度较低的团队,传统的工程执行瓶颈可能仍然是主要矛盾。
- 作者预期"一年后我们构建和发布软件的方式会完全不同,因为按现在的方式做会非常痛苦"——这是一个动态迁移过程,不是一次性诊断。
关键引述 · 原话
Mike Krieger: "We really rapidly became bottlenecked on other things like our merge queue... it just completely blew out the expectations of it."
Mike Krieger: "I've just found all these new bottlenecks in our system, there's an upstream bottleneck, which is decision making and alignment."
关联卡片
- 与 `harness-deprecation-as-model-improves--cat-wu`(同语料库,Cat Wu/Claude Code 团队视角)呼应:两者都描述"模型变强后,原本为弥补模型短板搭建的流程/脚手架需要持续拆除"。
被这些卡引用
出处：Mike Krieger (Anthropic CPO, Instagram 联合创始人) · 03-podcasts/mike-krieger.md
提炼自 Lenny Rachitsky 的 Lenny’s Newsletter & Podcast（2019–2026）。本站为个人学习用途的二次创作，与 Lenny’s Newsletter 无官方关联。
provenance · 已核验 · glm-5.2
提炼自 Lenny Rachitsky 的 Lenny’s Newsletter & Podcast（2019–2026）。本站为个人学习用途的二次创作，与 Lenny’s Newsletter 无官方关联。
provenance · 已核验 · glm-5.2