AI 正在消灭软件工程师的“中产阶级”！

AI 编程正在把写代码这件事变得越来越便宜，但一个有意思的问题也随之出现了：当代码生成的速度远远超过人的理解速度，软件工程师真正的价值还剩下什么？

过去，一个工程师一天能写多少代码，多少还受到时间和精力的限制。现在，Agent 可以连续工作几个小时，一口气改掉数万行代码，甚至直接提交 PR。代码产出的“速度上限”被 AI 不断推高，但人的审核、理解和判断能力，却没有同步加速。

这也让一个过去没那么尖锐的问题，开始变得越来越现实：如果一个工程师自己都搞不清 AI 写出来的代码在做什么，他到底是在提高生产力，还是在更快地制造技术债？

近日，软件工程师 Florian Herrengt 撰写了一篇题为《AI is removing the middle class of software engineering》的文章，在 Hacker News 上引发热议，也让不少开发者产生共鸣。

值得讨论的是，当 AI 已经能够替代大量“把需求变成代码”的工作后，公司真正需要的，究竟还是那些写代码最快的人，还是那些能够判断“这段代码到底该不该写”的人？

来源：https://blog.florianherrengt.com/ai-removing-middle-class-software-engineering.html

作者 | Florian Herrengt 责编 | 苏宓

出品 | CSDN（ID：CSDNnews）

假如在 2020 年。你是团队里资历最深的人，负责代码质量和架构设计。你建立了一套完善的工程规范，会认真审查经验不如你的同事提交的 PR，并且一直努力维护一个健康的代码库。

然后某一天，你去度假了。等你回来时，代码库已经一团糟。大家互相合并 PR，基本没怎么认真检查；也有人为了图省事，给数据库加了一堆新表进行反规范化；还有人直接把 Serverless 或 Kafka 加进了技术栈，却没有任何充分证据表明他们真的需要这些东西。

没关系，你还能修好它。

当时间来到 2026 年。你甚至都没有休假。这只是一个普通的周一早晨。你给自己冲了一杯咖啡，打开电脑，然后发现有 7 个 PR 等着你审核。

你打开第一个：+24,506 行，-3,938 行。旁边还附带了一段 AI 生成的描述，告诉你这个 PR 大概是要干什么。不知道怎么回事，你的团队从周五到现在做出的改动，竟然比过去你离开团队几周时他们完成的工作量还要多。

AI 取消了速度限制

AI 会让那些工程文化薄弱的项目，以更快的速度走向失败。

过去，团队还会坐下来讨论一件事情究竟应该怎么做。现在，他们只需要让 AI Agent 跑上几个小时，然后开一个 PR。

这种工作方式最悲哀的地方在于：在没有受过训练的人看来，它居然真的能用。

如果你拉取分支进行测试，你可能会得到一个勉强可以工作的东西。于是他们会怎么做？他们会继续。一次又一次地重复。直到项目发展到这样一个阶段：没有人知道任何东西究竟是怎么工作的，具体的工作原理到底是什么。

这就像有人用信用卡买了一辆豪华新车。你看不到他背负的债务，只能看到那辆看起来光鲜亮丽的车。

但随后，用户开始反馈一个奇怪的 Bug。这已经是你们团队第四次尝试修复它了。当然，严格来说，是第四次让 AI 尝试修复它。遗憾的是，似乎连 Fable 都搞不清楚到底哪里出了问题。

紧接着，你找到负责开发这个功能的人，开始一系列长谈：

• “这个数据是从哪里来的？”

• “嗯……其实我也不知道。让我问问 Claude。”

你们两个人并排坐在一起，看着屏幕上不断涌现的文字。你们谁也不知道其中的内容到底是不是真的，但 Claude 看起来倒是自信满满。

“要不我们直接打开 ultracode，让它再检查一遍？”

这次估计要等一会儿。于是你们开始聊起 X 上最近各种热闹的新闻。

终于，AI 给出了答案。

• “这说得通吗？”

• “我不确定。”

• “这不是你……上周刚做的吗？”

沉默。

这个项目已经变得如此复杂，堆叠了这么多层、这么多服务，以至于你们团队里根本不可能再有人真正搞清楚它到底是怎么运转的。

那么，你能怎么办？要修复它，需要投入巨大的工作量，以至于你甚至不知道该怎么向管理层解释为什么值得这么做。

更何况，你现在到底在纠结什么？就算真的修好了，几个月后它还是会重新变成现在这个样子。

- “要不就让 Claude 修吧。”

- “行。我给它设一个循环和目标，让它一直跑，直到确认所有东西都正常为止。”

- “听起来不错。”

- “等等，我今天的 Fable 用量已经用完了，明天再跑吧。”

你又拿了一杯咖啡，回到电脑前。现在，你还有 13 个 PR 等着审核。你看到其中有一处代码怎么也没看明白，于是给写这段代码的人发消息：

- “为什么要在这里这么做？”

对方发给你一个链接。是一个 Claude 的对话。

在那段对话的某个地方，埋藏着这段代码背后的设计决策——只不过你得先穿过一大堆内容：Claude 自信满满地推荐了一种架构，然后又道歉、改口；你的同事让它再重新考虑一下；接着又经历了 15 轮修改……

最后，似乎终于得出了现在这段代码的设计方案。

- “我应该看哪一部分？”

- “可能……全部都看吧。”

听起来是不是很熟悉？

每当我谈到这些，总会有人告诉我：其实过去也从来没有人能够真正完全理解大型系统。

