AI 会写代码之后,软件工程师的价值会转移到哪里?

如果有一天，AI 不仅能写代码，还能自己分析需求、设计方案、运行测试，甚至完成部署，我们还需要软件工程师吗？

Coding Agent 的能力不断提高，让这个问题越来越现实。过去需要工程师花几天完成的工作，现在可能只需要向 AI 描述目标，一两个小时后它就能给出结果。

这让不少软件工程师都开始焦虑：如果 AI 写代码都能从头写到尾了，甚至写得比我们还要好，那我们多年积累的知识和技能，还有什么价值？

Katelyn Lesse 在 2026 年 10 月 25 日发表的《The new set of problems for engineers to solve》，他提供了一个值得思考的视角：AI 没有让软件工程师的价值消失，但是这份价值的重心正在改变。

过去，我们的主要工作是亲自设计并实现软件功能；未来，我们可能需要花更多精力，设计能够让 AI 自主、安全、可靠运行的系统。

这不是说写代码不重要，只是单独代码的能力，已经不足以代表软件工程师的全部价值。

刚开始，AI 只是辅助工具：工程师提出问题，AI 给出建议，或者帮忙生成一小段代码。整个开发过程还是由人来主导。

后来，Coding Agent 开始能够独立修改文件、调用工具、执行测试，甚至根据测试结果修复自己的错误。

现在，Agent 正在向长期自主运行和多 Agent 协作发展。一个 Agent 可以负责任务规划，另一个负责开发，第三个负责测试，还有 Agent 专门承担审查和验证工作。

如果我们继续沿着这个方向推演，未来可能出现数百甚至数千个 Agent 长期协作，共同完成复杂的软件开发、科学研究或硬件设计任务。

单个 Agent 的工作能力越强，我们就越需要解决多个 Agent 组成的整个系统如何运行的问题。

比如，怎么为几千个 Agent 分配计算资源？怎么决定它们可以访问哪些数据？怎么防止一个 Agent 的错误影响其他 Agent？如果整个系统偏离了目标，又怎么及时发现并停止？

这些问题不会因为 AI 更擅长写代码就自动消失。AI 能够执行的任务越复杂，它们就变得越突出。

Katelyn Lesse 将这些新挑战归纳为四个方向。分别是：基础设施、身份与权限、安全与隔离、监控与终止。

这些挑战都指向同一个词：信任。是工程师能不能建立一个值得信任的 Agent 工程环境。

我觉得，信任这个词，解释了软件工程师价值正在发生的变化。

我们熟悉的软件基础设施，大多围绕应用和服务来设计。例如 Kubernetes，可以帮助我们部署应用、管理容器、实现弹性扩缩容。

Agent 的运行方式有些不同。传统服务可能长期运行，持续处理请求；Agent 往往需要保存自己的执行状态，又可能长时间等待模型推理、工具调用、其他 Agent 的反馈，或者用户的审批。

如果让每个 Agent 始终占用一个完整的运行环境，系统可能浪费大量计算资源。但如果直接释放资源，又必须解决状态保存、任务恢复和执行隔离的问题。

系统里只有几个 Agent 时，这些问题也许不明显。但当成百上千个 Agent 同时运行，或者突然产生大量并行任务时，资源调度、状态管理、快速启动和故障恢复就会变得十分重要。

Kubernetes 仍然有价值，现有基础设施也需要适应这些新的工作负载。

工程师需要考虑的，既有如何让一个程序运行起来，也有如何让大量自主行动的 Agent 高效、稳定地持续工作。

AI 可以帮助编写这些基础设施的代码，但如何设计运行机制、处理资源约束和保证系统稳定，仍然是需要人来解决的工程问题。

原文讨论的第二个问题是身份与权限，我认为它比基础设施更值得关注。

过去的软件系统，权限关系通常比较清晰：用户登录系统，服务器验证身份，再根据权限决定他可以访问什么、修改什么。Agent 的加入让这层关系变得复杂。

