2020 年，你是团队里资历最深的工程师，负责代码质量和系统架构。你制定工程规范，认真检查经验较少的同事提交的 PR，努力让整个代码库维持在一个健康的状态。然后，你休了几周假。等回来时，事情已经开始失控：大家互相合并 PR，却没人认真检查；有人为了开发方便，往数据库里加了一堆用于反规范化的新表；还有人在没有充分理由的情况下，把 Serverless 甚至 Kafka 塞进技术栈。问题当然麻烦，但至少还来得及修。

时间来到 2026 年。这一次，你甚至没有休假，只是一个普通的周一早晨。你冲好咖啡、打开电脑，发现面前躺着 7 个等待 Code Review 的 PR。点开第一个：新增 24,506 行，删除 3,938 行，旁边附着一段 AI 自动生成的说明，告诉你这两万多行代码 " 理论上 " 完成了什么。仅仅一个周末，团队制造出的代码改动，已经超过过去你离开几个星期时产生的总量。

这正是 AI 给软件工程带来的一个经常被忽视的变化：AI 首先取消的，不是程序员，而是软件开发原本存在的 " 速度限制 "。当生产代码变得异常便宜，一个过去并不那么致命的问题也被同步放大——如果团队缺乏足够好的工程判断，它现在可以以前所未有的速度，把项目推向失控。

一、AI 取消了软件开发的 " 速度限制 "

过去开发一个功能之前，人们通常需要坐下来讨论：应该怎么做，系统边界在哪里，数据库应该怎么设计，有没有必要增加新的服务。因为真正把一个想法变成代码本身需要时间，这种 " 慢 " 某种程度上反而构成了一道天然的工程约束。但 Agent 改变了这件事。现在，一个工程师完全可以给 AI 一个需求，让 Agent 连续运行几个小时，然后直接提交一个巨大的 PR。

最危险的地方在于，从表面上看，这种开发方式甚至真的有效。把分支拉下来、运行程序，你大概率会得到一个 " 基本能用 " 的东西。于是团队继续往前走：再生成一次，再合并一次，再增加一个抽象层，再增加一个服务，直到某一天，整个系统已经复杂到没有任何一个人真正知道它是怎么工作的。

Herrengt 用了一个形象的比喻：这就像用信用卡买了一辆豪华汽车。旁观者首先看到的是一辆漂亮的新车，而不是背后的债务。AI 生成代码也是如此，人们首先看到的是功能，技术债务则被隐藏在功能背后。

直到用户开始报告一个奇怪的 Bug。团队已经尝试修复三次，更准确地说，是三次 " 让 AI 尝试修复 "。这一次，连模型似乎也搞不定。你找到当初负责这个功能的工程师，问：" 这里的数据到底从哪里来的？" 对方想了一会儿：" 其实我也不知道。我问一下 Claude。" 两个人坐在屏幕前，看着 AI 不断生成长长的分析。Claude 说得非常自信，唯一的问题是，你们两个人都不知道它说的究竟对不对。

这就是 AI 编程正在制造的一种新的工程悖论：代码越来越容易产生，但代码背后的知识并没有以同样速度进入人的大脑。过去，一个大型系统当然也不可能被某一个工程师完全理解，但在一个健康的工程组织里，通常 " 有人知道 "。现在，一种新的情况开始出现：写出代码的人自己也不知道为什么代码是这样的，因为真正做出决定的，可能是一段几十轮的 Claude 对话。

当 Reviewer 追问 " 为什么这里要这样设计 "，工程师发来一个链接。那是一段 AI 聊天记录：Claude 先自信地推荐架构 A，然后道歉，说刚才的判断有问题；接着推荐架构 B；用户让它重新考虑；Claude 再次改变主意。最终进入生产环境的技术决策，就埋在几十页聊天记录的某个角落。问题已经不再只是 AI 会不会写错代码，而是当工程决策逐渐外包给模型，组织内部是否还在积累真正的工程知识。

二、AI 让 " 糟糕的工程师 " 变得前所未有地昂贵

软件行业一直存在能力差异。一个团队里，总有一些真正推动项目向前的人，也会有一些人不断制造复杂性，需要其他同事帮助收拾残局。这并不是 AI 时代才出现的问题。真正的变化是，现在任何一个人一天都可以制造过去很长时间才能制造出来的代码量。这意味着人的能力差异，会被 AI 同步放大。

