过去一年，Coding Agent 的能力提升得很快。
以前需要工程师自己查代码、补上下文、写实现、跑测试的任务，现在有越来越多可以交给 Agent。简单功能几十分钟就能拿到第一版，复杂任务也可以拆开，让多个 Agent 同时推进。我们衡量 Coding Agent 时，也越来越习惯看任务完成率、PR 数量、修改规模和整体耗时。
这些指标都在说明一件事： 写代码这件事，确实越来越快了。
但开发者的工作体验，并没有跟着一起变轻。
State of Devs 2026 调查了 5,463 名开发者。在关于科技行业的情绪选择中，排在第一位的是 Exhausted，疲惫 。4,484 名回答心理状态问题的开发者里，2,943 人表示最近对工作的动力或兴趣下降，2,700 人对工作或行业更消极，2,553 人在一天工作结束后感到情绪耗尽。
图注：State of Devs 2026 数据图
调查里还有一个问题：AI 工具有没有改善自己的心理状态？大约 46% 的回答者选择了否定，明确认同的只有约 23%。
当然，开发者感到疲惫，原因远不止 AI。裁员、管理、薪资、职业安全感、工作生活平衡，都可能影响这种感受。
但如果把这些数据和 Coding Agent 这一年的变化放在一起看，会出现一个挺有意思的反差：
代码写得越来越快了，开发者一天里需要处理的事情，却没有明显变少 。
代码生成速度提升后的瓶颈
软件开发本来就是一条连续的链路。
从理解需求、确定方案，到写代码、调试、测试、Review，再到最后合并上线，每一步都要花时间。过去，写代码本身占了其中很大一部分，所以很多开发工具做的事情，其实都很明确：让实现这一步更快。
从 IDE、代码补全、各种框架，到现在的 Coding Agent，这条路线一直在往前走。
只是 Coding Agent 又把速度往前推了一截。它可以自己读代码库、改多个文件、执行命令、补测试，复杂一点的任务甚至可以连续跑上很久。很多过去需要工程师亲手完成的工作，现在变成了先把目标交代清楚，再等 Agent 把结果交回来。
乍看之下，人的时间应该被省出来不少。但问题在于，开发流程里其他环节并没有跟着一起变快。
Agent 把代码写出来之后，需求有没有理解偏，方案能不能放进现有架构，改动会不会影响别的模块，测试够不够，最后能不能合并，这些判断依然要有人来做。
以前一个工程师可能花两个小时写代码，再花半小时 Review。现在 Agent 二十分钟就能给出结果，但后面的检查并不会自动缩短。改动越大、涉及的文件越多，人需要重新理解和确认的东西甚至还会更多。
图注：Agent 并行、人的判断汇聚
如果同时跑多个 Agent，这种感觉会更明显。Agent A 在改接口，Agent B 在补测试，Agent C 在修另一个 Bug。它们可以同时往前跑，但等结果回来之后，最后还是会一起堆到人这里。
Agent 可以并行，人的注意力却很难并行。
所以现在真正发生变化的，可能不只是“写代码变快了”。开发里的瓶颈也在跟着往后移。过去更花时间的是实现，现在越来越多时间开始耗在 Review、验证和判断上。
换句话说， 代码产出的速度在提高，人的判断能力正在变成新的限制条件。
正在占用注意力的Agent 结果
这也是 Coding Agent 和过去很多开发工具一个比较明显的区别。
代码补全提高的主要是局部效率。工程师仍然在完整的执行过程中，只是写得更快、查得更快、改得更快。Agent 往前走了一步，它开始替人完成一整段任务。这也意味着，人的工作内容跟着变了。
以前，一个工程师花两小时写一个功能，大部分时间都在持续处理同一份上下文：需求是什么、代码为什么这样写、前后逻辑怎么衔接，这些信息一直握在自己手里。
图注：从执行负担到认知负担
现在，同样两小时里，他可能先后收到几个 Agent 的结果。一个改了接口，一个动了测试，一个重构了模块。每接过一个结果，都要重新确认它为什么这样改、涉及哪些文件、测试覆盖了什么，还有没有遗漏边界情况。
代码出来得更快了，但理解改动、补回上下文、判断风险这些事情，并不会一起消失。
而且，Agent 越能独立完成任务，这种变化越明显。
如果它只是帮你补十行代码，你基本知道每一步发生了什么。可如果它自己跑了一个小时，改了几十个文件，最后只告诉你“任务完成”，那你面对的就不再是一小段生成代码，而是一整份需要重新读懂的修改。
这也是为什么现在很多 Coding Agent 产品越来越强调 Plan、Diff、Checkpoint、Review、Execution Log，以及整个任务过程能不能被追踪。
Agent 能不能把任务做完当然重要。
但任务做完以后， 人还能不能快速看懂它做了什么，同样重要 。
节省不下来的开发时间
除此之外，还有一个更现实的问题：Agent 省下来的时间，未必真的会空出来。
如果一个团队原来一周能完成 10 个任务，用上 Agent 之后可以完成 15 个，这部分效率提升很快就会被写进下一轮计划、排期和目标里。等到新的节奏跑顺之后，15 个任务也可能变成新的常态。
所以，单个任务变快，并不意味着人的工作时间会跟着减少。更多时候，同样的一天里，会被安排进更多事情。
State of Devs 在关于 AI 的开放回答里，也收集到了类似的担忧。一些开发者提到，AI 提高生产率之后，公司对交付速度和产出的预期也会继续往上走。
这种变化其实很好理解。
如果一个工程师以前一天能完成两个任务，现在借助 Agent 可以完成四个，团队更容易记住的是“现在一天能做四个”，而不是“原来两件事做完之后，剩下的时间可以空出来”。
时间一长，工具带来的效率收益就会变成新的工作节奏。
图注：工作密度循环
接下来发生的事情也很自然：Agent 缩短了单项任务的耗时，团队开始同时推进更多任务；任务一多，Review、沟通和判断也跟着增加；最后，同样的一天里，开发者需要处理的信息和决策反而更多了。
任务确实变快了，但工作也变得更密。
被拉满的决策带宽
如果顺着这个变化继续往下看，Coding Agent 对开发工作的影响，可能远不只是让人少写一点代码。它也在重新分配开发者一天里的时间。
以前，很多时间花在具体实现上；现在，越来越多时间开始转向任务拆分、上下文准备、Review、测试、验证和异常处理。开发者的工作，也逐渐从亲手完成每一个步骤，变成确定任务怎么做，再判断 Agent 给出的结果能不能接受。
这也解释了为什么现在很多 Agent 系统开始把能力往代码生成之外扩。
自动测试负责先筛掉一部分明显问题，Eval 帮助判断结果质量，规则检查提前拦截不符合要求的操作，Sandbox 和权限控制限制 Agent 能做什么，任务规划和 Subagent 再把复杂任务拆开继续执行。
这些能力表面上都在让 Agent 更自主，但站在开发者的角度看，它们其实在解决同一个问题： 尽量减少那些必须停下来等人判断的节点 。
如果 Agent 每完成一步都要回来问一次“接下来怎么办”，那代码写得再快，整个流程还是会频繁卡在人这里。真正能持续跑起来的 Agent 系统，需要自己处理更多边界清楚、风险较低、结果可以验证的事情，只把少量真正需要取舍的决策留给人。
所以以后看 Coding Agent，可能也不能只看它一次能写多少代码、能连续跑多久。另一个更值得看的指标是： 它到底让人少看了多少结果、少确认了多少步骤、少切了多少次上下文 。
图注：Agent 工程降低决策次数
从这个角度看，Coding Agent 之间的差距，最终可能会越来越体现在一件事上： 谁能把更多判断留在系统内部，把人的注意力留给真正需要人的地方 。
稀缺的注意力资源
State of Devs 2026 里，“Exhausted”排在开发者行业情绪的第一位。
一份调查当然无法说明这种疲惫具体来自哪里，也很难证明 Coding Agent 在其中占了多大比重。但它提醒了一个容易被生产率讨论忽略的问题：
我们一直在看 Agent 能不能做得更快、改得更多、跑得更久。接下来，也许更该问一句： 人一天到底能接住多少 Agent 的结果 ？
Agent 可以继续增加，Token 可以继续变便宜，代码产出也还能继续提速。但人的注意力不会按同样的速度增长。开发者依然要理解问题、检查结果、做出判断，并为最终结果负责。
所以以后衡量一个 Agent 系统，除了看它写了多少代码，也可以看看它替人省掉了多少判断、多少上下文切换，以及多少原本必须亲自介入的工作。
毕竟，真正决定工作有没有变轻的，还是一天结束之后， 人还需要处理多少事情 。
参考资料
- State of Devs 2026：2026.stateofdevs.com/en-US/