假设你授权一个 Agent 帮你开发项目，允许它访问代码仓库。它为了完成任务，又创建了几个子 Agent，分别负责修改代码、执行测试和管理部署。

主 Agent 可以把你的全部权限交给子 Agent 吗？如果其中一个子 Agent 想删除仓库、修改生产环境，或者访问与任务无关的数据，它是否应该被允许？

如果整个任务持续两周，你在第一天给予的授权，是否意味着 Agent 在两周内可以自行决定所有操作？

还有一个更基本的问题：当系统发现某项操作使用了你的账号时，如何判断这是你亲自执行的，还是 Agent 代表你执行的？

除了身份认证，这里还涉及授权、委托、信任和责任归属。

软件工程已经积累了 OAuth、工作负载身份、短期凭据等技术，但面对长期自主运行、不断分派任务的 Agent，授权机制还需要完善。

过去，我们主要设计人与软件之间的权限关系；未来，还必须设计人与 Agent、Agent 与 Agent 之间的权限关系。

AI 知道怎样调用 API 还不够，系统还得判断它有没有资格执行这次调用。解决这些问题，我们才能放心地把一部分工作委托给 AI。

传统软件也存在漏洞和攻击，而 Agent 带来了新的安全风险：它不仅会读取信息，还可能根据读到的信息决定下一步行动。

例如，一个 Agent 在阅读网页或代码仓库时，遇到了一段恶意构造的内容。这段内容可能试图诱导它改变原本的任务目标，执行不该执行的操作。

如果这个 Agent 还会和其他 Agent 协作，它可能把受到污染的信息传递下去。错误信息还可能被写入共享记忆，影响之后运行的 Agent。一次原本局限在单个任务中的攻击，就可能扩散到整个多 Agent 系统。

这就是原文特别强调的 Blast Radius，也就是影响范围。

我们不可能保证所有 Agent 永远不出错，也不能保证它们读到的内容永远安全，但可以通过工程设计，尽可能限制错误的影响范围。

例如，让 Agent 在隔离环境中运行，限制它能够访问的文件和网络资源，防止它随意使用高权限凭据，并避免不同任务之间的不可信数据相互污染。

过去，我们努力让软件不要出错；面对自主 Agent，我们还必须认真设计它出错之后会发生什么。

错误是否能够被限制在局部？重要数据会不会受到影响？系统能否恢复？

这些问题需要可靠的工程机制来解决。模型能力再强，也不能代替外部安全边界的设计。

原文提出的第四个问题是监控与终止，可能也是最有挑战性的一个。

过去，我们监控软件系统，主要关注错误日志、异常、性能指标以及服务是否正常。

对于长期自主运行的 Agent，仅仅知道系统没有报错已经不够了。它完全可能在技术上运行正常，却正在执行错误的目标。

例如，一个 Agent 在执行任务时，反复尝试访问某个没有被授权的域名。它可能是为了完成任务，一直在寻找可用方案；也可能受到恶意指令影响，正在尝试突破权限限制。

这两种行为在日志中可能非常相似。怎样判断它是在积极解决问题，还是已经偏离了原本的任务？

这要求系统具备更完善的可观测性和控制能力。作者特别提到了跨 Agent 的调用追踪，以及不允许 Agent 自行篡改的日志记录。

当系统发现异常时，还需要具备真正有效的终止机制，不仅停止当前任务，还要能够终止相关 Agent、撤销凭据，防止任务继续扩散。

但停止一个 Agent，并不意味着它之前执行的操作已经被撤销。

例如，它可能已经修改了数据库、提交了代码，或者向外部系统发出了请求。系统怎样确认这些操作的影响？是否需要回滚或补偿？谁来判断任务应该继续还是终止？

这些问题其实与传统软件中的事务、一致性、审计和故障恢复密切相关，只是在 Agent 时代变得更加复杂。

未来的监控系统可能还需要帮助我们判断：系统是否仍在朝着正确的目标前进？ 这已经超出了传统性能监控对“程序有没有正常运行”的关注。

