If You Thought the Speed of Writing Code Was Your Problem - You Have Bigger Problems
Source: Andrew Murphy's Blog | Date: March 2026
核心观点
"Your VP looked at your entire software delivery organisation, identified the one thing that was already pretty fast, and decided to make it faster. They found a station on the assembly line that was not the bottleneck, and threw money at it."
Goldratt 的约束理论 (Theory of Constraints)
核心原则：每个系统都有且仅有一个约束（瓶颈）。整个系统的吞吐量取决于这个瓶颈的吞吐量。在解决瓶颈之前，优化其他任何环节都不会让系统变得更快，反而会让系统变得更糟。
当"AI提升40%代码产出"发生时会发生什么
- PR堆积：开发者以更快的速度产生PR，但Reviewer没有增加
- Review质量下降：PR太多无法认真审核，开始"橡皮图章"式通过
- 上下文丢失：作者已经切换到下一个AI辅助功能，几乎不记得前一个PR的内容
- CI变慢：45分钟的CI，变成堆叠的等待
- 部署拖延：功能在Staging停留三天，没有人拥有"紧急上线"的步骤
结果：
- 你产生了更多代码，却交付了更少的软件
- 你的情况明显变得更糟，却有一个显示"生产力提升40%"的仪表盘
- 更可怕的是：没有人完全理解这些AI生成的代码
"More code, less understanding. That's not a productivity gain. That's a time bomb with a nicer dashboard."
真正的瓶颈在哪里？
1. 你不知道要构建什么
- PM已经两个月没有和真实用户交谈了
- 需求是Jira上的三句话和一个Figma链接
- 工程师每天做50个关于行为、边缘情况和错误处理的微决策
- 教训：如果你在不了解问题的情况下加快代码输出，你只是更快地构建了错误的东西
2. 代码"完成"后的一切
- 代码写作可能只占整个旅程的20%，另外80%是各种排队等待
- PR review → CI → Staging → QA → 安全审核 → 部署窗口 → 金丝雀发布
- 真实案例：一下午写的代码花了两个月才到达生产环境
3. 部署信任螺旋
- 团队害怕部署：测试不稳定，可观测性混乱，不信任金丝雀流程
- 结果：将变更批量成更大的版本
- 更大的版本 = 更高的风险 = 更少的发布频率
- 恐惧螺旋达成：更多代码，同样害怕部署的文化
关键洞见
- 瓶颈不是写代码的速度 - 代码写作几乎从来不是瓶颈
- AI不能解决"理解要构建什么"的问题 - 它只能更快地构建你已经理解的东西
- 加速一个非瓶颈的步骤会让整个系统变得更糟 - 产生更多待办工作，淹没瓶颈环节
行动建议：
- 先识别真正的瓶颈在哪里
- 在使用AI加速之前，先解决"理解问题"的瓶颈
- 审视整个价值流，而不仅仅是代码写作环节
探索时间: 2026-03-18 | 来源: Hacker News Best