50年前的一本奇书，早已预测了AI编程的未来！

0 1

50亿美元的豪赌，写出软件工程的圣经

有一本书，广为人知，经常被引用，偶尔被阅读，但很少被遵循。

这本书就是50多年前出版的，被誉为软件工程“圣经”的《人月神话》。

布鲁克斯在写这本书之前，是IBM System/360 操作系统项目的开发经理。

System/360则是IBM的一场豪赌，一共投入50亿美元（相当于今天的400亿美元），可以说是一把梭哈。

如果这次押注失败，IBM就得当场关门。

System/360的目标现在听起来有点“可笑”：用同一套架构覆盖从小型到大型的全部机器，所有机器都运行同一套软件，构建同一套操作系统OS/360。

项目从1961年开始，IBM整体动员了数万名员工参与设计、制造、测试、生产与支持工作。

在一个连“软件工程”概念都存在的年代，2000多名软件工程师，竟然开发了上百万行代码。

不出意料，项目出现了严重的混乱，复杂度被严重低估，需求不断变化，项目不断延期。

布鲁克斯后来形象地描述：软件开发就像“焦油坑”，表面看似平稳，但动物一旦掉进去，越挣扎陷得越深，很难脱身。

这些经历直接催生了后来著名的布鲁克斯定律：

“向已经延误的软件项目增加人手，只会使项目更加延误。” —— Brooks’s Law

项目结束以后，布鲁克斯意识到：软件开发的失败不是因为程序员不努力，真正的问题在于管理方式、沟通结构和复杂系统设计，于是他把IBM的踩坑经历整理成了一本书：《人月神话》。

02

50年前的预言，撞上今天的AI编程

《人月神话》和现在火热的AI编程有什么关系呢？

它提出了两个软件开发的核心概念：本质复杂性和偶然复杂性。

1.本质复杂性：

这是和问题本身固有性质相关的复杂性，例如操作系统内核设计，需要管理内存，进程调度，设备驱动，各个领域会互相纠缠，互相影响。再比如航空航天控制系统，涉及极高的实时性，多传感器融合，安全约束等。

这种复杂性无法通过更好的工具或方法完全消除，它决定了软件系统本身的“难度下限”。

2.偶然复杂性

它来自工具、方法或环境本身的复杂性，不是问题本身固有的。这种复杂性可以通过更好的工具、语言、框架或方法减轻甚至消除。

例如早期大家都用汇编语言，写程序需要手动管理寄存器、内存地址，软件开发极其复杂，效率极低，但是Fortran, COBOL等的高级编程语言以后，效率一下子就飙升了。

用一句话来总结：

本质复杂性 = 你必须要解决的问题

偶然复杂性= 你可以通过更好方法消除的麻烦。

很明显， AI编程可以极大程度地消除“偶然复杂性”，现在它已经接管了大量繁琐、重复但必要的工作，无论是理解代码库，生成代码，还是测试、调试，都干得相当不错。

那么问题来了，大模型能解决本质复杂性吗？

那些最聪明的头脑都搞不定，更别说现在的AI编程了，最近很火的AI写浏览器/编译器频繁翻车很好地说明了这一点。

即使是最先进的AI，也不能让问题本身变简单，离开了人的指导，在复杂的领域，AI编程也无所适从。

但是，AI能把人工处理本质复杂性的负担降低，让人更专注于本质决策。

例如，我要设计“设计分布式数据库一致性协议”，AI可以生成示意图、提供多种算法实现、检查潜在死锁。设计仍需人决定，但可以少做很多低级推演和文档工作。

再比如我想重构一个大型遗留系统，由于旧系统业务非常复杂，部门之间还有依赖，数据迁移有风险，这些都是本质复杂性，用工具无法消除，但是AI可以自动梳理代码依赖图，标记风险模块，自动生成回归测试。

0 3

复杂性不会消失，只会转移

AI编程很强，但是它很可能会走上前辈们（高级编程语言，各种辅助工具）走过的同一条道路：

工具变强->偶然复杂性被削弱->软件系统变得更大更复杂->本质复杂性更强

原因很简单，当实现成本下降，人类不会停在原来的复杂度水平，产品经理会加功能，市场会要求差异化，客户会定制需求，公司会做更多整合......

这直接推动功能数量，模块数量，交互路径，状态空间飞速上升，本质复杂性迅猛增加。

几十年前，一个程序员用汇编只能编写简单的软件，如今用Java、Python可以轻松写出复杂的系统。

用汇编写的OS/360，百万行就是巅峰，现在Linux 内核有3000万行代码，Windows 10有5000万行代码，Chrome，3000万行代码，而现代的云系统更加恐怖，是数亿行代码级别的代码宇宙！

现在AI编程来了，代码的成本变得近乎为零，天知道将来的软件会长成什么样子。