视频：https://www.youtube.com/watch?v=kwSVtQ7dziU

我看完这个视频之后更强烈地感觉到，软件工程并不是简单地被 AI 取代了，而是在被迫更换自己的重心。代码还在，但“写代码”正在失去它过去那种绝对中心的位置。

一、先换一套词，才能看清这件事

如果还沿用旧时代的软件语言来理解今天的变化，很多判断都会慢半拍。
Andrej Karpathy 提到的一些词之所以重要，不是因为它们新鲜，而是因为它们在试图命名一种已经发生的工作方式变化。

其中最关键的，我觉得有这几个。

• 技能差距（skill issue）：很多时候问题已经不是模型不够强，而是人不会调它、不会组织它、不会给出足够清晰的目标和边界。
• 意图表达：所谓“编程”，越来越像是在持续地向一组 Agent 说明你想要什么，而不是自己手工完成每一个中间步骤。
• 宏观动作（macro actions）：人不再负责“写这一行、改那一行”，而是负责下达更高层的动作，比如“实现某个功能”“重构这个模块”“跑完这组实验并比较结果”。
• 内存压缩（memory compaction）：当 Agent 持续运行、上下文不断累积时，系统需要不断总结、折叠和重组历史，才能保持长期任务的一致性。
• 能力锯齿（jaggedness of capabilities）：AI 在某些维度上非常强，在另一些维度上又显得非常笨。这种不连续的能力分布，决定了它不能被简单当成人类工程师的替身。

这些词背后真正指向的是同一件事：
软件工程的生产单元，正在从“人写代码”变成“人组织算力”。

二、软件工程并没有消失，消失的是旧的中心

“软件工程的终结”这句话如果字面理解，是错的。
软件不会消失，系统不会消失，工程复杂性更不会消失。真正结束的，是一种长期被默认为中心的工作方式。

过去的软件工程，大致可以概括成这样一套结构：
需求下来，人分析；设计做完，人拆分；代码实现，人手写；问题出现，人排查；上线之后，人维护。

AI 的出现并没有抹掉这条链路，而是重新分配了链路里各个环节的成本。

最先崩塌的是“实现”这一层。
代码本身的生产成本正在被快速压低。以前一个功能需要一个工程师花几天搭结构、补细节、写样板、修边角；现在越来越多的机械性实现劳动，可以被 Agent 成批吞掉。于是代码开始像一种廉价材料，而不是稀缺工艺。

这会带来两个直接后果。

第一，软件不会变少，反而会变得更多。
这其实很接近杰文斯悖论：当某种资源的使用效率上升，总消耗往往不是下降，而是上升。软件一旦变便宜，社会就会要求更多软件、更碎的软件、更临时的软件、更贴近具体场景的软件。原来因为开发太贵而不值得做的东西，都会重新变得值得。

第二，工程瓶颈开始上移。
当“写出来”不再最贵，真正昂贵的部分就变成了：你究竟要让系统做什么，你怎样判断它做得对不对，你怎样防止它在错误方向上高效狂奔。

也就是说，软件工程没有死，它只是把自己的重心从“编码执行”移到了“目标设定、系统编排与结果验证”。

三、从“经验驱动”到“算力编排驱动”

我觉得现在正在发生的，不只是工具升级，而是一种生产范式变化。

过去的软件开发更像是一门经验工业。
高级工程师的价值，很大程度上来自长期训练出的肌肉记忆、故障直觉和局部判断。他知道某个系统在哪些地方最容易坏，知道某种架构在团队里会怎样腐烂，也知道哪个问题需要一周，哪个问题半天就能拆开。

现在这些经验当然仍然重要，但它们越来越多地被放进了一个新的工作流里：
不是你亲手做完，而是你组织一组 Agent、脚本、测试、上下文和反馈回路，让它们在后台持续展开。

这就像软件开发从“单兵手工制作”转向“控制一条自动化生产线”。

在这种模式下，一个人的价值不再主要体现在：

• 能不能手写出更快的实现
• 能不能背更多框架 API
• 能不能把某个样板流程重复得更熟练

而更多体现在：

