在矽谷技術圈的聚光燈下，一場關於軟體工程本質的動搖正在發生。Netflix 資深工程師 Jake Nations 在一次公開演講中，以一席「告解」揭開序幕：「我發布了我不懂的程式碼，而且我敢打賭，你們也一樣。」
這不僅是一個人的疏忽，而是當代開發者普遍面臨的技術反差。透過生成式 AI，開發者得以在數小時內清掉原本需耗時數天的 Backlog。然而，在這種空前的開發速度（Speed）背後，隱藏著 理解深度（Understanding）的急速萎縮。
換言之，當測試通過、代碼部署，開發者卻無法解釋系統運作的核心邏輯時，我們正步入一個「能跑但看不懂」的危險領域。這不再只是效率的提升，而是軟體工程史上第三次大規模危機的開端，一場隱形的技術債正在這場「無限生成」的狂歡中加速累積。
進步的幻覺：從 Dijkstra 到 AI 的無限規模危機
歷史總是在「手段」與「目標」的失衡中重演。1960 年代末期，電腦科學家艾茲赫爾·戴克斯特拉（Edsger W. Dijkstra）曾精確指出： 當硬體性能提升千倍，軟體開發的複雜度會呈比例膨脹，將人類的認知邊界逼至極限。
過去半世紀，每一代技術都試圖用「機械性的修補」來解決「認知層面的複雜度」，但最終都演變成了新的負擔：
- 1970s-1980s（C 語言與 PC）： 為了編寫更大系統而生的結構化語言，卻因開發門檻降低而引發了軟體數量的第一次爆炸。
- 1990s（Java/OOP）： 試圖透過封裝解決問題，卻製造了讓人窒息的「繼承地獄」。
- 2000s-2010s（Agile/Cloud）： 放棄瀑布流、擁抱雲端，試圖用更快的迭代節奏管理複雜度，卻導致系統分佈化後的依賴性呈指數級增長。
- 2020s（生成式 AI）： Copilot 與 Claude 讓我們能以描述的速度生成代碼。
Nations指出，這是一場認知戰的全面潰敗。我們並非首次面對危機，但這是人類史上首個「無限生成規模（Infinite Scale of Generation）」的危機。當生成的數量與速度徹底甩開人類的理解力，我們不再是系統的建築師，而成了被 AI 餵養的代碼搬運工。
核心取捨：為什麼「易用」正在殺死「簡潔」？
Nations認為，開發者之所以墜入陷阱，是因為混淆了兩個看似相近、實則對立的架構哲學。借用 Clojure 創始人 Rich Hickey 的框架，我們必須看清這場商業騙局：
- 簡潔 (Simple)： 意指「單一交織（one-fold）」。它關乎系統的結構——每個組件職責單一，沒有纏繞。這需要深邃的設計思考與刻意的捨棄。
- 易用 (Easy)： 意指「近在咫尺（adjacent）」。它關乎獲取難度——無需努力就能觸及，像是複製貼上、或是點擊 AI 按鈕。
這個意思是，AI 是有史以來最強大的「易用按鈕」。它消除了開發的摩擦感，卻也主動摧毀了追求「簡潔」的動力。當架構決策被「現在的快速」取代，我們實際上是在吸食一種名為「無摩擦感」的毒品。
但關鍵是，「易用」不代表「簡潔」，它往往是複雜度的掩體。 每一次選擇讓 AI 瞬間生成代碼而不去理清依賴，我們都在預支未來的技術生命力。
案例深挖：Netflix 授權系統重構的失敗啟示
Nations表示，Netflix 曾試圖利用 AI 代理重構一套使用了五年的舊授權系統（Authorization System）。這場實驗撕開了 AI 在處理軟體工程「真實世界」時的無能。
Fred Brooks 將複雜度分為「本質」與「偶然」。在 Netflix 的案例中，AI 陷入了螺旋式崩潰，原因在於它無法處理代碼庫中的偶然複雜性 (Accidental Complexity)：
- 模式的盲目繼承： 在 AI 眼中，每一行舊代碼都是「必須保留的正確模式」。即便系統中存在「2019 年遺留的、把 gRPC 當成 GraphQL 來用的怪異代碼」，AI 也會忠實地在新架構中模擬這些錯誤。
- 無法辨識「接縫」： 舊系統的授權邏輯、權限假設與業務邏輯早已如亂麻般糾纏。AI 因為缺乏歷史上下文，無法辨識何處該切斷、何處該保留，最終只能在爛攤子上蓋違章建築。
實驗的初步結論令人心驚：AI 並不會自動清理技術債，它只會讓債務以更快的速度繁衍。 真正的突破並非來自更好的提示詞，而是 Netflix 團隊意識到，在讓 AI 介入前，他們必須先手動（by hand）完成一次遷移。
規格制定者三階段工作流
為了對抗認知萎縮，Nations 提出了一套將開發者從「打字員」轉向「規格制定者（Spec Writer）」的三階段工作流。
第一階段：研究
不要讓 AI 直接寫 code。針對 Netflix 高達 100 萬行 Java、約 500 萬個 Token 的龐大代碼庫，第一步是環境壓縮。
- 關鍵動作： 讓 AI 映射依賴，也就是請 AI 先幫你畫出系統裡所有模組之間的依賴關係，再由人類工程師用問題反覆質問AI、把這張圖修正到可用，作為後續寫規格書跟重構的基礎。
- 產出： 將 5M tokens 的混亂狀態，壓縮成 2000 字的精準規格書。這一步是整個專案槓桿最大的一刻，開發者必須在這裡把『系統做到哪、不做到哪』講明白。」
第二階段：實施計畫
這份計畫必須詳細到「按圖索驥（Paint by Numbers）」的程度。
- 細節要求： 定義清楚的函數簽名與數據流。這份計畫應該詳細到讓一個初級工程師或 AI 代理只需「照著填色」即可，嚴禁 AI 在執行階段進行任何「建築式發明」。
第三階段：執行
Nations最關鍵的洞察在於：你必須先賺取理解，才能享有自動化。 Netflix 的重構之所以最終成功，是因為團隊先手動完成了一部分最難的遷移，親身體會了那些隱藏的約束條件。將這些「帶血的經驗」作為種子餵給 AI，AI 才能在既定的規格內精準執行。
結語：在無限代碼時代守住人類的「直覺」
總結Nations的核心觀點，當代碼生成的邊際成本趨近於零，真正昂貴的資源成了「系統直覺」。因此，在萬事問AI的時代，我們必須警惕能力的「萎縮效應」， 要認知到那種能在凌晨三點精確定位系統崩潰的本領，來自於你曾親手處理過架構的脆弱與混亂。
簡單來說，如果你習慣跳過思考、直接生成，你的技術本能將會枯竭。因為模型不會從失敗中汲取教訓，它只會生成你要求的東西。
未來的核心競爭力，不再是寫出代碼的人，而是能在無數代碼中看出「接縫（Seams）」、理解系統運作本質的人。軟體工程終究是人類的事業，工具無法替代「決定要寫什麼」的智慧。
值得各位Vibe Coding 鍵盤專家深思的是： 當 AI 撰寫了我們大部分的程式碼時，我們是否還能理解自己的系統？
延伸閱讀：AI龍蝦遭Anthropic施壓更名為「Moltbot」！Clawdbot是什麼？跟ChatGPT、Gemini有何不同？要收費嗎？
資料來源：AI Engineer
本文初稿為AI編撰，整理．編輯/ 李先泰
