先看证据
一篇讣告，悼念的不是职业
Jeremy Scheff 在 2026 年 10 月 8 日发表个人随笔《My obituary for programming》，写的是 AI 编程代理进入日常开发后，他对程序员工作的感受变化。Simon Willison 于 10 月 19 日转述并评论了这篇文章。Scheff 面对的并非“代码还能不能写”的抽象问题，而是代理开始接手那些过去由程序员亲自解决的工程任务之后，编程这份工作还剩下什么。
Scheff 回忆，编程曾像一连串能创造实际产品的逻辑谜题：客户提出问题，程序员不仅找出解法，也决定策略、时间表和实现边界。这里的“讣告”因此更像对一种工作体验的悼念，而不是宣告程序员职业已经消失。它值得技术负责人读，是因为效率提升和工作满足感下降并不矛盾，甚至可能同时发生。
改变的是工作分工，而不只是打字速度
Scheff 描述的代理用法很具体：把 bug 报告或错误日志交给它，让它定位并修复问题；让它优化性能；或者让它处理过去搁置的大规模重构。材料没有交代代理采用什么模型、内部如何推理，也没有给出可复用的底层技术方案。因此，文章能说明的是工作分工如何变化，而不是代理具体靠什么机制完成这些任务。
当代理承担排错、优化和重构，程序员仍需要决定要解决什么问题，并判断交付结果是否合格；但亲自一步步推导方案的部分可能变少。换句话说，变化不只是“更少手写代码”，而是工作重心从直接解题，向问题界定、目标选择和结果判断移动。对工程团队来说，这意味着代理带来的收益不能只用代码产出量来描述，也要看它接走了哪些原本由人承担的任务。
提速数字能证明什么，又不能证明什么
Scheff 用自己的项目说明代理可能带来的工程收益。在 ZenGM 的四款游戏模拟中，他报告的速度分别达到原来的 1.84 倍、1.98 倍、1.88 倍和 1.98 倍，整体接近两倍。另一项案例是 JSON 流处理库，发布说明称其典型用法提速约三倍。这些数字让“代理能帮忙做优化”不只是一个空泛设想，而有具体项目作为依据。
但证据的边界同样明确：这些是作者项目中的案例，不是不同代码库、任务和团队上的普遍结论。提速也回答不了程序员是否更享受工作，或职业是否会消失。文章没有提供就业数据，也没有独立评估这些代理任务；因此，不能把局部性能收益直接外推成行业层面的职业判断。对负责人而言，首先应把这些数字视为值得在本团队验证的线索，而非预先保证的回报。
同一项效率，对不同程序员是两种结果
Scheff 原本不急着使用编程代理，因为他喜欢亲自写程序；后来看到同行不再逐行写代码，也看到非程序员完成过去难以完成的项目，才开始尝试。Willison 的评论补上了另一种偏好：如果开发者更看重建成可用系统，而不太在意解决途中亲手解题，LLM 就可能是持续带来帮助的工具。两种反应并不冲突，它们指向的是工作回报的差异。
对重视交付的人来说，代理能处理拖延的重构、修复错误或提升性能，腾出精力去完成更多目标；对把解谜本身视为乐趣的人来说，同样的自动化可能抽走工作中最有吸引力的一段。这不是简单的“拥抱”或“抵制”技术，而是要看团队里谁在做什么、他们最看重工作的哪一部分。若只追踪完成速度，管理者可能会看见产能提升，却错过任务体验已经改变。
把任务交给代理之前，先说清楚要保留什么
这篇随笔提供的不是一套代理部署指南，而是一个评估盲点：同样的任务转交，既可能消除积压，也可能减少工程师亲自解决问题的机会。团队可以先把排错、性能优化和积压重构列为代理辅助的候选任务，再观察交付是否改善，同时讨论哪些工作仍希望由工程师亲自完成。这里需要判断的不是“要不要用代理”这一道总开关，而是哪些环节值得自动化、哪些环节本身就是团队培养判断力和获得满足感的来源。
现有材料不能告诉我们，不同开发者对这种变化的感受有多普遍，也无法判断某个团队是否会因此更有效率或更满意。它足以支持的结论要窄得多：局部提速是真实案例，但不足以证明职业终结；自动化交接也可能改变工作的乐趣分布。技术负责人可以把代理收益和人的体验放在同一张评估表上，而不是把“更快”当作完整答案。