危險地跳過閱讀程式碼：AI Agent 時代下的嚴謹性轉移
危險地跳過閱讀程式碼：AI Agent 時代下的嚴謹性轉移
軟體工程師的傳統角色長期以來一直以維護原始碼為中心。數十年來，程式碼一直是理解軟體系統的主要代理工具；如果你想知道某個功能如何運作或為什麼存在某個 bug，你就會閱讀程式碼。然而，大型語言模型 (LLMs) 和自主代理 (autonomous agents) 的興起正在創造一種生產力悖論：程式碼生成的速度現在比任何人類能實際審查、理解或核准的速度還要快。
這種轉變迫使我們提出一個關鍵問題：如果我們無法再跟上生成程式碼的數量，我們是應該降低標準，還是將我們的嚴謹性轉移到其他地方？
將「機器碼」視為原始碼的論點
有一種具挑釁性的觀點認為，我們應該停止將 LLM 生成的程式碼視為需要人類逐行審查的東西。相反地，我們可以將高階原始碼視為一種「機器碼」——就像現在的開發者很少閱讀編譯器產生的組合語言或位元組碼 (bytecode)，或是交付給瀏覽器的縮減版 (minified) 或轉譯後的 JavaScript 一樣。
在這種模式下，「事實來源」(source of truth) 從實作 (程式碼) 轉移到了規格 (specification)。如果一個組織強制要求極致的速度與 AI agent 的槓桿作用，那麼知識的單位就會變成規格與測試套件。
將嚴謹性轉移至規格
為了在不閱讀每個 diff 的情況下維持工程完整性，重點必須轉移到：
- 標準化規格： 使用 Markdown 或類似格式來定義業務規則、架構方法和使用者體驗細節。這些規格將成為審查與問責的主要產出物。
- 嚴謹的測試案例： 測試不再僅僅是安全網，而是主要的執行機制。如果程式碼通過了測試並符合規格，則予以接受。
- 自動化驗證： 實施 PR 檢查，不僅驗證測試是否通過，還要驗證產出的程式碼是否與提供的規格一致。
組織轉型
這種轉變無法在個人層級發生；它需要組織層級的授權。根據 Amdahl's Law，如果沒有重新調整組織結構，僅靠最大化程式碼生成速度是無法獲得實質生產力增益的。
如果工程師透過 agent 每天產出數千行程式碼，傳統的「基於工單」(ticket-based) 工作流（例如：「為 API 新增一個端點」）就會成為瓶頸。相反地，工程界可能需要轉向：
- 減少人機協作 (Human-in-the-Loop)： 最小化協調、官僚主義和把關行為。
- 工程師作為產品設計師： 將開發者的角色轉向擁有整個工作流，並根據高階層級的需求做出自主決策。
- 接受「免費」重做： 擁抱這樣一個想法：因為生成成本很低，所以錯誤工作的成本也較低，將重點從防止錯誤轉向透過規格與測試來偵測錯誤。
反對意見與風險
雖然極致速度的前景非常誘人，但社群對於這種方法的長期成本仍持懷疑態度。
認知債務陷阱
A primary concern 是「認知債務」的累積。當開發者停止閱讀程式碼時，他們會失去除錯 (debug) 的能力來處理複雜的系統故障。正如一位貢獻者所言：
"What we trade for velocity we will pay for with hours of debugging because we won't understand how things work... after some time of not writing code... I simply don't have the muscle to grok the output."
「規格即程式碼」的悖論
有一種反覆出現的論點認為，一個精確到足以保證 LLM 輸出正確的規格，實際上就是用另一種語言寫成的程式碼。如果規格必須詳盡到足以防止 LLM 做出災難性的架構決策（例如，在未被告知不准做到的情況下，將資料庫進行反正規化 (denormalizing)），那麼編寫規格所花費的精力可能與編寫程式碼的精力相等。
可靠性差距
與具備確定性的編譯器不同，LLMs 是非確定性的。提示詞 (prompt) 的微小變化可能會導致截然不同的實作方式。這這使得與組合語言或位元組碼的類比非常脆弱；如果編譯器有 bug，你會修復編譯器。如果 LLM 有 bug，你通常是在與一個黑盒進行鬥爭。
實務操作實施
儘管存在風險，一些開發者已經在採用「計畫優先」(Plan-First) 工作流來減止這些問題：
- Plan Mode： 強制 agent 建立一個詳細的計畫文件 (spec) 之前寫入任何程式碼。
- Iterative Refinement： 審查並迭代計畫文件，直到它足夠詳盡，將計畫作為 PR 的工作單位，而非程式碼本身。
- RFC 2119 Keywords： 在規格中利用 RFC 2119 關鍵字 (MUST, SHOULD, MAY) 來提供 LLM 更清晰的約束，並提高合規性。
結論
將嚴謹性從實作轉移到規格是高風險、高回報的賭博。它承認了一個未來，即軟體生產的數量將超過人類的認知能力。雖然這可能導致一個充滿未知 bug 的「無法修復」的程式碼世界，但它也提供了一條通往前所未有的開發速度的途徑。現代工程師的挑戰在於，確定「生產力速度」與「危險的疏忽」之間的界線究竟在哪裡。