夜雨聆风AI 不会替代软件工程师
真正被 AI 改变的不是“写代码”这件事，而是工程师如何决定、验证和承担结果。
最近一段时间，“AI 会不会替代程序员”又被反复拿出来讨论。
如果只看代码生成速度，这个问题似乎已经有答案：模型越来越能写，Agent 越来越能跑，很多局部任务确实被压缩了。
但如果把软件工程当成一个完整系统，答案会变得不一样。
写代码只是其中最容易被看见的一段。真正决定软件价值的，往往发生在代码之前和代码之后。
代码不是唯一瓶颈
Arvind Narayanan 和 Sayash Kapoor 的判断很直接：目前还没有足够证据支持“AI 能力跨过某个阈值后，软件工程会出现大规模失业”。
一个值得注意的细节是，纽约州在 WARN Act 裁员申报中加入了 AI 披露选项。第一年 160 多家公司提交通知，却没有一家勾选“AI 相关”。
这不能证明 AI 对就业没有影响，但至少提醒我们：现实世界比“模型能力曲线”更慢、更复杂。
企业不会因为模型能写函数，就自动解散工程团队。
因为多数工程问题不是“缺少代码”，而是：
需求到底是什么； 现有系统能不能承受； 交付后谁来验证； 出问题后谁来负责； 业务、用户和技术约束之间如何取舍。
这些部分不只是信息处理，更是组织判断。
工程师的工作正在被重新切分
AI 最先吞掉的是低上下文、低责任、可验证的小任务。
比如补测试、改样式、写脚手架、查 API、生成迁移脚本。这些任务适合交给 Agent，因为目标明确、边界清楚、失败成本可控。
但越靠近真实业务，事情越难自动化。
一个工程师真正值钱的地方，常常不是知道某个语法，而是知道：这段代码为什么存在，谁依赖它，哪些历史债务不能碰，什么指标会被影响，以及团队愿意承担多大风险。
这就是 Simon Willison 提到的“deep human understanding”：对代码库、业务和环境的深层理解。
AI 可以帮你更快抵达答案，但很难替你拥有上下文。
AI Coding Agent 的机会，不是替代人，而是放大责任
今天的 Coding Agent 更像一个高效率执行层。
它可以把一个清楚的意图转成多个候选实现，也可以帮你快速定位错误、生成验证脚本、整理变更说明。
但它并不会自动知道“什么才是好结果”。
所以工程师的工作会从“亲手敲每一行代码”，转向：
把模糊问题拆成可执行任务； 给 Agent 足够准确的边界和上下文； 设计验证路径，而不是只看输出是否像答案； 对最终合并、上线和影响负责。
这意味着工程师不会消失，但不愿意做判断的人会变得危险。
对团队的实际启发
如果你在带技术团队，不要只问“这个工具能不能省人”。
更应该问三件事：
我们有哪些任务可以被 Agent 稳定接手？ 哪些环节必须保留人工判断和责任人？ 我们有没有把验证、回滚、审计做成流程？
AI 提高产能的前提，是组织把问题描述和结果验证做扎实。
否则，更多代码只会带来更多不可解释的系统风险。
结尾
软件工程的重心正在上移。
未来更稀缺的不是“会不会写代码”，而是能不能定义问题、理解上下文、验证结果，并愿意为交付承担责任。
AI 会替代一部分编码劳动，但不会替代真正的软件工程判断。
参考资料
Simon Willison: Why AI hasn’t replaced software engineers, and won’t Arvind Narayanan and Sayash Kapoor: Why AI hasn’t replaced software engineers, and won’t
