AI正在用代码海啸淹没中级工程师的最后防线！
软件开发正在经历一场代码通胀，而中级工程师成了第一波被冲垮的群体。
摘要：当AI能将需求秒变数万行代码，软件工程的中级岗位正面临前所未有的生存危机。速度掩盖了理解断层，代码量淹没了架构判断，技术债在AI辅助下以前所未有的速度累积。本文通过分析“24506行PR”现象背后的语言模糊性与工程决策链瓦解，揭露AI时代中级工程师的尴尬处境：不是被AI取代，而是被AI加持的混乱淹没了。
速度的暴力：当“完成”不再需要理解
2020年，休完假回来发现代码库面目全非。同事互相合并了彼此的拉取请求，没人仔细看。有人为了图省事往数据库里加了一堆新表做反范式化，还有人毫无征兆地把Serverless或者Kafka塞进了技术栈。那时候，这种灾难还能靠一个人的力量掰回来。
2026年，一个普通的周一早晨。咖啡还没凉，屏幕上有7个拉取请求等着审阅。点开第一个，加号24506，减号3938。一个周末，团队产出的代码量比2020年休假几周积累的还要多。这不是效率，这是一场代码海啸。
这里的关键词是拉取请求。它是代码审查的边界，是工程决策的最后一道闸口。过去，拉取请求的规模天然受限，因为人写代码的速度就那样。你没法在两天内编出两万五千行逻辑严密、架构清晰的代码。但现在AI可以，而提交代码的人未必知道这两万五千行里发生了什么。
速度从来不是免费的。它只是把代价从“写”转移到了“读”。AI生成代码的边际成本趋近于零，但人类理解代码的认知成本几乎没有变化。这意味着每一行新增代码都在向团队征收一笔阅读理解税。过去写代码的人和审阅代码的人之间有一种默契，叫做“写的人费了多大劲，读的人就能省多少事”。现在这份默契被AI撕得粉碎。
幻觉授权：为什么Claude说啥你信啥
一个工程师打开AI对话窗口，输入需求。AI吐出一堆代码。工程师看了一眼，觉得差不多，直接开拉取请求。这就是现在很多团队的日常。但真正值得追问的不是AI写了什么，而是工程师凭什么觉得“差不多”。
语言哲学的视角下，“差不多”这个词在这里承担了它不该承担的重量。它实际上在说：“我没法验证这段代码的正确性，但我选择相信AI。”这不是一个技术判断，这是一个信任决策。问题是，信任决策的前提是对信源的可靠性评估。而对AI的可靠性评估，在缺乏理解的情况下，根本无从谈起。
于是出现了这样一个场景：当被问及“这些数据从哪来”时，工程师的回答是“问一下Claude”。这句话在语言层面暴露了灾难性的责任转移。数据的来源被描述成了一个动作（问AI），而不是一个位置、一个系统或一个明确的数据流路径。这意味着工程师自己都不知道答案，但他觉得AI知道。更致命的是，他觉得自己不需要知道，因为AI会告诉他。
这种“幻觉授权”现象正在软件工程中蔓延。每个工程师都成了AI输出内容的二传手，而整个团队对系统真实状态的理解，变成了一个不断衰减的信号。每个人都在转发AI的答案，但没有人验证信号的原始来源。最终，整个项目的知识基础变成了一堆由AI生成、由人类转发的、未经核实的声明集合。
认知债务：比技术债更难还的东西
技术债是个老概念。代码写得烂，以后得花时间重构，这是利息。但现在出现了一种更隐蔽的东西，认知债务。
技术债是你知道代码写得烂，你也知道为什么烂，你只是暂时没空修。认知债务是你根本不知道这段代码在干什么，你甚至不知道应该问谁，因为写代码的人也是从AI那复制来的。你手上只有一段功能似乎正常的代码，和一段AI留下的、充满自信但细节全错的注释。
2026年的工程师坐在显示器前，面对一个持续报错的模块，问同事：“这部分谁写的？”同事说：“上周我让Claude写的。”再问：“为什么这么设计？”同事发来一个AI对话链接。那个链接里有15轮对话，AI一会儿推荐微服务架构，一会儿道歉改口，一会儿又在同事的要求下重新考虑。设计决策的过程被埋在一堆AI的自我修正和概率输出里，没有任何人能说清楚最终为什么选了这条路。
这就是认知债务的实体形态。系统里每一行代码都对应着一个“据说”。据说这样做能提高性能，据说这个表是这么用的，据说这个接口是兼容的。但拿出证据，没有。拿出推理链，AI的对话记录。拿出责任人，谁都有一份，谁都不敢全担。
一个令人意外的发现是，在这种环境下，最让人崩溃的不是代码有多烂，而是每次想搞清楚一个问题时，都被告知“去读一下这个AI对话”。那个对话的长度动辄几百条，AI在里面翻来覆去，你根本找不到决策的锚点。语言的模糊性在这里被AI无限放大了，因为AI从不承认自己不确定，它只会换一种表述重新说一遍。
反直觉漏斗：为什么25，000行代码被放行了
回到那个24506行的拉取请求。正常人不会提交一个两万五千行的改动。正常人也不会批准一个两万五千行的改动。但这两件事都发生了。问题在于，这两个“正常人”的行为都受到了AI的扭曲。
提交者那边，AI生成了两万五千行代码，他跑了一下，功能没问题。他的判断基于一个简单的事实：程序跑起来了。至于代码里有没有冗余、有没有安全漏洞、有没有错误处理缺失，他没看，也看不过来。但他的心理账户里，这算“完成”了。因为AI把“写代码”这件事的认知负荷降到了零，而“验证代码”这件事的认知负荷却没变，他选择了忽视后者。
审阅者那边，看到24506行改动，心里知道不该放行。但他面临的压力变了。过去，一个同事一周写一千行，审阅者能从容地问问题、提建议。现在，如果阻止这个两万五千行的PR，意味着整个团队的交付速度会瞬间断崖。而管理层的预期已经被AI神话抬到了天上，所有人都默认“AI让你快了十倍，你怎么还在拖”。审阅者妥协了。
这里存在一个反直觉的漏斗效应。AI使代码产出量暴增，但没有提高代码质量的判断门槛。当产出速度超过了审查能力的上限，审查流程实际上就瘫痪了。而流程瘫痪的结果是，所有代码，无论好坏，都开始以更快的速度涌入主干分支。这个漏斗的口径没有变，只是上游的水压被AI加到了无限大。
于是，在AI介入之前，一个坏决策可能需要一周才能扩散到整个代码库。现在，一个坏决策在一天之内就能被AI重构成十几处模块，混进十几个拉取请求里，让所有人都找不到它的源头。
删除的难度：为什么加一张表只需要AI十秒，删一张表却要三个月
AI往数据库里加一张表，十秒钟。告诉它需求，DDL语句直接生成，跑个迁移脚本，完事。但一旦这张表开始存储生产数据，一旦外键关联开始指向它，一旦下游报表开始依赖它，这张表就焊死在系统里了。想删？写迁移计划，准备回滚方案，确认数据清洗逻辑，处理孤儿记录，通知所有依赖方，灰度切流，观察监控，再等一个季度让旧数据过期。
加东西的边际成本被AI压到了极限。删东西的边际成本一点没变。这种不对称才是AI时代技术债的恐怖之处。AI生成的代码里，每多一张表、多一个服务、多一层抽象，都是在未来某个时刻埋下了一颗拆除成本极高的炸弹。而AI生成这些炸弹的速度是无限的。
这就引出了一个谁都不愿面对的问题：当一个系统被AI加上了几千个“当时觉得可能有用”的组件后，谁来拆？答案很明显，没人拆。因为拆的成本远高于重新做一个新的。而重新做一个新的，又会被AI加上同样多的新组件。系统就这样在AI的辅助下，从一个勉强能跑的烂摊子，变成一个谁也动不了的巨型僵尸。
一个冷笑话式的场景是这样的：团队决定用AI重构整个系统，目标是简化架构。AI跑了一个周末，生成了一套全新的代码库。大家欢呼着部署上去，运行良好。但新系统比旧系统多了两倍的微服务和三倍的中间件。没人敢问为什么。因为一旦问了，就又要去看那个几百轮的AI对话。
终局赌注：工资分化与认知垄断
如果写代码的能力被AI商品化了，那工程师到底在卖什么？公司在伦敦和旧金山开出六位数英镑的工资，买的是什么？显然不是敲键盘的速度。AI敲键盘比人快一万倍。
买的是判断。是在AI说“用这个架构吧”的时候，能说出“不行，因为我们的业务场景有这个那个限制”的人。是在AI生成两万五千行代码后，能扫一眼就知道“这里的事务边界错了，那里的索引会炸”的人。是在所有人都在说“AI说没问题”的时候，站出来说“AI没考虑这个边缘案例”的人。
判断力无法被AI直接输出，因为它依赖上下文，依赖对业务的理解，依赖对系统演变方向的预判。而这些，都是AI生成代码过程中被压缩掉的信息。AI只生成结果，不保存判断过程。所以当整个团队都开始依赖AI生成代码时，系统里的判断力就在流失。每个工程师都变成了AI的传声筒，而真正能做出判断的人，越来越少。
经济层面的推论并不复杂。能做出判断的工程师，会因为AI的辅助而产出数倍于前的价值。他们不需要那么多执行层的人围着转了。另一方面，那些只做执行、把判断外包给AI的工程师，他们的可替代性被AI推到了极致。以前，一个只会执行的工程师还能因为“熟悉这套代码”而保住饭碗。现在，AI比任何人更熟悉任何一套代码的表面结构，只是它不理解而已。
最终的局面可能是：软件行业留下了一小撮拿着极高薪酬的决策层，和一大幅随时可能被AI替代的操作层。那个曾经庞大的、负责在决策和执行之间翻译和转化的中级工程师阶层，正在被这场代码海啸一寸一寸地吞没。
五十年前，写代码是数学家的特权。二十年前，写代码是工程师的饭碗。现在，写代码是AI的基础操作。而人类，退回到了一个更古老、更本质的位置上：决定写什么，以及决定不写什么。这听起来像升级，实际上更像一场关于谁还能留在牌桌上的残酷淘汰。
讽刺的是，AI越能写，越不会写的人就越危险——但这一次，他们甚至不知道自己正在危险之中。
原文期刊：The Pragmatic Engineer / 发表日期：2026年 / 原文标题：AI is removing the middle class of software engineering / 作者单位背景：Gergely Orosz，独立技术博客作者，前Uber工程经理
网友灌水
Hacker News 上关于“AI正在淘汰软件工程中产阶级”一文的讨论非常热烈，评论总数超过550条。
总体来看，评论区普遍认同原文的核心观察：AI极大地加速了“坏”工程师造成破坏的速度，同时也显著提高了对“好”工程师判断力的要求。
讨论主要集中在以下几个维度，观点涵盖了从共情、辩护到批判和未来预测：
1. 对“坏工程师被AI放大”的强烈共鸣
- 大量评论者分享了亲身经历，印证了原文描述的“AI生成海量代码导致系统迅速腐烂”的场景。他们指出，过去一名能力不足的工程师需要很久才能制造出问题，现在借助AI，一个周末就能生成数万行难以维护的“垃圾代码”，让整个团队陷入审查和修复的泥潭。
- 许多评论者认为，问题不仅在于“坏”工程师，更在于那些对工作失去热情、只求完成任务的资深工程师。他们将决策外包给AI，与AI形成了“共谋”关系，加速了项目的崩塌。
2. 对“入门级岗位消失与人才培养断层”的深切担忧
- 一个核心共识是，AI工具正在消灭初级和中级岗位，这不仅影响了当下的就业，更切断了未来高级工程师的培养管道。新手失去了通过写代码、犯错误和接受前辈指导来积累经验的机会。
- 有评论将这与历史上CAD软件对机械工程的影响相类比：初级绘图工作被自动化，行业门槛被提高。他们预测软件工程最终也会要求更高的学位（如硕士或博士），才能从事核心工作。
3. 对“优秀工程师价值提升，但技能也会退化”的辩证讨论
- 一方面，评论普遍认为AI是“放大器”，能让优秀的工程师效率倍增，因此他们变得更有价值。那些只懂执行、不思考的“中间层”工程师最容易被淘汰。
- 另一方面，也有尖锐观点指出，即使是优秀工程师，如果长期依赖AI进行规划、编写和分析，他们的核心能力——理解复杂系统——也在悄然退化。他们离真正理解系统的距离，并不比那些“中间层”工程师远多少。
4. 对“监管、职业化与行业历史”的延伸思考
- 部分评论将话题引向软件工程师是否应像律师、医生一样实行职业资格认证。支持者认为这能提高责任门槛，防止AI酿成大祸；反对者则认为这只会增加官僚主义，且效果存疑。
- 多位老工程师将当前现象与过去的技术浪潮（如互联网泡沫、外包浪潮）对比，认为每次行业危机后都会催生新的机会，现在的恐慌与当年并无本质不同。