AI 正在挤掉软件工程师的“中间层”
一名负责架构和代码质量的资深工程师休假几周，回来后可能会发现代码库里多了未经论证的数据库表、Serverless 服务或 Kafka。到 2026 年，Florian Herrengt 描绘的场景变得更夸张。周一早上积压了 7 个 PR，第一个就增加 24506 行、删除 3938 行；到了第二杯咖啡时，待审 PR 已变成 13 个。

这组场景是作者为说明风险设置的情境，并非行业调查。AI 编程智能体让实现速度突然提高，却没有同步提高团队理解和审查代码的速度。一个人提示智能体几小时，便能提交看起来可以运行的功能。团队继续沿着这条路堆叠代码、服务和抽象，直到出现反复修不好的 Bug。负责功能的人甚至无法解释数据来自哪里，只能转发一段很长的 Claude 对话。

问题出在工程判断缺位。提交 2.5 万行 PR 的人没有及时停下智能体、拆分任务，也没有质疑新抽象；审查者没有拒绝无法有效评审的改动；引入 Kafka 的人说不清理由；实现功能的人也没有真正掌握数据流。大型系统从来不可能由一个人全部理解，但过去至少有人理解其中每个部分，并能向同事解释。如今，团队可能把模型对话误当成设计记录。

坏决策的制造成本和撤销成本并不对称。模型或许 10 分钟就能增加一批数据库表和字段，一旦生产数据写进去，删除它们便涉及迁移、回滚、业务连续性和外键完整性。即使使用更强的模型，工程师仍须逐行理解改动。作者举例称，一个下午可以生成 2 万行代码，而团队解开一个错误决定时，可能已有 5 个新决定被合并。

因此，作者预测 AI 会拉大软件工程师的价值和薪酬差距。把规格转换成可运行代码越来越便宜，能判断架构是否合理、控制复杂度、解释系统并对结果负责的人会更值钱；只能提示模型、又无法检验模型建议的人，其工作价格可能下降，甚至被替代。他把这种变化称为软件工程“中间层”的消失，并认为相同趋势可能扩展到其他知识工作。

这个判断仍是作者的推测，原文没有提供招聘、薪资或生产率数据。文章指出了一个已经值得团队正视的管理问题。当生成速度超过审查能力，AI 不只放大优秀工程师的产出，也会更快放大薄弱的工程文化和未经验证的决策。

AI 软件开发