夜雨聆风如果智能体写出来的代码比你更快更好，软件工程会变成什么样子？
它已经部分发生，并且还在继续推进。
这意味着，写代码这件事本身，正在变得越来越便宜、越来越自动化。
那么，软件工程这个行业真正稀缺的能力，究竟是什么？
我觉得，这是今天讨论 AI 编程时最值得认真面对的问题。
过去一年多，很多人已经习惯了让 AI 写函数、补测试、解释报错、生成页面。
代码生成的能力还在快速进步。
SWE-bench 这样的评测，已经把任务从“写一道算法题”推向“在真实代码库里，根据 GitHub issue 修改代码并通过测试”。
METR 也在用“AI 能独立完成多长时间跨度的任务”来衡量模型能力，而不再只看一次回答的质量。
也就是说，AI 编程的讨论正在离开那个最容易展示的阶段。
于是，真正的问题变成了：我们能不能围绕 AI，重新设计一套可靠的软件工程系统。
生产代码，正在从核心动作变成系统输出
传统软件工程里，写代码当然重要。
但只要做过真实项目就知道，写代码从来不是全部。
一个系统能不能交付，取决于需求是否清楚，边界是否合理，架构是否能演进，测试是否覆盖关键路径，代码是否能被团队理解，部署是否稳定，出了问题能不能定位，后续维护是否承担得起。
很多时候，工程里最难的不是“把这段逻辑写出来”，而是知道应该写什么、不应该写什么、写在哪里、和谁协作、用什么方式验证，以及什么时候停下来。
AI 的到来，并没有取消这些问题。
它只是让“写出一段代码”的边际成本快速下降。
当代码生成变得更便宜，软件工程的重心就会自然迁移：从亲手生产每一行代码，转向设计一个能持续、稳定、可控地产生正确代码的系统。
这有点像工业化之后的制造业。
真正重要的，不再是某个工人手工打磨每一个零件，而是生产线、质量体系、供应链、检测流程和责任边界。
在 AI 时代，代码可能越来越像系统的产物。
而软件工程师的任务，是设计那个系统。
智能体的本质是循环
智能体区别于聊天机器人的关键，不是回答，而是行动。
在 OpenAI 的工具调用文档里，tool calling 被描述为一个多步流程：模型拿到可调用的工具，返回一次工具调用；应用侧执行这次调用；再把工具结果送回模型，让模型继续生成回答或发起更多工具调用。
Anthropic 在讲 agent 时，也用了一个很朴素的定义：agent 是“LLM 自主地在循环中使用工具”。
一个 coding agent 工作时，它通常会先读文件，理解项目结构；再修改代码；然后运行测试；如果测试失败，就读取报错、继续定位、继续修改；最后查看 diff，总结变更，等待人类审查。
这个过程的本质是一个循环：
判断下一步要做什么，调用工具，读取结果，再判断下一步。
模型负责提出意图，执行框架（harness），负责执行意图，工具负责完成具体动作，执行结果再回到上下文里。
所以，AI 时代的软件工程，更重要的是设计这个循环回路。
工具怎么暴露？权限怎么控制？上下文怎么组织？失败怎么恢复？什么时候让 agent 自己继续，什么时候必须停下来找人确认？这些问题，才是 agent 真正进入工程现场之后绕不开的部分。
新的软件工程能力：上下文、工具和验证
当智能体开始参与真实开发，工程师要关心的能力会发生变化。
第一是上下文工程。
人写代码时，不只是靠脑子里的语言语法。我们会看目录结构、读 README、翻历史提交、查测试、看日志、问同事、理解团队约定。
agent 也一样。
如果它不知道项目的边界、不知道团队的命名习惯、不知道哪些接口不能动、不知道上周刚发生过一次事故，它就很难稳定做出正确判断。
所以，未来的软件工程里，很大一部分工作会变成：怎样把正确的信息，在正确的时间，以合适的粒度交给 agent。
不是把所有东西一股脑塞进上下文，而是让 agent 能按需检索、按需读取、按需行动。
第二是工具设计。
Anthropic 有一句话说得很直接：agent 的能力取决于我们给它的工具。
这句话放在软件工程里尤其明显。
一个只能“生成文本”的模型，和一个能读文件、跑测试、查日志、搜索文档、创建分支、提交 PR、调用内部平台的 agent，完全不是同一个生产力形态。
但工具越多，不代表系统越好。
工具太散、边界太糊、返回结果太长，都会让 agent 更难判断下一步。真正好的工具，不只是能完成动作，还要能返回有用、紧凑、可验证的上下文。
第三是验证体系。
当 agent 能写更多代码，测试、审查、评估、回滚会变得更重要，而不是更不重要。
因为生成速度越快，错误扩散的速度也越快。
过去，一个工程师一天写不了太多代码，人的速度本身就是某种天然限流。
未来，如果一个团队同时运行多个 coding agent，系统每天产生的变更量会显著增加。
这个时候，团队真正的瓶颈可能不再是“谁来写”，而是“谁来判断这些变更能不能进生产”。
这也是为什么 OpenAI 的生产和安全实践文档里，会强调从原型走向生产时要考虑访问控制、监控、成本、测试、安全和 human-in-the-loop。
尤其在代码生成场景里，人类审查仍然很关键。
所以说，AI 时代，软件工程本身变得更重要。
工程师不会消失，但价值位置会迁移
如果 agent 能承担越来越多实现工作，工程师还重要吗？
我认为会更重要，只是重要的方式变了。
过去，一个工程师的价值很大程度体现在“生产代码”。未来，这仍然重要，但可能不再是唯一核心。
更重要的问题会变成：
这个任务应该怎样描述，agent 才能理解？
哪些上下文必须提供，哪些上下文会干扰判断？
哪些工具应该开放，哪些操作必须加审批？
怎样设计测试，让 agent 的产出可以被快速验证？
怎样把一次成功的 agent 协作，沉淀成团队下一次可复用的流程？
怎样让非技术人员也能在安全边界内提出需求、验证结果、推动交付？
这些问题，本来就是软件工程的一部分。
甚至可以说，它们更接近软件工程的本质。
软件工程的核心，是在多人、多变、长期演进的环境里，把软件可靠地做出来。
过去，人是这个过程里最主要的执行者。
现在，agent 正在进入执行层。
于是，人类工程师的角色会越来越像系统设计者、上下文组织者、工具链建设者、质量守门人和协作流程的设计者。
工程师不是退出软件生产，而是从“直接生产代码”，迁移到“设计软件生产系统”。
重新定义软件工程
所以，AI 时代的软件工程到底会怎样被重新定义？
我的理解是：
软件工程会从“组织人写代码”，逐渐变成“组织人与智能体共同交付软件”。
它会具体体现在每一个工程环节里。
需求不再只是写给人看，也要写成 agent 能执行的任务。
文档不再只是事后说明，也会变成 agent 工作时的重要上下文。
测试不再只是质量保障，也会变成 agent 自我修正的反馈信号。
CI/CD 不再只是部署管道，也会变成 agent 行动边界的一部分。
代码审查不再只是检查人写的代码，也会变成管理机器生成变更的治理机制。
工具链不再只是辅助开发者，而会成为 agent 能力的外骨骼。
如果说过去的软件工程，核心问题是“如何让人类团队协作写出可靠软件”，那么 AI 时代的软件工程，核心问题会变成：
如何设计一套系统，让人和 agent 能够安全、稳定、可持续地共同交付软件。
这就是“重新定义软件工程”的含义。
它不是说编程不重要了，而是说，编程正在被放进一个更大的系统里。
未来真正稀缺的，是谁能定义问题、组织上下文、设计工具、建立验证，并把智能体的能力接入真实的工程流程。
AI 没有让软件工程消失，而是把软件工程从“代码生产”，推向“智能协作系统的设计”。
而这，可能才是软件工程真正变得更大的开始。