你可以想像這樣的畫面。
2026 年的深夜，一個 PM、一個技術主管，或一個創業者，坐在電腦前，按下一個按鈕。下一秒，十個、五十個、甚至一百個 Agent 同時開始工作：有人讀 codebase、有人補測試、有人修 bug、有人整理文件、有人寫 PRD、有人驗證功能。螢幕上的任務像流水線一樣往前推，原本要好幾個人來回交接一週的工作，如今可能幾個小時就跑完。
這一刻，很多人心裡會冒出同一個問題：
《人月神話》還算數嗎？
那本書最有名的一句話，是 Brooks Law：一個已經落後的軟體專案，增加人力，只會讓它更落後。這句話經典了半個世紀，不只是因為它說中了軟體專案常見的痛點，更因為它抓到一件本質上的事：軟體開發不是搬磚。它不是把人往裡面一直加，產能就會線性上升。軟體是知識勞動，知識勞動最麻煩的地方，從來都不只是人手不夠，而是理解、協調、抽象、取捨與責任分配都很昂貴。
我最近重讀《人月神話》，最大的感受不是它過時了，反而是它被今天的技術照得更清楚。
Brooks 所在的時代，人和人之間的溝通成本很高，文件常常不完整，知識傳遞也很慢。新人加入專案，需要一段不短的時間才能搞懂脈絡；資深工程師需要花很多精力帶人、補洞、收尾。每多一個人，團隊內部的溝通路徑就變多，專案管理的摩擦也會跟著膨脹。這些條件，構成了人月神話成立的背景。
到了今天，這些前提確實鬆動了。
像 Claude Code，已經不是單純在編輯器裡補幾行程式碼，而是直接住進 terminal，能讀整個專案、改檔、跑指令、建立 commit，還能透過 MCP 把 Google Drive、Slack、Figma 這類外部脈絡一起拉進工作流。Codex 則把軟體生產往平行委派再推一步：它可以在雲端隔離環境裡，同時處理多個任務，寫功能、修 bug、回答 codebase 問題，最後再提出 pull request。Google Antigravity 走得更前面，它把 agent 從「協助你寫」提升成「替你跑完整條鏈」：官方描述裡，agent 可以直接操作 editor、terminal 和 browser，自主規劃、執行並驗證端到端的軟體任務。OpenClaw 雖然不是純 coding IDE，但它把 agent 變成可從 WhatsApp、Telegram、Discord、iMessage 等入口隨時叫起來的 gateway，等於連「叫人做事」這件事本身都被進一步自動化了。
如果用《人月神話》的語言來看，這一代工具確實解掉了一部分老問題。
第一，是 onboarding 成本下降了。以前新人進來，要先找文件、問同事、讀歷史 commit，再慢慢拼出專案的全貌。現在，Agent 可以先幫你把 repo 結構、關鍵模組、文件脈絡、ticket 背景整理出來。理解專案的起跑點，被大幅往前推。
第二，是局部協調成本下降了。過去很多工作卡在等待：等某人修完、等某人交接、等某人回覆、等某人把測試補齊。現在，多個 Agent 可以平行處理不同子任務，把原本一條線上的工作拆成多條線同時前進。
第三，是執行成本下降了。修 lint、補文件、寫測試、整理 release note、處理零碎 bug，這些很耗體力卻不一定高價值的事情，開始被大量吸收。也就是說，Brooks 當年看到的那種「人一多，專案反而變慢」的局部困境，今天的確被打穿了一部分。
但焦油坑沒有消失。它只是往上游移動了。
以前專案出問題，常常卡在人與人之間。需求沒講清楚、交接漏了、文件過期了、某個新人還沒進入狀況。今天的新工具把很多這種摩擦壓低了，於是更上層的問題全部浮出來：需求到底清不清楚？規格是不是一致？誰定義什麼叫做完成？哪一段上下文是舊的，哪一段是新的？哪些權限可以交給 Agent，哪些不能？如果它做出了看起來很完整、其實方向偏掉的結果，最後誰來收斂？
這就是今天最值得警惕的地方。
Agent 的執行速度越快，模糊意圖的代價就越高。以前一份說不清楚的需求，可能只是讓兩三個工程師多走一點冤枉路；現在，一個有問題的 prompt、一份邊界模糊的 spec、一次過期的脈絡注入，可能會讓整串自動化流程高速地把錯誤放大。做錯事的人變少了，做錯事的速度變快了，影響範圍也變大了。
而且，當 agent 已經可以動到 terminal、browser、外部資料源，風險就不再只是「寫錯 code」而已。它還包含權限治理、資料外洩、驗證失靈、責任斷裂。OpenAI 在介紹 Codex 時，特別強調每個任務都跑在獨立 sandbox；Anthropic 也把 Claude Code 的安全實務獨立拉成一整套文件；OpenClaw 官方文件更直接提醒，sandbox 不是完美邊界，workspace 也不是硬隔離。這些提醒本身就說明了一件事：今天真正需要被治理的，不再只是人的協作成本，還有 agent 的行動半徑。
所以我現在更傾向這樣理解《人月神話》在 AI 時代的新版本：
它沒有被推翻。它只是被重新定位了。
Brooks 當年提醒我們，軟體開發不能用工業時代那種「多加幾個人就會更快」的線性思維來理解。今天，Claude Code、Codex、Google Antigravity、OpenClaw 這類工具，確實讓局部執行、局部協調、局部理解變便宜了。它們打掉了一部分「加人必慢」的老摩擦。但它們同時也把真正困難的問題推到更前面：問題定義、系統邊界、權限設計、驗證機制、責任歸屬，還有最後那個最難、也最不能外包的問題——到底誰在替整個系統做判斷？
這裡，才是 AI 時代新的焦油坑。
以前的瓶頸，多半出現在「做的人太多」；現在的瓶頸，更常出現在「定義的人太少」。以前最貴的是執行；現在執行越來越便宜，意圖治理反而變成最昂貴的部分。你可以派很多 Agent 去完成很多局部工作，但整體到底要往哪裡收斂，還是需要有人負責。功能可以分派，判斷不能自動長出來。流程可以加速，責任不會因為工具變聰明就自然消失。
這也是我想寫這個系列的原因。
我不想用一句「《人月神話》已死」來換一個輕鬆結論。那樣太快，也太淺。比較值得做的，是重新檢查：當溝通成本被壓縮、文件整理被自動化、局部執行能夠被大量代理之後，軟體工程裡還有哪些困難沒有消失？它們今天換成什麼形式回來？我們以為自己已經走出了焦油坑，結果只是把坑從會議室搬進了上下文、從人際協調搬進了系統治理、從團隊管理搬進了權限與責任設計。
技術確實讓很多事情變快了。
但快，從來不是免費的。
只是帳，現在記在別的地方。
而那個新的帳本，正是這個時代最值得重讀《人月神話》的理由。
