AI 與工程紀律的回歸

軟體生產的經濟學已發生根本性的轉變：生成程式碼現在實際上是免費且即時的。這種轉變意味著程式碼行數不再是需要精心策劃的珍貴資產，而是可以在一夜之間重新生成的拋棄式產物。因此，軟體工程的主要挑戰正從編寫程式碼的行為，轉向驗證生產環境中系統的紀律。

程式碼作為拋棄式快取

在計算機歷史的大部分時間裡，生產程式碼所需的勞動力是主要的瓶頸。因為重寫成本高昂且重新驗證具有風險，程式碼成為了開發者意圖、使用者期望和歷史錯誤修復的唯一儲存庫。這創造了一種將程式碼視為持久資產的模型。

隨著 Opus 4.5 等高能力模型以及 2025 年代理人框架（agentic harnesses）的興起，AI 現在可以針對常見模式生成品質相當於中等軟體工程師的程式碼。這將程式碼的角色從永久記錄轉變為「理解的實體化視圖」——一個在當前有用但過時後即可拋棄的快取。

當重新生成成本很低時，原地修改程式碼反而成為了一種負擔。就像從手工打造的伺服器轉向不可變基礎設施（immutable infrastructure）一樣，變動應用程式程式碼會累積熵值。只要工程團隊理解系統所需的行為，完全替換程式碼就能重置該熵值。

刪除測試與評估問題

「刪除測試」揭示了大多數工程師將程式碼視為系統本身。當工程師聲稱他們無法丟棄程式碼時，他們通常是在描述評估問題，而非程式碼問題。具體來說，他們缺乏以下知識：

• 確切需要什麼樣的行為。
• 哪些失敗是不可接受的。
• 哪些不變量（invariants）必須始終成立。
• 如何判斷新版本是否正確。
• 哪些錯誤修復是為了應對被遺忘的邊緣案例而進行的刻意修復。

這些理解上的差距無法透過閱讀程式碼來解決，而是要透過建立嚴謹的評估框架來解決。只有當程式碼是系統知識唯一存放處時，程式碼才會變得珍貴。

將嚴謹性移至生產環境

由於人類大腦並不擅長處理重複性、吹毛求疵的驗證工作，人類是品質閘道中最薄弱的一環。因此，必要的嚴謹性必須從程式碼審查流程轉移到生產環境。

生產環境並非開發後的最後階段；它本身就是開發的一個階段。為了在非確定性、AI 生成的程式碼時代維持穩定性，團隊必須採用來自維運與 QA 的技術，將系統「正在做什麼」而非「應該做什麼」進行編碼。關鍵紀律包括：

• 行為與特性測試（Behavioral and Characterization Tests）： 編碼現有系統行為以確保替換後的系統保持一致性。
• 擷取/重放與流量分割器（Capture/Replay and Traffic Splitters）： 使用真實世界的數據來驗證新的實作。
• 可觀測性（Observability）： 使用追蹤（traces）和生產環境評估來確保系統即時滿足需求。

工程紀律的回歸

雖然 2025 年可能是「氛圍編碼（vibe coding）」的一年，但 2026 年代表著工程紀律的回歸。AI 生成程式碼的能力並不會消除對技術人員的需求；相反，它消除了手動 API 重寫和「扼殺無花果樹（strangler fig）」遷移的乏味任務。

軟體的價值是由持久性和確定性支撐的，而非生成速度。使用者需要一致的介面和可靠的金融交易。要實現這種持久性，需要透過短促、快速的反饋迴圈和嚴謹的生產環境驗證，將目前受困於人類大腦中的知識編碼進系統本身。AI 工具讓這種程度的紀律變得更容易實現，但紀律本身仍然是人類工程的要求。