夜雨聆风导语
近一两年，生成式 AI 加速进入软件研发流程，"AI 能否替代程序员"的讨论随之增多。然而从软件工程的长期视角看，这一问法容易模糊焦点。要厘清 AI 的真实作用边界，不妨回到一个已沿用近四十年的经典框架——它比多数热点争论更经得起时间检验。
一、软件工程有两种复杂度，别混为一谈
1986 年，Fred Brooks 在《人月神话》里有一篇著名的文章《没有银弹》。他提出：软件工程的"难"，其实分两种。
第一种叫"偶然复杂度"，是工具、语言、环境带来的麻烦。比如为了连个数据库要写一堆样板代码，为了对接两个系统要写大量胶水逻辑，为了跑通流程要补一堆机械的单元测试。这些"难"并非问题本身所固有，而是源于工具与语言表达能力的局限，使工程人员被迫在低价值环节投入大量重复劳动。
第二种叫"本质复杂度"，指问题域本身的难度。需求存在模糊性，业务之间可能存在冲突；系统规模扩大后，某处改动会牵动哪些环节，往往难以厘清；需求本身也处于持续变化之中；更为关键的是，软件没有实体形态，无法像建筑那样直观地判断其结构是否失当。
这个区分的关键在于：四十年来，被工具持续消解的始终是“偶然复杂度”；“本质复杂度”则几乎未被触及。
二、AI 削减的，正是“偶然复杂度”
客观地说，AI 在软件工程中削减的，正是"偶然复杂度"，且成效显著。
样板代码、胶水逻辑、标准的增删改查、文档与注释、已知模式的重复实现——这些过去占去工程师大量时间的任务，如今可由 AI 快速产出初稿。McKinsey 的研究显示，代码文档时间已可减半，新代码编写次之；越是接近偶然复杂度的任务，AI 加速越明显。团队引入 AI 编码工具后，产能提升有实际依据，它确实大幅降低了"编码"环节的成本，但不等于"软件变简单了"。
一个值得注意的数据来自 LinearB 在 2026 年对 810 万次代码合并请求的分析：使用 AI 的开发者完成了 21% 更多的任务，但代码审查时间增加了 91%。产能上去了，验证的负担同步上升——这个信号指向了下一节的问题。
三、AI 解决不了的那块，才是企业真正的痛点
本质复杂度所涵盖的四个方面，AI 至今难以有效处理，且在可预见的未来仍难以替代人。
需求模糊。业务方往往难以清晰表述需求，合规与体验孰先、目标客群如何界定——这些判断 AI 无法替企业完成，因为它不了解企业自身的经营语境。
跨系统耦合。一家企业跑着十几套系统，改会员中心会不会影响风控、动了订单会不会牵动财务，这种全局权衡靠的是对"整盘棋"的理解，不是对一段代码的补全。
变化。规则每月都在变，监管、市场、组织架构都在动。AI 能帮你改，但"该往哪改、改到什么程度算够"，仍要人拿主意。
不可见性。软件没有实体，质量藏在逻辑里、风险藏在依赖里。谁来判断"这段代码到底稳不稳、值不值得信"，谁为它上线后的后果负责——这件事，AI 给不了"人"的背书。
这四件事，正是质量、架构、治理这些角色存在的理由。它们不是"手艺"，是"系统思维"——而系统思维，只能属于人。
四、AI 还在制造新的复杂度
很多人只看到 AI 消解了旧的复杂度，忽略了一点：AI同时在制造新的复杂度。
2026 年初，维多利亚大学教授 Margaret Storey 提出"认知债务"（Cognitive Debt）概念：当开发者依赖 AI 快速生成代码但不在每轮中增长理解时，团队会逐渐积累一种与技术债务不同的债务--没有人能解释为什么某些设计决策被做出，系统的不同部分应该如何协同。技术债务在代码里，可以被工具发现；认知债务在人脑里，只能通过行为检测。
同年，Zhu、Tsantalis 和 Rigby 的研究发现了"推理-复杂度权衡"现象：更强的模型倾向于产出更臃肿、耦合更重的代码，而非更清晰的架构。功能正确性并不预测可维护性，代码量几乎可以预测结构退化的程度。这意味着 AI 编码工具本身在引入新的偶然复杂度（膨胀、重复、过度抽象），同时让本质复杂度（架构理解、变更影响判断）更难把握。
行业数据进一步印证了这一趋势。MIT Sloan 的研究显示，AI 生成代码中的重复代码块增长了 8 倍，代码改动率翻倍；Harness 的调查显示，92% 的开发者认为 AI 代码增加了部署的"爆炸半径"。代码出得快了，仓库里待审查、待治理的对象成倍变多；AI 依据提示自动引入的依赖和生成的配置，带来新的安全攻击面；一段未经充分审查便合入的 AI 代码，会持续累积不可审计的技术债。
有一种观点认为，软件复杂性是守恒的——它只能从一种形式转化为另一种形式。AI 没有让复杂度消失，而是把复杂度从"怎么写"搬到了"怎么验、怎么管、怎么信、怎么负责"。
五、开发者的角色正在转变：从"写代码"到"守完整性"
上述变化催生了一个新的角色定位。2026 年的研究共识指向一种转型：开发者正从"代码创造者"变为"技术完整性的守护者"。
这个角色的核心能力不是写代码，而是判断 AI 生成的代码是否符合架构标准、识别 AI 输出中的幻觉和次优模式、评估变更对整体系统的连锁影响、在信息不完整时做出风险判定、对"是否可信、由谁负责"给出结论。
换言之，AI 把"编码"环节的成本降下来了，但"判断"环节的成本和权重反而上升了。企业真正需要投入的，不再是"会不会用 AI 写代码"，而是"有没有能力判断 AI 写出来的代码能不能用、敢不敢用、由谁负责"。
六、这对企业意味着什么
结论比较直接：AI 普及之后，偶然复杂度被持续消解，本质复杂度仍须由人管理，且因新的治理对象出现而更显突出。
对采用 AI 编码的企业而言，质量与合规不再只是上线前的一道检查，而成了需要持续投入的常态能力——有没有建立治理框架、治理框架是否真正在运行、AI 生成的代码是否处于受治理状态、出了问题能否追溯到责任人。这些工作，恰恰对应前文所述的本质复杂度。
我们也因此调整了自己的定位：不去和 AI 拼"谁写得快、谁扫得准"，而是做企业 AI 开发里的系统思维外包--AI 干手艺，我们干判断、干规范、干兜底。
顺着这个思路，我们整理了一套《AI 代码治理成熟度模型（AICG-MM）》。它的设计逻辑与本文一脉相承：将"工具是否到位"作为门槛基线，将"组织能否治理本质复杂度"作为认证核心——从风险研判、架构权衡、变化适应、责任归属，到 AI 时代特有的"认知债务管理"，用行为化评估而非文档审查来定级。
七、写在最后
"AI 能不能解决软件工程的复杂度"——这个问题本身问错了。
更准确地说：AI 大幅消解了偶然复杂度，却将本质复杂度原封不动地留给人，并叠加了一层新的治理复杂度。 软件的复杂度并未消失，只是从"写"转移到了"验"和"判"。谁能帮助企业承接这部分"只能由人完成、AI 无法替代"的工作，谁就将在 AI 时代占据一席之地。
如果您也在思考"团队引入 AI 之后，质量与治理由谁负责"这一问题，欢迎交流具体场景。我们可以协助企业把"可治理、可负责"落到实处。