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編程來了，代碼的成本變得近乎為零，天知道將來的軟件會長成什么樣子。