热闹点在编码，难点在系统

眼下最常见的误判，是把“AI 让写代码变快”直接等同于“AI 解决了软件工程”。

这两个判断之间差得很远。写代码只是软件工程对外最显眼的一层，系统真正难的部分，经常藏在更前面和更后面：需求到底是什么、边界怎么切、什么地方必须一致、什么地方可以延迟、谁来承担错误成本、系统在真实环境里改了十次之后还剩多少可理解性。这些问题不会因为代码生成更快就自动消失。

如果只看 2025 AI Index，你很容易被能力进展震住。SWE-bench 的表现一年内从 4.4% 涨到 71.7%，看起来像是机器已经冲到了软件工程腹地。可如果再看 METR 对真实开源开发者的随机对照实验，你又会发现另一面：在高上下文、强约束的成熟仓库里，AI 并没有自动把开发速度整体拉上去，反而平均慢了 19%。

这组反差说明，AI 正在重写“编码”这件事，却还没有证明自己已经重写“软件系统”。

《人月神话》先提醒过一次：难点从来不只是人不够多

很多人今天谈 AI，口气像是在重复几十年前另一种旧信念：只要把产能再放大一点，软件工程的难题就会自然塌掉。

《人月神话》真正值得今天再读的地方，不是那句流传很广的“往一个已经落后的项目加人会让它更晚”，而是 Brooks 整本书都在讲的一件事：软件项目不是靠堆产能就能稳定推进的活动，它需要概念完整性、清晰边界和一致设计。Pearson 的 20 周年版目录里仍然把 The Second-System Effect、The Whole and the Parts、No Silver Bullet 放在同一本书里，意思很明确：规模、协调和系统结构，才是软件工程最顽固的问题带。

把这个命题放回今天也成立。AI 可以把一个团队的局部实现能力放大得很夸张，但一旦系统本身缺少统一概念，产能越大，漂移越快。它不会自动帮团队长出“概念完整性”，反而可能更快把缺失放大出来。

Brooks 说的“本质复杂性”，今天依然没有消失

Brooks 在《No Silver Bullet》里最重要的区分，是把复杂性分成了 essence 和 accident，也就是本质复杂性和偶然复杂性。

偶然复杂性来自表达手段和实现手段的限制。比如语言太底层、工具太差、样板代码太多、构建流程太繁琐。这一层，AI 的确正在大幅削减。今天很多人用 Claude Code、Cursor、Copilot 或内部 agent 写出一个初版页面、一个接口封装、一组测试脚手架，比过去快太多了。

但 Brooks 所说的本质复杂性，指的是系统概念本身的复杂性。它来自几个地方。

  • 现实世界本来就充满歧义、例外和冲突。
  • 软件要维持大量互相咬合的概念关系。
  • 系统一旦进入真实环境，就要同时面对历史包袱和未来变化。
  • 正确性、性能、安全、可维护性、成本之间很少能同时最大化。

AI 可以帮你更快表达这些关系，却没有证据表明它能让这些关系本身消失。系统仍然要面对多个目标之间的张力，仍然要面对不同角色对“正确”的不同定义，仍然要在变化的业务和组织里不断重写边界。

换句话说，AI 更像是在压缩软件的书写成本，而不是取消软件的概念负担。

Parnas 讲的是模块化，真正指向的是未来变化

Parnas 1972 的经典论文经常被简化成一句“信息隐藏”，但那篇文章真正锋利的地方，是它把模块划分从“今天怎么分工”改成了“明天哪里最可能变化”。

这在 AI 时代更重要。代码生成一旦变得足够便宜，团队就更容易容忍局部实现混乱，更容易觉得“先做出来再说”。但模块边界不是为了今天看起来整齐，而是为了未来改动时不把整个系统一起扯坏。

Parnas 的问题意识是：你到底是按处理流程切模块，还是按可能变化的秘密来切模块。如果是后者，模块化是在为未来不确定性买保险。

