低廉程式碼的隱形成本：從外包到 AI 的教訓"}],

開發程式碼的成本已經崩塌。隨著 LLM 和 coding agents 的興起，現在能以五年前無法想像的速度和成本，生成功能性、足夠且平均水準的程式碼。然而，正如歷史所言，當生產成本下降時，成本並不會消失——它只是遷移了。

這種現象並不新鮮。業界許多人還記得 2000 年代初期的外包浪潮，當時的目標是透過將生產轉移到勞動力成本較低的地區來降低開發成本。雖然經濟效益是合理的，但長期的結果往往是失去組織知識和架構意圖。

我們現在正隨著 AI 生成的程式碼面臨類似的轉折點。

成本的遷移：從生產到維護

當程式碼撰寫成本昂貴時，開發者被迫要有意圖性。每一行程式碼都是基於限制、未來擴展性和系統架構所做出的計算決策。當程式碼變得「廉價」時，對於「為什麼」選擇特定實作的批判性思考動機就會減少。

AI 工具可以產出通過測試並直接交付的程式碼，但它們往往無法捕捉程式碼背後的「意圖」。這造成了一個危險的缺口：我們擁有功能性的軟體，但我們不再理解其存在的理由。這與許多公司在外包時代掉入的同一個陷阱——他們收到了要求的交付物，但失去了讓系統能夠在數十年內演進和維護的「為什麼」。

AI 驅動開發的主要風險之一是文件與推理過程的侵蝕。與人類開發者不同，AI 不會自然地維護一個關於專案長期架構目標的心智模型。

社群討論強調了幾個關鍵疑慮：

文件缺口： 對於文件的需求日益增長，這些文件不僅要能被人讀懂，還要能被「agent-ingestible」（代理人可攝取），讓 AI 理解它正在修改的系統限制。
「黑盒」效應： AI 生成的程式碼通常缺乏人類開發者可能會提供的註解或原理。雖然有人建議提示 AI 在程式碼中包含其推理過程，但根本問題在於 AI 是在預測下一個 token，而不是在設計系統。
盲目信任的風險： 一些開發者承認依賴 AI 來閱讀並向他們解釋程式碼，這實際上將人類從理解的環節中移除了。正如一位使用者所說：「我不再閱讀程式碼……我要求 LLM 閱讀程式碼並告訴我它在做什麼。」

為了避免重蹈覆轍，團隊必須找到方法將有意圖性重新引入 AI 輔助的工作流中。開發者社群中出現了幾種實用的方法：

與其依賴程式碼本身來敘述故事，一些團隊正在實施專用的決策日誌。其中一種方法是維護一個 decisions.md 檔案，每當 agent 要求人類針對產品或架構選擇做出決定時，就更新該檔案。這捕捉了那些在生成的 diffs 中會遺失的意圖。

為了防止對程式碼庫的掌控力喪失，一些開發者主張實施嚴格的審查流程。這包括即時閱讀 AI 所做的每一項變更，並針對任何模糊的邏輯要求立即解釋。這確保了開發者仍然是架構師，而 AI 僅僅是工具。

有一種強而有力的論點認為，AI 生成的程式碼標準不應低於人類撰寫的程式碼。如果一段程式碼無法被理解或維護，它就不應該被合併，無論是誰——或什麼——寫的。對最終產品的控制權至關重要。

整合 coding agents 會將開發者的認知負荷從「記憶受限」（了解語法和 API）轉向「計算受限」（對系統進行推理並驗證輸出）。雖然效率的提升是不可否認的，但危險在於將程式碼視為一種商品，而非架構意圖的體現。

如果我們將 AI 生成的程式碼視為一次性資產，我們就有可能建立一個在今天運作但明天無法被理解或修改的軟體未來。目標並非停止使用 AI，，但要確保生產成本與理解成本保持同步。