当 AI Agent 能在几分钟内生成一个接口、一套测试和一份部署配置，开发者很容易产生一种焦虑：我还要怎样提高编码速度，才能跟上它？
我的判断是：开发者应该把竞争重点转向问题定义、系统设计、技术判断，以及对交付结果的负责。编码速度仍然影响工作效率，但它越来越难成为独立的竞争优势。
更深的变化在于，软件开发的价值分配正在受到影响。同样使用 AI，有人能够承担更大的工程范围，有人却可能发现，自己熟练完成的任务不再那么稀缺。
要理解这种分化，可以使用 ESC 框架：E（Event，事件）看发生了什么；S（Structure，结构）看背后的机制；C（Cognition，认知）看我们应该怎样调整判断与行动。这里把它作为分析工具，不把它当作预测就业的模型。
E：从明确需求到代码，正在变得更便宜
AI 编程最值得关注的变化，是把相对明确的需求转成代码所需的人工投入，在越来越多的任务中下降了。
传统开发中，人主要负责编写、测试和部署。引入编程助手后，人设计方案，AI 提供代码建议，人审查修改。进一步使用 Agent 时，人定义目标与约束，Agent 在权限范围内实现、运行测试并迭代，人验证最终结果。
这几种工作方式会长期共存。对于需求模糊、上下文缺失或者难以验证的任务，自动化程度仍然受到限制。
采用率说明这种变化已经进入日常工作。Stack Overflow 2026 年开发者调查中，回答相关问题的 17,464 人里，65.9% 表示在工作中使用 AI 编程助手或编码 Agent；这类工具的用户中，73% 表示每天使用。[1]
这些是自报使用情况，不能解读为效率提升幅度，也不能直接代表所有开发者。
项目交付速度还取决于审查、集成和返工。METR 的 2025 年随机对照实验让 16 名熟悉各自开源项目的开发者完成 246 项任务，结果是允许使用当时的 AI 工具后，完成时间平均增加了 19%。这个结果适用于实验中的人员、任务和工具，不能推广到所有 AI 开发场景。[2]
2026 年 2 月，METR 报告后续实验受到参与者与任务选择偏差，以及并行使用 Agent 时工时记录困难等影响。研究者认为工具带来的加速可能比早期更大，但数据不足以可靠估计改善幅度。[3]
因此，需要同时观察代码生成和完整交付。它们的速度可能不同。
S：实现成本下降，瓶颈会移动
把软件开发看作一个生产系统：需求确认、实现、验证、集成、上线，每个环节都可能限制交付。
注意下图橙色的验证环节。蓝色实现通路提速后，如果验证能力没有跟上，候选变更就会在这里堆积。图中表示的是机制，不是行业实测比例。
实现提速后，验证能力可能成为限制交付的瓶颈（概念示意）。
这可以推导出四种值得关注的结构变化。
第一，常规实现的稀缺性下降。 常见增删改查接口、样板代码、配置文件和测试骨架，往往更容易由 AI 生成。熟练完成这些任务仍然有用，但相同产出的获得成本下降后，这项能力单独带来的议价优势可能减弱。
这里不能把“能够生成”直接等同于“能够替代岗位”。岗位通常包含需求沟通、集成、维护和风险处理，多项任务会一起变化。
第二，选对问题的重要性提高。 如果 Agent 可以快速实现五个方案，我们更需要知道哪个方案值得投入。是否解决了真实需求？有没有更简单的办法？新增功能能否覆盖长期维护成本？这些问题决定代码是否有价值。
第三，验证可能成为新的主要瓶颈。 人很难逐行审查大量生成代码。测试、安全检查、运行观测和清晰的验收标准，需要共同承担验证工作。让另一个 Agent 审查可以提供额外线索，但多个 Agent 也可能共享相同盲点，不能把相互同意当作正确性的证明。
第四，评价工程工作的方式可能改变。 当代码产量更容易增加，可靠性、交付周期、用户价值和运行成本就更值得衡量。提交数量能够反映活动，却无法单独说明成果。
这些变化并不保证每位开发者都受益。企业可能减少某些以实现为主的工作需求，也可能利用更低成本开发过去不值得做的软件。最终岗位数量取决于需求增长、组织选择与自动化范围，不能仅凭编码速度预测。
更稳妥的结论是：当一种产出更容易获得，开发者需要重新判断，交付链条里还有哪些约束没有被解决。
C：把能力建设放到完整交付链条上
从代码实现者走向系统负责人，意味着扩大对问题和结果的理解范围。它不要求每个人立刻担任架构师，也不意味着一个人承担整个团队的责任。
可以从一项边界明确的任务开始：你能否说清为什么要做、什么叫完成，以及出现问题时怎样发现和恢复？
我会优先练习五项能力。
问题定义： 把“优化性能”写成具体场景、约束和验收条件。先确认慢在哪里，再决定是否改代码。
系统设计： 理解组件之间的关系，以及一致性、容量、权限和成本上的取舍。局部代码合理，并不保证整体系统可靠。
Agent 工作流设计： 提供必要的仓库上下文，拆分可验收任务，明确工具权限和停止条件。多 Agent 只有在任务可独立开展时才可能带来收益，也会增加协调成本。
验证： 为关键行为设计可执行检查，覆盖正常流程、失败路径和回归风险。测试通过以后，还要确认测试是否覆盖了真正的业务要求。
产品判断： 根据用户需求和维护成本决定做什么、暂缓什么，以及什么时候停止投入。
编程基础仍然重要。不了解并发、事务、网络和权限，就很难识别 Agent 生成的方案会在哪里失败。减少手工实现，需要更多有效判断，而不是放弃技术理解。
对于初级开发者，可以让 Agent 解释代码，再自己追踪一次真实请求、修改一个边界条件、复现一次失败。这样既能使用工具，也能保留建立判断力所需的实践。
用告警治理举例：谁对漏报和误报负责？
以 DevOps、SRE 和可观测性工作为例。Agent 可以帮助编写 PromQL、生成 Grafana 面板、修改 Helm 配置，并提出告警规则。但一份语法正确的规则，不一定能发现影响用户的故障。
假设我们想为一个服务补齐告警覆盖。下面是一个可尝试的设计示例，尚不是经过生产验证的方案。
先确定关键用户路径和服务依赖，再选择服务级别指标（SLI），例如请求成功率或延迟，并明确服务级别目标（SLO）。Agent 根据这些上下文生成候选规则。
随后，把规则放到历史指标和已知事故中回放，检查是否漏掉重要故障，以及是否产生过多无意义告警。历史回放也有局限：它不能覆盖从未发生过的故障，需要补充边界测试或故障演练。
下图从上方的蓝色入口开始，沿主通路到发布后观测。右侧回路表示：无论测试失败，还是上线效果不达标，都应该回到规则修改，而不是继续增加规则数量。
告警规则必须经过验证与上线观测，失败结果应反馈到修改环节（流程设计示意）。
验证通过后，Agent 可以准备包含测试证据的配置 PR。团队审查变更，再按既定流程上线，保留回滚办法。上线之后，还要观察误报、漏报和实际处理效果。
自动化的权限应与后果相匹配。读取数据、生成候选方案和提出变更可以有不同的权限；涉及生产修改时，需要明确授权边界和审计记录。
工程师的价值体现在这条链路中：判断哪些用户体验值得保护，确定证据是否足够，选择可接受的风险，并持续改进结果。Agent 承担实现工作，团队仍然需要明确的责任归属。
用 90 天完成一次小范围转型
不必一开始就搭建庞大的 Agent 平台。选择一个真实、重复、可验证的任务，逐步扩大范围。
第 1—30 天：把 Agent 用进日常任务。 练习描述目标、补充仓库上下文、定位错误和验收结果。记录人工投入、返工和遗漏，找出哪些任务适合委派。目标是稳定交付通过验收的任务，而不是生成更多代码。
第 31—60 天：形成可重复工作流。 例如，从发现告警覆盖缺口，到生成规则、执行检查，再到准备 PR。把一次成功整理成明确步骤，加入失败停止条件和权限边界。先把一个流程跑通，再考虑并行。
第 61—90 天：验证一项实际改善。 在一个服务或团队中试用，选择少量指标：交付周期、上线后缺陷、告警质量、平均恢复时间（MTTR）或运行成本。记录口径、基线和同期变化，避免把流量下降或业务调整带来的改善归功于 AI。
衡量进步时，可以问：在相近的任务范围和质量要求下，同样的人工投入，是否交付了更多经过验证的有价值工作？
这是一种观察思路，不是统一的行业指标。质量要求改变了，前后数据就不能直接比较。人力节省之外，还应记录模型、工具和后续维护的成本。
如果 AI 也擅长架构和判断呢？
“转向系统设计”不能成为一劳永逸的职业答案。Agent 也可能继续提高架构、调试和验证能力，今天稀缺的技能，明天未必仍然稀缺。
这也是 ESC 的价值：分析完一次变化，还要继续追踪下一次变化。
事件层，我们观察哪些任务变得更容易。结构层，我们检查交付瓶颈与价值分配如何移动。认知层，我们调整自己的学习和工作方式。
业务上下文、组织信任和结果责任，目前仍然影响方案能否真正落地。但这些因素也不是人的永久护城河，更不能被用来保证某类岗位不会变化。
开发者更可持续的优势，是持续学习新工具，理解实际系统，用证据做判断，并在变化中找到值得解决的问题。
可以从下一张工单开始：在让 Agent 动手之前，先写清它解决谁的问题、有哪些约束，以及用什么证据确认完成。这一步很小，却已经把注意力从代码产量移向了交付价值。
参考资料
[1] Stack Overflow 2026 Developer Survey：AI 原始数据
[2] METR：2025 年 AI 对资深开源开发者生产率影响的随机对照研究
[3] METR：2026 年 2 月开发者生产率实验设计调整