这话没错。你本来就不需要理解每一个服务、每一个数据库。

但至少，曾经有人理解。

当你遇到问题时，他们可以把这些东西解释给你。而现在，他们去问 LLM，是因为他们自己其实也不知道答案。

你再也承担不起糟糕的工程师了

每个团队里，都有一些真正有能力的人，是他们让项目得以运转；同时，也总有一些人，本质上是在给其他所有人增加工作难度。

而现在，一个人一天写出来的代码，可能比过去一年写的还多。

在上面的故事里，其实每个人都有问题：

• 那个提交 2.5 万行 PR 的工程师，本应该在 Agent 走到这一步之前很久就让它停下来。他应该理解 Agent 到底在做什么，把工作拆成更小的部分，并对它引入的每一个新抽象提出质疑。

• 负责审核的人，本应该直接拒绝审核这么大的 PR，而不是最后妥协。

• 那个把 Kafka 加进来的工程师，应该能够准确解释为什么需要 Kafka。

• 那个开发这个功能的人，也应该能够解释数据究竟来自哪里，而不是直接丢过来一个 Claude 对话链接。

但问题来了：那就用 AI 把这些问题修好不就行了？

事情没那么简单……

先说明一下，免得有人马上跳出来反驳：这并不意味着技术债务永远都是坏事。真正重要的是，你得知道自己是在走捷径。

问题在于，一个糟糕的决定一旦做出，想要撤回它，真的非常难。

比如，让 LLM 往数据库里加一堆表和字段，需要多久？

10 分钟？

但一旦你开始往里面存数据，就不能说删就删。你得制定迁移方案，还得确保迁移不会影响系统正常运行——毕竟每天都有人付钱使用你的产品。

你还得考虑：如果迁移失败了怎么办？要确保最后不会留下孤立的外键。这些事情，修起来就是难得多。即使你手里用的是最好的模型，也一样。

而就在你修复这些问题的时候，新的 PR 还在不断涌进来。更多代码、更多抽象、更多决策。一个人一个下午就能生成 2 万行代码，但你还是得坐在那里，真正搞清楚这 2 万行代码到底在干什么。

等你终于理清一个糟糕的决定时，可能已经又有五个类似的决定被合并进去了。

AI 带来的新经济

当然，糟糕的工程师一直都是一种负担。

这种情况已经持续了几十年，早在 OpenAI 或 Anthropic 出现之前就是如此。

糟糕的决定不断叠加，不必要的复杂性不断累积，最终整个团队只能维护那些没人真正搞得懂的系统。

区别在于，过去这种事情的速度是有限的。

而今天，实现代码已经变得很便宜。你真正拿钱换来的，是做出正确的决定，是构建能够持续扩展、同时又能控制复杂度的软件。

想想为什么公司愿意在伦敦或旧金山给工程师开出六位数的年薪。

如果他们需要的仅仅是一个能够把需求说明变成可运行代码的人，那为什么还要花这么多钱？

毕竟，这种工作早就可以在其他地方以更低的成本完成了。

那些声称“软件已经被解决”的科技公司，为什么依然愿意用顶薪去争夺最优秀的人才？

我的判断是，AI 反而会进一步拉大工程师之间的薪资差距。想要保持就业竞争力，你必须跨过一道门槛，而这道门槛就是：当下最强的模型能做到什么，你至少得比它更有价值。

优秀的工程师反而变得更加值钱，因为 AI 让他们能够以快得多的速度推进工作。

他们不再需要身边有那么多人专门帮自己完成具体的实现工作。

与此同时，糟糕的工程师也变得昂贵得多。

我之前写过一篇文章，谈到“Vibe Coder”的职业道路注定走不通，其实也是这个原因。

你必须贡献一些东西，而这些东西不能只是给 Agent 一个 Prompt 就能得到的东西。

如果你缺乏判断 LLM 建议是否正确所需要的判断力，那么让 AI 再给你更多“判断”并不能解决问题。

归根结底，总得有人真正知道系统到底发生了什么。

而这个人，才是团队里最有价值的人。

那些不知道的人，要么会变得越来越便宜、越来越容易被替代，要么最终直接被淘汰。

与此同时，资金会越来越集中到一小部分真正值得信任的人手里。

而且，我不认为这种变化只会发生在软件工程领域。我认为，大多数知识型工作都会经历同样的变化。AI 会让最优秀的人变得极其高效，也会让糟糕的人变得几乎不值得雇佣。过去，一个人做出糟糕的决定，在它造成太大影响之前，还有很大概率会被其他人发现。但现在，他们可以以一种周围的人根本来不及合理审查、甚至来不及理解的速度，不断做出改变。

11.20-21 日，2026 奇点智能大会·北京站。

OpenAI 资深研究科学家 Łukasz Kaiser 确认进行主题分享。

他是 Transformer 八子中唯一还在科研前线的人，GPT-4/5、o1、o3、ChatGPT 的核心开发者。

2021 年，他在这个大会上分享了三个方向：多模态、更大更好的 Transformer、模型即服务。五年后，多模态爆发，ChatGPT 席卷全球，前沿观点全部成了现实。

去年，他讲的是推理模型的进化：从"记忆"到"策略"再到"研究器"——模型开始学会自己思考。

欢迎大家扫码领取 Łukasz Kaiser 历年在奇点智能大会上的分享 PPT 和视频

if like:

click("分享", "点赞", "在看")