AI加速编码后瓶颈转移到了哪里

代码的产出速度已经超过了我能够自信地审查、验证和交付的速度。

旧工作流 vs 新工作流

我工作流中最大的变化并不是 AI 写代码更快了这么简单。而是我的角色正在逐渐从手动实现每一个细节，转向设计、编排、审查和验证整体结果。

这听起来是一个很小的转变，但它改变了我大部分工程精力的投入方向。

编程不再是最慢的环节

与 coding agent 协作改变了我对开发效率的认知。我可以定义一个任务，让 agent 探索代码库、实现变更、添加测试，然后返回一个可工作的 diff，整个过程比我手动构建所有内容要快得多。

但实现只是软件交付的一个阶段。

flowchart LR
    A[Requirement] --> B[Design] --> C[Implementation] --> D[Review] --> E[Test] --> F[Deploy]

AI 可以大幅压缩实现阶段，但审查、测试、集成、安全和部署仍然有其各自的限制。当这些阶段跟不上时，更快的编码并不能消除瓶颈，只是把它推到了下游。

这也是 Red Hat 最近在《为什么更快的编码并没有让交付变得更快》中提出的观点：生成代码和交付可靠软件不是同一回事。

我开始更清楚地在自己的工作流中注意到这一点。当我还在构建判断这个变更是否真的好的心智模型时，agent 已经可以产生一个相当大的变更了。

更多代码不等于更高效率

假设我以前一天完成两个有意义的变更，现在 AI 帮助我产出六个。乍一听这听起来是一个 3 倍的效率提升，但前提是工程系统的其他部分能够消化这六个变更。

它们仍然需要被理解、审查、测试、集成，最终在生产环境中运行。如果审查能力或 CI 成为瓶颈，那我并没有创造三倍的价值，只是创造了更多等待验证的工作。

这就是为什么在 AI 辅助的工作流中，代码行数、commit 数量甚至 pull request 数量这些指标变得不那么有用了。AI 可以非常容易地增加所有这些数据，但未必能提升可靠性或交付速度。

我发现一个更有用的问题是：

一个想法多快能变成生产环境中可靠的软件？

这将焦点从输出转向了结果。

我的工作流正在从写代码转向验证代码

这可能是我个人感受到的最大的变化。

当我手动写代码时，我在写的过程中构建上下文。我知道为什么一个函数存在，为什么我选择这个抽象而不是另一个，以及我在过程中做了哪些权衡。

使用 agent 时，实现可以在我构建相同心智模型之前就到达了。

所以我不再把大部分时间花在问"我应该怎么实现这个？"，而是越来越发现自己问的是：

这个方法适合架构吗？

agent 重用了正确的抽象吗？

测试验证的是真正重要的行为吗？

这个变更引入了不必要的耦合了吗？

六个月后我仍然愿意维护这个东西吗？

我的工作流开始看起来不再像：

flowchart LR
    A[Design] --> B[Write] --> C[Debug] --> D[Review]

而是像：

flowchart LR
    A[Design] --> B[Delegate] --> C[Validate] --> D[Integrate] --> E[Observe]

我不认为这是工程变得不重要了。

我认为这是工程判断力变得比代码生产本身更重要了。

agent 可以快速产生一个实现。但我仍然负责决定这个实现是否属于这个系统。

更快的 agent 需要更强的护栏

我给 agent 的自主权越多，另一个需求就越明显：代码库需要清晰地传达它的规则。

agent 可以生成完全有效的代码，同时仍然做出糟糕的工程决策。它可能复制业务逻辑、绕过现有抽象、引入不必要的依赖、跨包边界，或者创建日后会痛苦的耦合。

其中一些问题会被测试捕获。另一些不会。

这就是为什么我越来越把 AGENTS.md、架构边界、依赖规则、契约测试、静态分析、安全检查和 CI/CD 验证视为 agentic 开发工作流的一部分，而不是单纯的支撑工具。

目标不是添加更多流程。而是让可预测的工程约束变得可被机器验证。

如果 agent 可以在几秒钟内产生一个糟糕的实现，我希望系统能够同样快速地拒绝明显的问题。

这样就能让人类注意力集中在仍然需要判断的事情上：架构、权衡、产品上下文、可维护性，以及我们是否在解决正确的问题。

有趣的部分在 agent 写完代码之后

今天很多关注都放在了哪个 coding agent 产生的代码最好，或者哪个完成任务最快。

我认为这很重要，但我越来越对一个不同的问题感兴趣：

实现生成之后会发生什么？

自动化检查能验证它吗？另一个 agent 能审查 diff 吗？CI 能强制执行架构边界吗？安全工具能识别有风险的变更吗？生产可观测性能告诉我们这个功能是否如预期那样表现吗？

一个更成熟的工作流开始看起来像这样：

flowchart LR
    A[Human Defines Intent]
    --> B[Agent Implements]
    --> C[Automated Validation]
    --> D[AI + Human Review]
    --> E[CI/CD]
    --> F[Production]
    --> G[Observe & Improve]

这就是我认为更大的生产力机会所在。

不仅仅是让 coding agent 更快，而是设计一个能够安全吸收 agent 所创造的速度的工程系统。

这个转变已经在改变我的工作方式。我花更少的时间手动产出每一个实现细节，花更多的时间设计方法、编排 agent、验证决策，以及改进周围的系统。

AI 让写代码变得更快了。

现在工程工作流的其余部分必须跟上。

因为目标从来不是生成更多代码。

目标是更有信心、更快地交付更好的软件。

借鉴了 Red Hat 的《为什么更快的编码并没有让交付变得更快》以及我自己在越来越 agentic 的开发工作流中的经验。