AI 并不会替你回答这个问题。它当然可以按你的要求吐出十个模块、二十个类、五十个函数，但这些边界究竟是不是围绕未来变化来划，仍然需要人来判断。代码生成能力越强，信息隐藏的重要性往往越高，因为错误边界也会被更快地批量复制。

Conway 讲的是组织，复杂性因此不只是一件技术事

如果说 Brooks 和 Parnas 主要在讲系统内部结构，那么 Conway 的论文提醒的是另一层：系统结构会映射组织沟通结构。

这对“AI 能不能消灭复杂性”是一个经常被忽略的问题。很多软件复杂性不是单纯长在代码里，而是长在协作关系里。一个支付系统为什么会复杂，不只是因为业务规则复杂，也因为风控、财务、合规、产品、运营和工程团队之间本来就存在不同目标和不同节奏。

Conway 的原文里讲得很直白：组织如何被切开，系统就会被切成什么样。今天引入 AI 之后，这个命题并没有失效，反而更尖锐了。agent 可以替团队完成更多局部实现，但它并不会自动重构组织之间的目标冲突、权责边界和沟通成本。

因此，“AI 会直接把架构复杂性吃掉”这个判断很难成立。只要组织还是多目标系统，软件就还会继续带着这些目标之间的摩擦往前长。AI 最多帮助你更快响应这些摩擦，不能让它们消失。

Lehman 讲的是演化，说明复杂性是会自己长出来的

Lehman 的软件演化定律可以直接拿来观察今天的 AI 叙事。

后来的研究综述和开源项目分析反复重述了两条最关键的规律。第一，E-type 系统如果不持续适应环境，就会越来越不令人满意。第二，系统随着演化会持续增加复杂性，除非团队有意识地投入工作去控制或降低复杂性。

这两条规律和 AI 时代几乎是正面相撞的。AI 最擅长的事情之一，就是把“继续往上加一点功能”的门槛压低。功能更容易加了，原型更容易搭了，局部重构更容易做了，团队就更可能以更高频率持续修改系统。可修改频率升高，不等于系统会自然变得更整洁。很多时候恰好相反，修改变便宜了，演化债也会累积得更快。

Lehman 的提醒很直接：复杂性不是一个等着你清扫完毕的存量问题，它是系统和环境持续互动后不断再生的增量问题。只要软件还要服务现实世界，它就不会因为某一代工具足够强而终止演化。

AI 真正削掉的是哪一段

也不能因为 AI 没有消灭复杂性，就假装它没有改变软件工程。

它改变得很深，只是改变的位置要说准。

  • 它大幅压低了样板代码、局部实现和初版试错的成本。
  • 它让很多过去只属于熟练工程师的探索动作变得大众化。
  • 它把不少“写出来”型工作，转成了“说清楚、看明白、收好口”型工作。
  • 它让很多偶然复杂性从前台退到后台。

这也是为什么很多开发者会有一种强烈体感：代码变便宜了。这个判断没错。需要补上的一句是，代码变便宜，不等于系统变简单。

真正危险的，不是相信 AI，而是把它误认成新银弹

每一轮工具跃迁都会制造同一种判断：这次不只是改良，而是根治。

Brooks 当年反对的是 CASE 之类技术被宣传成银弹。今天被重新包装的对象换成了大模型和 coding agent，但逻辑很像。只要有人把“局部提效很惊人”直接翻译成“软件工程的复杂性问题已经被根本解决”，后果就会很具体。

这个风险至少有三层。

  • 团队会低估规格、边界和架构判断的重要性。
  • 组织会把新人训练、人工评审和长期维护错当成可以直接省掉的成本。
  • 系统会在短期高产之后，更快地积累看不见的演化债。

AI 正在解决软件工程里最容易被工具化的那部分问题；但只要软件还是嵌在现实世界、组织结构和持续演化里的系统，就没有足够证据表明它已经消灭了软件复杂性的根。