• 能不能把目标说清楚
• 能不能把系统拆成适合机器执行的层次
• 能不能设计好验证机制
• 能不能快速看出 AI 生成结果里哪里只是“看起来对”

换句话说，未来的软件工程师会越来越像：

• 架构师
• 调度员
• 裁判
• 审稿人

而不会再像过去那种纯粹的“代码生产工人”。

四、人还剩下什么不可外包

如果 Agent 能够写越来越多代码，那人到底还剩什么？

我觉得最重要的不是去找“还有哪些技术点 AI 现在不行”，因为这些空白会不断缩小。
真正稳固的，不是某一块暂时还没被自动化的技能，而是几类更高层的能力。

1. 问题定义

AI 可以在一个已经定义好的问题空间里高速搜索，但它不会天然知道哪个问题值得解决。
在现实世界里，最困难的往往不是“如何优化”，而是“到底该优化什么”。

很多团队的失败，甚至不是因为执行差，而是因为一开始就解决了一个伪问题。
在这种情况下，AI 只会让你更快地在错误方向上跑远。

2. 架构品味

当系统能生成三种都能工作的方案时，真正的区别就不再只是“能不能跑”，而是：

• 哪一种更稳定
• 哪一种更容易扩展
• 哪一种更适合团队未来的节奏
• 哪一种技术债更少

这件事很难完全程序化，因为它牵涉到长期维护、团队结构、组织文化、用户预期以及工程审美。

3. 验证与纠偏

AI 最危险的地方，不是完全不会做，而是“经常做出看起来很像对的东西”。
这比直接报错更麻烦。

所以未来很重要的一类能力，就是快速识别那些被指标、语气和复杂度伪装过的错误。
你需要成为那个能在大段自动生成的代码、文档和架构说明里，迅速闻到不对劲的人。

4. 跨界映射

数字系统是精确的，但现实业务往往不是。
人类组织、市场节奏、资源限制、情绪反应、行业规制，这些东西都带着大量模糊性。

把这种模糊世界翻译成 AI 可以处理的目标和边界，这本身就是一种高密度的工程工作。
而这类工作，恰恰最不容易被简单外包。

五、未来的软件工程师，更像什么人

如果继续沿着这个趋势走，未来的软件工程师未必会更像“更强的程序员”，反而更像一种新的复合角色。

他既懂技术，又不再把技术理解为最终目的；
他既能使用 Agent，又知道什么时候不能相信 Agent；
他既能写 Prompt，又知道 Prompt 不是魔法，而只是系统设计的一部分。

从这个角度看，未来值得练的东西大概是下面几类。

• 少沉迷语法，多理解系统。 与其花大量时间追逐新框架的表面差异，不如花时间理解服务边界、数据流、故障传播和接口耦合。

• 学会写给机器执行的说明书。 一份好的指令文档，不只是让 AI“去做”，而是明确目标、边界、约束、检查方式和失败后的回退路径。

• 刻意训练审稿能力。 未来很多时候，你的工作不是创造第一稿，而是快速看穿第一稿的缺陷。

• 深耕真实世界的业务逻辑。 技术会越来越平权，但行业里的复杂现实不会。谁更懂医疗、金融、制造、教育这些领域真实的摩擦力，谁就更不容易被替代。

六、写在最后

我越来越觉得，“软件工程的终结”这句话，真正想说的不是毁灭，而是重生。

终结的，是那种把软件工程理解为“人类凭手艺逐行塑造代码”的旧中心。
重生的，则是一种更像系统组织学、更像判断学、更像验证学的新工程。

代码当然还会存在，而且会比现在多得多。
但代码本身会越来越像一种廉价材料，而不是工程师价值的最终证明。

真正稀缺的，将是那些无法被廉价复制的能力：
问题定义、系统判断、验证机制、架构审美，以及在高强度自动化环境里持续保持清醒的能力。

如果说过去的软件工程师主要靠“把东西做出来”来证明自己，
那么接下来更重要的问题会变成：你能不能决定什么值得做，能不能判断它是不是真的做对了。

这大概就是我看完这个视频之后最直接的感受：
软件工程没有结束，它只是把灵魂从“编码”转移到了“判断”。