The new bottleneck
TL;DR · AI 摘要
AI工具提升了开发效率，但流程未同步升级，导致新瓶颈出现。
核心要点
- AI工具降低了代码生成成本，但流程未随之优化。
- 组织需重新审视需求定义和协作流程，以匹配新工具的效率。
- 敏捷流程应随技术变化调整，否则无法释放AI的潜力。
结构提纲
按章节快速跳转。
思维导图
用一张图看清主题之间的关系。
查看大纲文本（无障碍 / 无 JS 友好）
- AI工具与流程瓶颈
- AI工具的效率提升
- 代码生成成本降低
- 开发速度加快
- 流程未同步优化
- 传统流程未适应AI
- 需求定义和协作流程未更新
- 新瓶颈的出现
- 流程成为新瓶颈
- 需重新设计流程
金句 / Highlights
值得收藏与分享的关键句。
AI, of course, has significantly relieved that bottleneck. The incremental cost of a line of code... is now 'about the most inexpensive thing we do in software development.'
The sprint structure is the same. The handoff model, the PRD template, the design review checkpoint—all the same.
We said, 'Let’s not do that. Let’s actually reimagine what it will take to deliver that roadmap.'
新的瓶颈 - Stack Overflow
2026年6月18日
新的瓶颈
工程团队已经升级了他们的工具。他们是否也升级了他们的工作方式？
假设你的工程团队做对了所有事情：在AI编码工具的宇宙中遨游，选择最适合的工具，让每个人都能顺利使用并保持一致，然后看到个人生产力显著提升。工程师们更快地交付功能；演示令人印象深刻；领导层非常满意。
但也许随着时间的推移，你意识到你的团队实际上并没有变得更快。也许冲刺速度仍然差不多，功能仍然卡在同样的地方，回顾会议中仍然出现同样的老问题。那些AI工具承诺的额外产能去哪了？似乎有某种东西吸收了它们，但很难准确指出到底是什么。
工具已经改变，工程师的工作方式也已经改变，但围绕这些工作的流程（交接流程、定义好和完成的标准、相关人员的参与、审批）未必随之演变。使用AI编码工具后，企业是否只是升级了引擎，却忘记了继续关注道路？
当瓶颈转移时，你也必须随之移动
著名的瓶颈理论是这样的：每个系统都有一个瓶颈，当你解决一个瓶颈时，另一个瓶颈就会出现。改进一个瓶颈并不会改善整个系统，它只是创造了库存——工作在下一个瓶颈前堆积起来。
在制造业中，这一点是众所周知的，但软件开发中却较少一致地应用，我们往往将流程改进本身视为有价值的，而不是提出一些令人不适的问题，比如我们是否真的推动了进展。
当然，长期以来，代码生成确实是一个真实且合法的瓶颈。编写好的软件需要时间。我们如今习以为常的许多组织基础设施——敏捷、冲刺、故事点、速度跟踪——都是为了管理这一现实，以实现可预测性和规划。
当然，AI显著缓解了这一瓶颈。正如Intuit工程总监Eric Anderson在最近一集《Leaders of Code》节目中所说，一行代码的增量成本现在“是我们软件开发中最不昂贵的事情之一。”
但大多数组织仍在使用他们为管理旧瓶颈而构建的流程。冲刺结构仍然相同。交接模型、PRD模板、设计审查检查点——一切都一样。当Anderson的团队最近进行季度规划时，他描述了一个逐渐醒悟的时刻：“我们说，‘我们不要这样做。让我们真正重新想象实现该路线图所需的内容。’”当他审视团队的待办事项时，他意识到他们想得太小了。代码不会是困难的部分，那么时间到底会花在哪里？这是大多数工程组织尚未提出的问题。
新的瓶颈实际上是什么样子
新的瓶颈不会自我宣布。它只是在每次冲刺中反复出现，并被错误地归因于其他原因。它看起来是这样的。
构思与需求。当代码变得廉价时，模糊或考虑不周的规格说明所带来的成本却在上升。一个目标明确的AI代理将精确地构建你所描述的内容。如果你所描述的内容存在说明不足的问题，你将很快发现这一点，而重新设计工作也不会归咎于AI。如今，明确知道自己真正想要构建的内容（以及原因）变得更加重要，而不是更不重要。那些将发现和需求视为通向编码过程中的检查框的组织，将在他们的周期时间中感受到这种痛苦。
设计交接。埃里克提出了一个尖锐的问题，即当UI迭代几乎不耗费成本时，“设计完成”到底意味着什么。传统的交接模式——在编写任何一行代码之前，将完全完成的设计交给工程团队——在重做工作昂贵且耗时的过去是有意义的，但这种计算方式已经发生了变化。在许多情况下，在设计完成之前就开始构建只会增加延迟。
审查与判断。更多的产出意味着更多的审查面积。如果一位资深工程师现在负责的工作，以前需要一个完整的团队来完成，那么代码审查和架构监督将成为瓶颈。这已经在那些广泛部署AI但未改变审查、QA或技术签批流程的组织中显现出来。当产出翻倍但审查能力没有同步提升时，总会有某些方面不得不让步。
跨职能协调。这一点很容易被忽视，因为它不会在工程指标中体现出来，但工程团队现在移动的速度往往远远超过产品、设计、法律和安全团队的工作节奏。这种不匹配会以一种形式产生浪费，即完成的工作被搁置在架子上，等待那些从未设计用于如此快速运作的签批流程。当瓶颈位于团队之外时，它更难以被发现和解决（但并非不可能——继续阅读）。
为什么组织即使看到了这些问题，也未能解决它们
工程领导者并非不知道他们的流程已经过时，事实上，很多工程领导者都清楚这一点。但流程变更的难度似乎比推出一个令人兴奋的新工具更加令人望而生畏。
流程变更需要跨职能协作。你可以要求工程师采用新的编码工具，但你无法强制产品团队重新思考其发现方式，或要求设计团队重新考虑其交接模式。这些讨论需要跨职能团队的认同，而这些团队之间并没有共同的汇报线，同时还需要有足够组织地位的人来推动所有这些变化。大多数工程领导者可以推动自己的团队，但推动整个外围系统却是一个不同的问题。
旧的流程让人感觉安全。敏捷本身是对瀑布模型失败的回应，但在许多组织中，敏捷已经固化为它所取代的另一种版本。即使冲刺和仪式不再推动速度，它们仍然提供了舒适和可预测性。放弃熟悉的结构让人感到风险和不适，尤其是在团队已经从新工具中吸收了大量变化的情况下。
目前，没有人知道新的流程会是什么样子。在关于人工智能和工程的对话中，这一部分需要更多的诚实。“我们还不清楚如何真正做好这一点，”安德森解释道。“我们正在通过实践进行探索和学习。”当代码生成基本上变得免费时，还没有一套公认的运行软件团队的方案。那些在最佳实践达成共识之前等待行动的组织，假设这一领域会迅速趋于一致。但事实真的会如此吗？
重新调整实际的样子
升级团队的工作方式并不需要一次性彻底推翻现有结构。相反，应逐个功能、逐个检查点地审视你的流程，看看每个部分是否仍在解决一个仍然存在的问题。流程的某些部分可能仍然适用，但当你从另一个角度审视时，其他部分可能看起来完全不同。
从一个问题开始，而不是一个框架。对于你当前流程的每个部分，问问自己：这个部分原本是为了解决什么限制，而这个限制现在还存在吗？当以较小的块进行规划可以降低改变方向的成本时，两周的冲刺是有意义的。现在仍然如此吗？当工程时间成本显著更高时，设计审查关卡是有意义的。现在仍然如此吗？当然，并不是每个答案都会是否定的，但值得在每个关键点上提出这个问题。
重新思考“准备好构建”的含义。传统意义上的“准备好”——完整的规格说明、完成的设计、所有依赖项都已解决——是为了保护昂贵的工程时间而建立的。但我们现在所处的世界已经不同了。安德森描述了Intuit正在向一种模式转变，即产品经理和工程师实时共同开发功能，而不是将完成的规格说明逐级传递下去。在这种模式下，设计只是一个起点，而不是严格的前提条件。
缩短从想法到实验的距离。人工智能的最大价值可能不在于更快的代码生成，而在于更快的学习。安德森谈到Intuit从只能选择运行两个实验之一，到能够运行九个、九十个甚至九百个实验。要实现这一点，需要一个以实验为导向的流程，而不仅仅是执行：更短的周期、更宽松的“完成”定义，以及以你学到了什么，而不是仅仅以你发布了什么为中心的成功指标。
将跨职能的摩擦视为一个工程问题。瓶颈出现在工程团队之外——在产品、设计、法律或安全团队中——并不意味着这不是你的问题。希望加快速度的工程领导者，也应帮助相邻团队和职能加快速度。这可能意味着在探索阶段更加紧密地协作，或者构建共享工具以消除审查流程中的手动工作。即使只是承认这种摩擦，也是一个有益的初步步骤。
值得深思的问题
让我们回到引言中的团队：他们已经升级了工具，个人生产力也提高了，但他们仍然没有加快速度。没有东西是坏的，但流程吸收了这些提升，而这些提升尚未体现在输出结果中。
与流程不同，工具很容易更改，因此组织会推出新工具并称之为“转型”，因为这比彻底改革流程要容易得多。如果你多年来一直把衣服扔在地上，仅仅买一个新的衣柜并不会改变你的操作方式，除非你也将流程从“衣服→地板”转变为“衣服→衣柜”。新工具可以推动并鼓励流程的改变，但流程本身在某个时候也需要进化。
如果代码不再是瓶颈，你是否围绕真正的问题进行组织？
《Code Leaders》是《Stack Overflow Podcast》的一个栏目。如需建议话题或嘉宾，请发送邮件至 podcast@stackoverflow.com。