一个能够提交 2.5 万行 PR 的工程师，本来应该在 Agent 生成几百行甚至几十行代码的时候就停下来，理解它正在做什么，把工作拆成更小的部分，并质疑模型引入的每一个新抽象。Reviewer 也应该拒绝审查一个大到实际上无法认真审查的 PR；决定加入 Kafka 的人应该能够明确回答为什么这里需要 Kafka；负责某项功能的人应该知道数据从哪里来，而不是在被问到时发送一个 Claude 聊天链接。

这些要求听起来都是传统软件工程常识，但 AI 正在让这些常识变得更加重要。过去，一个错误架构从想法变成现实，需要工程师投入大量时间；现在可能只需要几分钟。比如，让一个 LLM 给数据库增加若干张表和字段很容易，但一旦生产数据真正写进这些表，撤销这个决定就完全是另一回事。你需要设计迁移方案，保证线上系统不中断，考虑迁移失败怎么办，检查外键关系，避免留下孤儿数据，还要确保新旧系统的数据一致性。

制造复杂性的成本已经被 AI 大幅压低，但消除复杂性的成本并没有同步下降。这是原文最值得注意的判断之一。AI 让 " 创造技术债 " 的速度远远超过 " 偿还技术债 " 的速度。一个人下午可以生成 2 万行代码，但仍然需要另一个人坐下来理解这些代码究竟做了什么。等你终于拆掉一个错误架构时，另外五个 PR 可能已经被合并进主干。

于是 AI 带来的效率提升出现了一种反直觉结果：软件组织获得了更高的代码吞吐量，却不一定获得更高的工程生产率，因为真正的瓶颈正在从 " 写代码 " 转移到 " 理解代码、验证决策和控制复杂性 "。

三、当 " 实现 " 越来越便宜，工程师究竟为什么值钱？

如果 AI 已经可以如此快速地生成代码，那么企业未来为什么还需要高薪软件工程师？Herrengt 认为，答案恰恰隐藏在这个问题里。今天伦敦、旧金山的科技公司愿意给优秀工程师支付六位数级别的薪酬，从来不只是因为这些人能够把产品需求翻译成代码。如果企业真正需要的只是 " 根据规格实现功能 "，这种工作在 AI 出现以前就已经可以通过全球外包，以远低于硅谷的成本完成。

即使一些科技公司开始宣称 "software is solved"，它们仍然愿意花高价争夺最优秀的工程人才。因为真正昂贵的从来不是敲代码，而是做出正确决定：知道什么时候应该增加一个数据库，什么时候不应该；知道什么时候一个新的抽象层能够降低长期复杂度，什么时候它只是炫技；知道系统未来增长十倍之后会发生什么；知道哪些技术债可以暂时接受，哪些技术债一旦留下就会在两年后变成灾难。

AI 降低的是 Implementation ——实现——的成本，但软件工程真正稀缺的部分，越来越变成 Judgment ——判断。这也是为什么 AI 可能并不会让所有软件工程师一起贬值。恰恰相反，它可能让工程师之间的价值差距进一步扩大。

四、软件工程的 " 中产阶级 " 正在被挤压

Herrengt 给出了一个尖锐判断：AI 可能会进一步拉大软件工程师之间的薪酬差距。未来，一个工程师首先需要跨过一道新的最低能力门槛——你能够提供的价值，至少要超过当下最强模型可以直接提供的价值。如果一个 Agent 已经能够根据产品需求生成基本代码，那么 " 能够根据需求写代码 " 本身，就不再足以构成稀缺能力。

优秀工程师反而可能变得更贵，因为他们可以借助 AI 极大提高自己的执行速度，并且不再需要过去那么多初级工程师帮助完成基础 Implementation。过去，一个高级工程师可能需要带着几个人完成项目；未来，一个真正优秀的工程师加上若干 Agent，也许就能够完成过去整个团队的部分实现工作。

但与此同时，能力较弱的工程师正在变得更加昂贵——不是工资更高，而是他们给组织制造错误的速度也被 AI 加速了。这才是 "AI 正在消灭软件工程中产阶级 " 这个标题真正想表达的意思：夹在顶尖工程判断与可被模型商品化的基础实现之间，那一大批主要靠执行能力获得不错收入的人，面临的压力可能最大。

五、真正的风险不是 Vibe Coding，而是 Vibe Engineering

