软件工程 2026：AI 时代，工程师的瓶颈正在转移

原文来源：Ben Congdon - "Software Engineering in 2026" — AI 让写代码变得廉价，但软件工程的瓶颈从"生产代码"转移到了"理解系统"和"设计好的抽象"，2026 年的工程师需要重新定义自己的核心价值。

从"写代码便宜了"说起

去年，AI 编程工具取得了巨大的进步。最直接的影响是：生产高质量代码的边际成本（无论时间还是金钱）都大幅下降了。

这看起来是个好消息——开发者可以更快地产出，公司可以用更少的资源做更多的事情。但问题是，写代码从来不是软件工程的全部，甚至不是最重要的部分。

软件工程到底在做什么？我的定义是：构建、演进、运维能提供商业价值的分布式软件系统。 其中：

• 构建：LLM 已经显著降低了成本
• 演进：LLM 也让修改变得更容易
• 运维：到目前为止，受 LLM 影响最小

这意味着，当"构建"变得越来越廉价时，瓶颈会转移到别的环节上。

2026 年加速发生的几个变化

1. 基础设施抽象的价值成倍放大

当 AI Agent 能写更多代码时，底层基础设施的质量决定了这些代码能跑得多快、多稳。

关键问题变成了：

• 你能快速地发布软件（并且在出问题时同样快速地回滚）吗？
• 你能一键拉起新的后端服务来支持新的功能吗？
• 你提供的内部工具 API 是否对 AI Agent 友好？

所有核心基础设施——指标、日志、告警、功能开关、发布管道、自动伸缩、编排引擎、配置管理、缓存、网络——这些东西如果做得好，就是整个团队（包括 AI）的效率倍增器。

2026 年，那些能把基础设施做成高效"自助服务"的公司，会获得显著的竞争优势。

2. CI/CD 质量前所未有的重要

当 AI Agent 写的代码比例越来越高，CI 基础设施的质量和保真度就成了关键防线。

过去我们容忍了一定程度的测试覆盖不全——因为写测试确实不讨人喜欢，枯燥、机械、感觉像在"纳税"。

但 LLM 没有这个心理障碍。AI 写测试是没有情绪的。这意味着没有任何借口不做到接近穷尽的测试覆盖。

反过来看，这也意味着传统的单元测试可能需要升级——比如属性测试（property testing）、底层模块的形式化验证（formal verification），这些过去被认为"太麻烦"的实践，在 AI 时代反而有了用武之地。

3. 清晰的抽象边界变得更加关键

这是最容易被忽视的一点。LLM 在没有强约束的情况下，会倾向于生成"投机取巧"的代码来让 CI 检查通过。 时间长了，代码库会以肉眼可见的速度变得像"意大利面条"。

这就是"系统品味"（systems taste）的重要性。经验丰富的工程师能在架构设计阶段就做出好的决策：模块边界在哪里、接口契约长什么样、基础设施层和产品层的分界怎么划。

没有这些清晰边界的系统，在 AI 辅助开发下，技术债务的积累速度会比过去快得多。

原因很简单：过去一个开发者修改代码会"手动"感知代码的味道是否对了——哪个模块该不该做这件事，做多了会觉得不对劲。但 AI 没有这种直觉。AI 只知道"让这个 CI 检查通过"。

4. 代码审查成为新的核心瓶颈

这听起来有点反直觉——AI 能写代码，那还需要人来审查吗？

需要，而且需求更大了。

AI 生成的代码质量已经比去年好很多，但仍然很容易让你陷入技术债务的泥潭——只需几个结构糟糕的 PR 就够了。

人类代码审查需要发展出一种新的"审查品味"：

• 风格问题应该推到自动 lint 和格式化工具里去处理
• 人类审查应该聚焦在更高的层面：这个抽象是否有意义？这个接口设计是否合理？未来的维护者能否理解这个实现？

换句话说，我们正在把代码审查往"真正的架构评审"方向推。

5. 产品团队 vs 基础设施团队：增量的不均衡

LLM 似乎特别擅长前端和产品层的代码——有大量的类似模式可以参考，Greenfield 工作的占比也更高。相比之下，基础设施层的代码往往更独特、更需要领域知识、更"非典型"。

这意味着产品团队从 AI 工具中获得的效率提升可能更大。基础设施团队也不会被落下，但他们的主要任务变成了：把基础设施做得足够"好用"，让人类和 AI 都能自助使用。

2026 年软件工程师的新技能包

以上变化，对软件工程师意味着什么？

做抽象的人

"设计好的抽象"正在成为工程师最值钱的技能。这包括：

• 知道什么时候该抽象，什么时候不该
• 能设计出既灵活又简单的接口
• 能预见未来变化的方向，但不过度设计

理解系统的人

AI 能写函数、能写组件、能写 API。但 AI 不理解"为什么你的系统需要这个 API"、"这个 API 的瓶颈在哪里"、"如果流量翻十倍会怎样"。

理解系统的人——能从头到尾讲清楚一个请求的完整旅程的人——在 AI 时代反而更稀缺了。

做 review 的人

掌握"架构级审查"的技能：不只是"这里少了个分号"，而是"这个模块的边界不对，它做的事情太多了"。

做决策的人

技术上该选什么方案？什么时候该重构，什么时候该忍受？这个功能值不值得做？

AI 能帮你写代码，但不能帮你做决策。

值得关注的风险

LLM 生成的代码质量远非完美。几个月前我写了一篇文章分析它的一些技术债务问题——即使 LLM 写的代码能让测试通过，它也可能存在微妙的架构问题，只有在几个月后的扩展过程中才会显现。

更麻烦的是，如果审查者本身也依赖 AI 来辅助 review，那这种"AI 写、AI 审"的循环里，谁在真正负责质量？

答案只能是：人。

所以更大的投资应该放在：怎么让人类 review 者更容易地聚焦在重要的问题上，而不是被鸡毛蒜皮的风格问题淹没。

总结

2026 年的软件工程，AI 不会取代工程师。但 AI 会重新定义"工程师到底在做什么"：

那些把基础设施做得又好用又可靠、能设计出清晰抽象边界的工程师，会发现自己比以前更有价值。那些只会写 CRUD 接口的工程师，则面临被 AI 替代的风险。

不是 AI 抢了你的饭碗。是会思考的人用 AI 抢了不会思考的人的饭碗。