一個心智，被放大
在大約三個月內，tlslane 從一個空的儲存庫，變成一套從零寫起的 TLS 1.2/1.3 協定堆疊、一條 eBPF inline 資料路徑、一個 Go 控制平面，以及一支持續運行的跨區域浸泡測試機隊—由一個人完成。大家一直問我的是那個速度。它是最不重要的部分。重要的是，這個東西沒有散掉—而 Fred Brooks 在五十年前就說明了它為何不會散。
不是速度—是完整性
大家會想找一個倍數。隨你挑一個；它一碰到真相就站不住。AI 並沒有敲出五十個開發者份量的程式碼。真正重要的不是寫了多少，而是寫出來的是一個系統：pipe 是單一的「事件→轉換」核心；同一套命名慣例，從最底層的 record-layer 類別一路貫穿到頂端；同一套由下而上、測試先行的方法，先建好 Tls_record 才建 Tls_pipe，每一層都先被信任，才蓋上一層。這個性質有個名字，而它不是「生產力」。
Brooks 真正說的是什麼
在《人月神話》（1975）裡，Fred Brooks 主張概念完整性是系統設計中最重要的考量—擁有一套連貫的想法，勝過許多各自優秀但彼此獨立的想法。他那個嚴酷的結論—「Brooks 定律」—隨之而來：往一個已經延遲的專案裡加人，只會讓它更延遲。不是因為人不好，而是因為一個設計會在持有它的眾多心智之間裂解，而 n 個人之間的溝通路徑，是以 n² 成長的。他開的藥方是外科手術團隊：一位主刀者擁有整個概念，其他所有人都在放大這一個人的意圖，而不是去協商一個對立的意圖。
對 AI 的直覺解讀，是它增加了開發者—團隊變大，所以 Brooks 定律應該咬得更兇。這個解讀是反的。
是助手，不是第二位主刀者
一個握有專案完整脈絡的代理，是主刀者的助手。它並不持有一個與你競爭的系統心智模型；它持有的是你的，並依此執行。沒有第二位架構師要去磨合，沒有介面委員會，沒有一條「協商出來的設計」接縫貫穿整個程式碼庫的正中央。於是 Brooks 警告的那個 n² 溝通成本從未出現，因為 n 仍然是一。你得到的不是五十個心智；是一個心智的模型，以過去需要許多人才能達到的速度呈現出來—而過去正是那個速度，會把讓它值得被打造的完整性給弄丟。第一次，「連貫單一願景」這條路，和「這一季就出貨」這條路，是同一條路。
接著我試著把它分散出去，而 Brooks 又對了
接下來這一段才是說服我的部分，因為它是一次失敗。tlslane 是跨平台的，所以我試了那個顯而易見的做法：在 Mac 和 Windows 機器上各跑一個代理，就地、原生地做各自平台的工作。結果更糟，不是更好。脈絡在每一個邊界上流失。每台機器上的代理，對整個系統都只有一幅局部的圖像，而重新同步這些圖像的通道，是我—用手把狀態搬過去。我等於用縮小的規模，重建了 Brooks 警告的那個東西—設計在持有者之間裂解、溝通稅重新出現—只是現在那條昂貴的溝通鏈路，是一個在房間之間搬運脈絡的人。
這種工作方式的瓶頸不是打字，是脈絡重建。每一次交接—交給另一台機器、另一個代理、另一段工作階段—都要付一筆重新推導的稅，並且冒著概念漂移的風險。真正行得通的配置，恰恰是分散的相反：一個代理、一台機器，把所有構成這個專案記憶的東西都放在同一處—儲存庫、工作筆記、工作階段歷史、浸泡機隊的完整紀錄。真正出貨的那個 Windows 移植，是從那一台機器驅動的，用 CI 和遠端 VM 作為驗證基座，而不是靠一個被困在 Windows、只握有一半脈絡的代理。
Brooks 的另一半
Brooks 另一篇著名的文章〈沒有銀彈〉，把軟體的困難一分為二：設計本身的本質複雜度，以及表達這個設計所牽涉的一切的偶然複雜度。他賭沒有任何單一工具能帶來一個數量級的躍升，因為本質的那一半—決定這個系統是什麼—無法被自動化掉。
這三個月沒有推翻他；它讓那條線更清晰了。偶然複雜度崩塌了—樣板程式、一個解析器的第二和第三次實作、接線的瑣事。本質複雜度則正好停在他說它所在之處：在一位架構師的腦袋裡，決定 pipe 不做任何在地決策、決定工作階段的身分來自 TLS 內容而非四元組、決定一個按成因拆分的計數器能抓到一個加總計數器抓不到的歸因錯誤。這些判斷是我的。工具只是不再逼我為了把它們寫下來，去付那筆偶然的稅。
所以這個故事誠實的版本，不是「AI 讓我變快」。而是那種連貫願景式的軟體打造方式—Brooks 的理想，那個通常慢到熬不過一個截止日的理想—忽然變成了負擔得起的那一個，只要你維持它是一個心智，而不把脈絡打散。這就是這裡一切被打造出來背後的紀律，也是我們帶進一次遷移案的東西。
← 所有文章