过去一年，Vibe Coding 成为 AI 圈最流行的概念之一。但这篇文章真正警惕的并不是普通人利用 AI 写几个小程序。对于个人项目、原型验证、一次性工具来说，AI 大幅降低编程门槛显然是一件好事。真正危险的是，当 Vibe Coding 进入复杂、长期运行、承载真实业务的生产系统之后，它可能逐渐演变成一种 "Vibe Engineering"：代码能跑就行，模型说合理就行，测试通过就行，至于为什么这么设计、未来会产生什么后果、系统复杂度是否已经失控，没有人真正负责。

技术债本身也不是问题。原作者特别强调，技术债并非永远是坏事。现实商业世界里，工程师当然可以为了更快上线而做出妥协，关键在于你必须知道自己正在走捷径。因为只有知道哪里存在债务，未来才有机会偿还。

真正危险的是，团队通过 AI 不断引入自己都没有意识到的复杂性。这时，技术债甚至不再像一笔可管理的债，而更像一笔没人知道存在、没人知道本金多少、也没人知道利息什么时候爆发的隐藏负债。

六、AI 编程真正的瓶颈，正在从 Code Generation 转向 Code Comprehension

如果把 Herrengt 的观点再往前推一步，这篇文章触及了当前 AI 编程一个更深的产业问题：过去几年，整个行业都在努力提高代码生成速度，Copilot、Claude Code、Codex 以及越来越多 Coding Agent，都在竞争 AI 能够替开发者完成多少工作。但当生成能力提升几个数量级之后，另一个过去没有那么突出的瓶颈开始出现——人类还有没有能力理解 AI 生成的系统？

代码生成可以并行，理解却很难并行。Agent 可以在几分钟内同时修改几十个文件，但 Reviewer 仍然需要理解这些修改之间的依赖关系；模型可以迅速引入新的服务，但生产事故最终仍然需要有人判断问题究竟发生在哪里。生成速度和系统复杂度正在被 AI 快速推高，而人的理解能力没有以同样速度增长。

这意味着下一阶段 AI 编程真正需要解决的，也许已经不只是 " 让模型写更多代码 "，而是让系统保持可理解，让架构决策可以追踪，让 AI 解释自己为什么这样修改，让团队能够验证 Agent 生成的代码，并让工程知识重新沉淀到组织，而不是散落在数百个 Claude Session 里。

从这个意义上说，AI 编程下一阶段真正稀缺的产品，也许不是更快的 Coding Agent，而是帮助人类控制 AI 产生的复杂性的工程基础设施。

七、这件事可能不会只发生在程序员身上

文章最后把问题从软件工程推向了整个知识工作领域。作者认为，同样的结构可能出现在大多数白领职业中：AI 会让最好的人变得更加高效，同时让能力较弱的人变得越来越难以被雇佣。过去，一个经验不足的员工做出错误判断，组织还有时间发现，因为人的执行速度有限；AI 改变了这个约束，它把 " 执行能力 " 迅速放大。

问题在于，AI 既会放大正确判断，也会放大错误判断。因此，在 AI 时代，一个人的判断力可能比执行力更加重要。如果你没有能力判断 LLM 给出的建议是否合理，那么再问一次 LLM 并不会自动获得这种判断力。

原文有一句很值得深思："At some point, someone still has to know what is going on. And that's the most valuable person on the team." 无论 AI 发展到什么程度，团队里最终仍然需要有人真正知道正在发生什么，而这个人，会成为团队里最有价值的人。

过去我们一直问 "AI 会不会替代程序员 "，但这个问题可能问错了。更值得问的是：当 AI 把普通人的执行能力大幅提升之后，什么能力还会保持稀缺？至少从软件工程正在发生的变化来看，答案越来越清晰：不是写更多代码，而是知道什么代码不应该写；不是让 Agent 更快完成任务，而是能够判断任务本身是否值得完成；不是拥有更多 AI 生成的答案，而是在所有人都可以得到答案之后，仍然有能力判断什么是正确的。

如果这个判断成立，那么 AI 对就业市场真正深远的冲击，可能不是简单的大规模失业，而是知识工作内部的价值重新分配。AI 把 Implementation 变便宜了，也正因为如此，Judgment 正在变得越来越贵。而夹在两者之间、主要依靠 " 执行能力 " 获得不错收入的那批知识工作者，可能才是 AI 时代真正面临压力的 " 中产阶级 "。