基础设施、权限、安全、监控分属不同的技术领域，但在我看来，它们都在回答一个关于信任的问题。当软件有了更强的自主决策和行动能力，我们怎么能放心地把事情交给它？

过去，我们更多把软件看作按既定逻辑执行任务的工具：工程师设计规则、编写代码，软件按规则运行。现在，AI 可以根据目标，自行选择部分执行路径，不必每一步都由人预先确定。我们需要知道，它会在什么范围内行动，结果能否验证，出错以后又该怎么办。

这份信任需要技术来支撑。基础设施让 Agent 能持续工作，并在中断后恢复任务；身份与权限明确它代表谁、被允许做什么；安全与隔离限制错误的影响；监控与终止机制让我们能发现它是否偏离目标，并及时介入。

第一，从直接生产代码，转向设计和管理代码生产过程。

当 Agent 可以承担越来越多的实现工作时，工程师需要更准确地定义目标、拆解任务、确定验收标准，并建立持续验证和反馈机制。这些检查让我们有依据判断，交付的代码是否可信。

第二，从构建确定性的程序，转向治理具有自主行为的系统。

工程师需要解决身份、权限、执行隔离和协作问题，明确我们在什么范围内信任 Agent。可以把某项任务交给它，同时限制它访问无关数据，以及向其他 Agent 转交权限。

第三，从保证单个功能正确，转向保证整个系统持续可靠。

这包括状态管理、异常检测、故障恢复、可观测性，以及必要时终止整个系统的能力。系统要持续运行，任务也会不断变化。一次成功的交付还不够，我们还得能持续判断它是否值得信任。

做好架构、权限、测试、日志和恢复机制，需要技术积累。我们敢于把工作交给 AI，靠的就是这些具体的保障。

软件工程仍然重要，但是现在的软件工程岗位已经受到了冲击。

如果一项工作的核心价值只是根据明确需求，重复编写常规业务代码，那么随着 AI 能力提高，这部分工作的稀缺性确实可能下降。这也是很多工程师焦虑的真实原因。

如果一个工程师能深入理解复杂系统，设计架构、处理安全与可靠性问题，把不确定的任务变成可验证、可管理的执行流程，他的经验仍然能发挥重要作用。靠这些能力，他能判断一项工作是否可以交给 AI，并说明判断的依据。随着 Agent 自治程度提高，这种建立信任的能力可能变得更加关键。

不过，这些能力也不是人类永远独占的。AI 同样会逐步参与架构设计、验证和运维工作。

因此，工程师不能指望只靠过去积累的技术知识，就获得长期的职业保障。我们需要理解新的工程问题，借助不断进步的 AI，做好支撑信任的技术机制，并验证它们是否有效，能否让我们放心地委托这一次任务。

过去很多年，我们一直在追求更高的软件性能、更丰富的功能和更低的开发成本。

现在，AI 正在让软件获得一种过去很少具备的能力：自主完成复杂任务。但它能自主行动，我们就能放心地把工作交给它吗？

Agent 会写代码，不意味着我们就应该允许它直接部署生产系统；会调用工具，也不意味着它应该拥有所有工具的权限。一群 Agent 能共同完成任务，也未必能安全、可靠地协作。

我觉得，软件工程师不要再思考“怎样才能比 AI 写代码更快”，这已经没有意义。更值得思考的是：当 AI 能做的事情越来越多，我们需要建立怎样的环境，才能放心地把工作交给它？

读完 Katelyn Lesse 对基础设施与可信性问题的讨论，我的理解是：软件工程师的价值正在从亲自实现功能，进一步转向用技术建立信任，让能力越来越强的 AI 持续交付可靠的结果。

未来优秀的软件工程师，未必是亲手写出最多代码的人，也可能是能把这样的系统设计出来的人：大量 Agent 能持续工作，有明确的目标和合理的权限，工作结果也能得到可靠验证。

我是 Yakir，移动端原生工程师，努力学AI、玩AI。