软件工程的终结：代码正在成为运行时产物
标题听起来像是一个预言：软件工程即将结束。
我的读法比较保守，也比较有用。这篇论文并不是说工程学消失了。更准确地说，耐久工程的中心可能会移动。在传统软件中，代码库是系统的长期主体。在智能体软件中，一些代码会变成运行时产物：在更大的推理循环中生成、执行、检查和丢弃。
这并没有结束工程。它改变了必须设计的内容。
浅读
浅读是：
AI writes code, so programmers matter less.这个框太小了它仍然将代码想象为最终对象，仅由不同的参与者生成。
更强的框架是：
Some decision logic moves from static code into a runtime agent loop.然后，长期资产成为使循环可靠的东西：任务规范、工具、内存、策略、评估、跟踪、权限边界和人工审查点。
从软件对象到交付结果
这篇论文描述了从本地软件到 SaaS，再到智能体即服务的历史演变。
方向不仅仅是“更多云”。这是一种更深层次的复杂性外包：
| 时代 | 用户购买 | 供应商携带 |
|---|---|---|
| 本地软件 | 已安装的对象 | 有限的更新和支持 |
| SaaS | 维护服务 | 基础设施、部署、升级 |
| 智能体即服务 | 结果循环 | 规划、工具使用、执行、验证 |
在最后一帧中，用户可能不关心特定脚本是否存活。用户关心智能体在变化的条件下是否能够持续产生期望的结果。
这就是这篇论文变得有趣的地方。如果代码有时是一个临时工具，那么问题就不再只是“代码优雅吗？”这也是“循环能否选择正确的工具、验证结果、从故障中恢复并保留有用的状态？”
什么变得持久
如果生成的代码不太持久，则必须有其他东西来保持连续性。
明显的候选人是：
- 内存：系统保留有关用户、项目、故障和偏好的内容。
- 工具：智能体可以安全调用的稳定操作。
- skill：模型权重之外的可重用程序和约束。
- 评估：可接受结果的长期定义。
- 可观察性：跟踪、日志、重播和解释。
- 治理：许可、审计、审批、回滚和策略。
这些不是模型周围的装饰。它们是工程表面。
证据是定向的，而不是最终的
这篇论文的证据支持该方向，但并不能证明最终状态。
智能体修复孤立问题的基准显示出明显的进展。与此同时，持续的软件进化仍然更加困难：上下文变得陈旧，错误累积，测试偏离意图，长期工作需要记忆和治理。这种对比才是真正的教训。智能体已经可以在有强烈反馈的有界任务中发挥作用。当任务是长期的、跨领域的并且依赖于模糊的产品判断时，他们就不太成熟。
因此，我不会将路线图解读为“我们已经处于自我进化的生态系统”。我会将其视为缺失基础设施的地图：
tool-augmented work
-> single-task autonomy
-> multi-agent teams
-> self-evolving systems第二阶段和第三阶段之间的差距不仅仅是模型能力。它是角色设计、共享记忆、评估、可观察性和人类治理。
新的工程工作
这篇论文最好的短语不是标题。这是角色转变：工程师成为意图架构师、智能体协调员和结果审计员。
这听起来很抽象，所以我把它转化为具体的工作：
- 编写能够在与混乱的 repo 接触后仍然存在的目标；
- 公开带有类型边界的安全工具；
- 设计有帮助且不会污染上下文的内存；
- 构建捕获回归的评估；
- 创建使故障可检查的痕迹；
- 决定哪些行动需要人工审批；
- 保持压缩重复练习的 skill。
所有这些都比编写代码技术含量低。它是不同层面的技术。
我的收获
有用的主张并不是软件工程的终结，而是代码可能不再是唯一值得组织的持久产物。
如果智能体可以按需生成代码，那么稀缺资产就变成了运行时，告诉它生成什么、何时信任它、如何测试它、如何记住结果以及何时寻求帮助。
这样这篇文章成为智能体构建者的一个很好的概念图。未来可能包含更少的手工维护样板，但需要对意图、工具、skill、记忆、评估、可观察性和治理进行更仔细的设计。