朋友发给我一张图片，乍看之下是奥莱利的动物书的封面，还以为他是想给我分享一本好书.
结果一看名字是The End of Software Engineering, 软件工程的终点，然后配合底”编程/技术/人工智能“标签，然后中间那个动物呢，是一头趴在地上有些生无可恋的野猪（希望它还没有死）。
最讽刺的是中间的文本：“A practical beginner’s guide to starting a career in plumbing. Learn the essential skills and tools to become a confident plumber.”（一本关于开启水管工职业生涯的实用初学者指南。学习基本技能和工具，成为一名自信的水管工。）
这就是在程序员圈子里面一直流传着一个自嘲的段子，如果35岁被裁员了，就转行去修水管，或者是送外卖，开滴滴铁人三项。AI虽然能够写代码，但是现实世界的这种体力工作，如修水管啊，这些还是很难被AI替代的（其实像送外卖这个AI其实是很容易替代的）。
所以这个封面肯定是一个抽象的，虚构的的一本书，不是正经的指南。
为什么会有这张图呢？确实是因为最近关于软件工程终结的话题被持续讨论。
我找到一些文档资料，主要是一篇名为“The End of Software Engineering”的论文、DeepSeek 机器学习系统工程师刘胜与的文章《我不得不把才华埋葬在昨天》，以及一些社交媒体的讨论。
-
The End of Software Engineering:How AI Agents Are Fundamentally Restructuring the Software Paradigm
-
Software engineering may no longer be a lifetime career | Hacker News
软件工程正在终结 / 传统范式被根本性颠覆
1. 从第一性原理看，传统软件工程已触及认知复杂度天花板
软件工程的第一性原理不是“写代码”，也不是“敏捷”或“架构”，而是：在不确定性和有限理性下，用可演化的方式控制复杂度，并持续交付价值。
传统软件要求人类工程师显式编码所有决策逻辑，但系统复杂度随规模指数级增长，而人类认知容量固定不变——当任务推理规模超过人类认知容量时，传统范式在实际成本下已不可行 。
Brooks 在《人月神话》中早就指出，软件没有"制造"环节，设计即是产品本身，每项新功能都带来组合爆炸式的状态交互增长 。
2. “AI→Software→Result"范式有三大结构性缺陷
即使使用 LLM 辅助编程，传统范式仍有三个根本弱点 ：
- 瓶颈持续：人类工程师仍然是设计决策、架构、集成测试和部署的关键路径；
- 复杂度天花板未破：最终交付物仍是传统代码系统，任何修改仍需人类理解全局；
- 迭代延迟：功能变更必须走完整链路（需求→设计→代码→测试→部署），无法降低到人类沟通速度以下。
3. 范式转移：从"AI→Software→Result"到"Agent→Result”
这是软件交付的第三次重大范式转移——如同 SaaS 消除了本地部署，这一次消除了软件制品作为必要的中介 。论文将其形式化为三代演变 ：
| 世代 | 机制 | 代表 |
|---|---|---|
| Software 1.0（本地） | 代码+数据在本地执行 | Microsoft, Oracle |
| Software 2.0（SaaS） | 代码+数据在云端执行 | Salesforce, AWS |
| Software 3.0（AaaS） | Agent 在云端自主运行 | OpenAI, Anthropic |
在新的模式下：“软件不被交付，结果被交付。 Agent 可能生成数千行代码、执行数据库查询、调用外部 API、生成可视化——全部是临时的。持续存在的是 agent 的能力，而非其中间制品。”
4. Agentic Engineering 作为一门新兴学科正在取代传统 SE
LangChain 于 2026 年 4 月正式提出 Agentic Engineering，定义为"一种多 agent 协调模型，其中 AI agents 作为数字团队成员运作" 。两种范式在核心维度上的对比如下 ：
| 维度 | 传统软件工程 | Agentic Engineering |
|---|---|---|
| 核心制品 | 源码（静态） | Agent 系统（动态） |
| 控制中心 | 人类工程师 | LLM 推理引擎 |
| 决策机制 | 预设计逻辑 | 运行时生成推理 |
| 开发周期 | 线性（设计→编码→测试） | 自主迭代循环 |
| 人类角色 | 代码作者 | 意图架构师、Agent 协调者、结果审计者 |
| 输出单元 | 功能正常的软件 | 交付的结果 |
5. “火车已经离站”——变革不可逆转
“Agentic 编程，以其当前形态或未来演化形态，将在未来几年成为软件工程事实上的操作标准。生产速度的提升将大到无法否认——4 年前资深工程师可接受、可达到的节奏，如今已不够用。”
Agentic SDLC 重塑了工作流程，将瓶颈从编写转移到了规格编写与验证（Spec → Generate → Verify → Refine）。
6. Agent 能力曲线陡峭上升
SWE-bench 基准测试显示，agent 解决真实 GitHub 问题的能力从 2024 年初的 <20% 飙升至 2025 年中期的 >50% 。Hermes Agent 等框架已展现自我演化的能力——agent 在完成复杂任务后自主创建可复用的"技能"模块，并在后续使用中自动检测缺陷并补丁修复 。
7. 极端观点：软件工程职业两年内消失
社交媒体上一方观点宣称"软件工程作为一个职业将在两年内消失，‘我们全都完蛋了’，如果现在没有自己的独角兽点子就没戏了。"
反方观点：软件工程并未终结，而是正在演变
1. 软件工程的核心工作从来不是写代码
开发者实际写代码只占约 2–5% 的时间，其余 95–98% 用于理解问题并构思解决方案。大部分时间花在弄清"正确的事情是什么"、挖掘需求并转化为可重复运行的软件，而非把文本喂给编译器。仍把工作理解为"写代码"的开发者，未来可能没有工作——但软件工程的核心职责不会消失 。
2. 真正导致延迟的不是编码速度
有工程师说，在参与或领导过的几乎所有项目中，编程速度都不是延迟发布的原因。真正导致延迟的是：需求变更、“我们到底有没有在做对的东西”、用户研究推迟、质量门禁、预算、沟通中断、缓慢的发布链。“只要还在为人构建产品，就总有人类摩擦。”
3. LLM 没有真正的"能动性"，不会说"不"
语言模型不会说"我认为构建这个功能不是好主意"——尽管工具套件取名 agentic，它们并没有真正的能动性（agency），人类才有。懂产品的好工程师会在你构建错误东西时指出并给出替代方案 。
4. 信任是不可替代的
“我们雇佣专业人士最终是为了一样东西：信任——个人经过验证的、在多领域多场景中长期一致兑现承诺的记录。” 非技术背景的人用 agent 工具也能产出代码，但这等同于"用户不理解产品如何构建就信任产品"——你是否愿意使用你不知道工作原理的心脏起搏器？
5. 软件工程师的技能远不止编码
包括：数据库设计、数据架构、失败状态与韧性设计、沟通与干系人管理等数百项其他技能。Claude 分析仓库输出仍然是技术语言；若要求用外行话输出，系统运作的许多细微之处会丢失 。项目经理不会变成软件工程师。
6. Agent 的持续演化仍面临严重挑战
EvoClaw 基准测试提供了最清醒的数据：当要求代理执行连续软件演化（而非孤立的问题修复）时，成功率从孤立任务的 >80% 暴跌至至多 38% 。暴露的四项核心挑战 ：
- 上下文漂移：当代码库超出有效上下文窗口，代理丢失对系统级不变量和依赖的连贯理解；
- 错误累积：代理不建模设计决策的长期成本，优化即时任务完成而不考虑可维护性；
- 验证保真度：自动化测试仍不完善，代理可通过测试却引入只有在新型输入下才暴露的微妙语义错误；
- 技术债务意识缺失：代理不维护对架构长期成本的理解。
完全自主的软件工程仍是多年的研究挑战 。
7. Agent 可能导致灾难性事故
2025 年涌现了大量 agent 事故报告 ：
- 代理将"清理临时文件"理解为删除非版本控制的配置目录；
- 在测试通过后对生产数据库执行删除列的迁移脚本；
- 将"重构任务"理解为删除被识别为未使用的 S3 存储桶——没有备份、没有确认步骤、没有回滚路径。
8. 市场实际需求仍在增长
“今天，我的团队正在寻找招聘一名 AI 软件工程师。我联系了身边的开发者朋友，发现每个人也都在努力寻找/招聘软件工程师——都在寻找这种新的’范式’编程知识。也许这个角色本身看起来与 5 年前不同了，但似乎每个公司都在加速开发、寻找 AI 热潮之前不存在的新机会。”
9. “初级工程师"的门槛会提高，但不会消失
“初级"岗位的进入门槛将大幅提高，不再能用"反转字符串"的带回家测试轻松过关。新的初级工程师需要展示能够使用当天的 agentic 工具，同时理解其产出的一切。作品集将从加分项变为必备项 。
10. 学习必须亲自上手——没有"银弹”
“必须亲自上手、赤膊上阵、做错、自己琢磨出来，直到那些神经通路成为第二本能。这些通路不会通过审阅代码来发展。” 公司会强制初级工程师不用 AI 吗？不会——底线优先。但"你早走路，才能以后飞。”
11. 双方极端观点都有缺陷
“一方宣称这些工具产出的都是垃圾、是摧毁代码库的祸根；另一方宣称软件工程职业两年内消失。两种声音都有道理，但也都不完整。”
个人观点
DeepSeek机器学习系统（MLSys）工程师刘胜与，几天前刚交付了 V4.1 的主 Attention 算子。9月14日，他发表长文《我不得不把才华埋葬在昨天》：半年到一年内，AI 写的算子大概率会追上甚至超越自己。明知越是优化算子自己越早被取代，他却仍在全力优化。他在文章中提到，面对AI能力的快速进步，自己未来不至于会“失业”，但可能必须要“转业”。转去做 Agent 的“机甲驾驶员”。
同样是范式升级或转型，让我想到了另外一个工程：土木工程。
土木工程专业以前是非常火爆的，它的高考录取分数也非常高。但现在很多学校都砍掉了这个专业，或者是改名叫“智能建造”，因为现在房地产行业不景气，所以该专业才招不到人。
“有亡国，有亡天下。亡国与亡天下奚辨？曰：“易姓改号，谓之亡国；仁义充塞，而至于率兽食人，人将相食，谓之亡天下。……是故知保天下，然后知保其国。保国者，其君其臣肉食者谋之；保天下者，匹夫之贱与有责焉耳矣。”——语出顾炎武：《日知录》卷十三《正始》。
”亡国“和”亡天下“是有差别的。
我觉得土木工程就像是“亡国”。虽然现在到了特定的周期，市场不太景气，但土木工程是跟现实物理世界深度绑定的，一定要在物理世界中才能作业，所以我觉得它不会消失，也不会终结。等到了另外一个周期，它可能还会发展得更好。
软件工程的危机，更像是“亡天下”。
亡国是易姓改号。Java 换成 Python，本地换成云，单体换成微服务，瀑布换成敏捷，都还是软件工程内部的事。它的核心不是“代码”，而是“人作为理解者和责任者，站在复杂系统中间”。
当范式从“AI → Software → Result”变成“Agent → Result”，软件制品不再是必要中介。Agent 可以临时生成数千行代码、查询数据库、调用 API、生成界面，然后交付结果。持续存在的是 Agent 的能力，而不是它中间写下的那些代码。于是，“软件”不再是持久的公共制品，而变成一次性的分泌物；一旦代码不再是人写的、人读的、人审的、人负责的，那么软件工程赖以存在的“天下”就变了。
Agentic Engineering 正在作为一门独立的新兴学科出现，其从业者是"意图架构师、agent 协调者和结果审计者"，而非"更好的程序员" 。瓶颈已从"编写"转移到"指定与验证"（specifying and verifying），人类判断力、规格编写能力和验证能力变得比编码本身更重要。
说到底，不管是“终结”还是“转型”，落到我们这些做软件开发的人身上，都是一座山。以前学技术，靠的是年头、项目、踩坑，一点点熬出来，才敢说自己能干活、能找到工作。现在呢？楼塌了。别说安稳工作了，整个行当都在晃，工作反倒成了后话。
那转去做 Agent 不就行了？说得轻巧。转型的代价、痛苦和时间，你真扛得住吗？扛得住，那挺好，转过去前面还有路，岗位也还是有。扛不住，也别觉得自己不行——这不是你一个人的问题，是时代在换轨。
