AI SYNTHESIS / MAY CONTAIN ERRORS
生成式 AI 最先壓低的是把意圖轉成程式碼草稿的成本。它沒有替團隊回答需求是否一致、例外是否完整、架構能否承受變更、測試 oracle 是否可信，以及故障後由誰回復。這些才是軟體工程與單純寫程式的分界。
實證結果也不支持單一加速敘事。固定的 JavaScript HTTP server 實驗出現 55.8% 加速；三家企業共 4,867 名開發者的實驗顯示完成任務數增加 26.08%；METR 在成熟開源程式庫的真實任務卻測到 19% 變慢。2026 年更新又因選擇偏差與多 Agent 計時問題，無法可靠估計現在的幅度。
合理結論不是 AI 無效，而是效益取決於任務可驗證性、既有上下文、品質門檻與工作流。當輸出速度上升，古典軟體工程不會退場；它變成限制 Agent 權限、判定結果與承擔事故的控制面。
同樣是 AI 寫程式，研究量到的其實是不同工作
FIGURE 01 / MATRIX同樣是 AI 寫程式，研究量到的其實是不同工作| 項目 | 研究場景 | 觀察結果 | 主要外推限制 |
|---|
| 固定 HTTP server | 窄任務、同一規格、自動測試 | 平均快 55.8% | 上下文與長期維護成本很低 |
|---|
| 三家企業日常工作 | 4,867 名開發者、程式補全助手 | 完成任務數增 26.08% | 各實驗噪音高，輸出量不等於完整價值 |
|---|
| 成熟開源程式庫 | 16 名資深貢獻者、246 項真實任務 | 平均多花 19% 時間 | 工具與模型屬早期 2025 水準 |
|---|
| 2026 後續研究 | Agent 普及後的真實任務 | 可能改善但估計不可靠 | 參與者、任務選擇與平行工作造成偏差 |
|---|
把古典軟體工程理解成厚規格、階段簽核與半年一次上線，是把流程形式誤認為工程原則。SWEBOK V4.0 已把 Agile 與 DevOps 納入知識體系，同時保留需求、架構、測試、組態、維運、品質與安全，因為快速迭代仍需要有人對這些面向負責。
《Software Engineering at Google》用時間、規模與取捨區分程式設計和軟體工程。今天能跑的程式，不代表半年後可修改、十個團隊可協作，或事故發生時能定位。AI 擅長的是局部候選解；工程要處理的是候選解進入長壽系統後的後果。
因此應保留的不是瀑布，而是六個古典問題：要解什麼、哪裡可以變、介面承諾什麼、如何證明正確、如何追蹤版本、如何在正式環境回復。
六個古典範式，在 Agent 工作流中的新位置
FIGURE 02 / MATRIX六個古典範式，在 Agent 工作流中的新位置| 項目 | Agent 時代的控制物 | 缺少時的典型失敗 |
|---|
| 需求工程 | 可驗收任務契約 | 完成了錯的功能 |
|---|
| 模組化 | 上下文與修改權限邊界 | 小需求擴散成大範圍 diff |
|---|
| 介面契約 | 型別、schema、不變量 | 程式可跑但上下游語意錯位 |
|---|
| 驗證與確認 | 獨立 oracle、負向測試、人工審查 | 模型替自己的答案背書 |
|---|
| 組態管理 | 小提交、可重現環境、版本鎖定 | 無法重建產出與依賴 |
|---|
| 維運工程 | 觀測、漸進發布、回滾 | 錯誤直接放大到正式流量 |
|---|
Prompt 可以描述意圖，不能單獨充當規格。Agent 最容易在未寫明的地方自行補完：擴大修改範圍、選擇方便但錯誤的資料來源、忽略效能與安全條件，最後以測試通過宣告完成。
可執行的任務契約至少要分開寫目標、允許修改、禁止修改、功能驗收、非功能條件、測試資料、停止條件與回滾。這不是增加文書，而是把 Brooks 所說的規格工作移到產碼之前，避免模型用流暢文字掩蓋未決議事項。
高風險或跨模組問題還要加入「先回報、不得自行決定」的分支。Agent 能推進已定義的工作，不應替產品、架構、安全或法遵角色做隱性決策。
Parnas 的核心不是把檔案切小，而是讓每個模組隱藏一項可能改變的設計決策。這個準則在 Agent 時代多了直接的操作價值：決策邊界同時可以成為上下文邊界、檔案權限與 code owner 邊界。
依處理流程切模組，常讓一個政策或格式變更穿越多層；依易變決策切分，則能把供應商 API、資料格式、計價規則或輸出編碼封裝在單一介面後。Agent 只需知道公開契約，不必讀完整實作，也不應跨越邊界順手重構。
多 Agent 平行工作更需要這種隔離。每個任務使用獨立分支或 worktree、明確檔案範圍與小型整合點；語意衝突仍由整合者判斷，不能把 Git 無衝突誤認為系統無衝突。
模組切法決定 Agent 需要知道多少、能破壞多少
FIGURE 03 / MATRIX模組切法決定 Agent 需要知道多少、能破壞多少| 項目 | Agent 所需上下文 | 變更影響 |
|---|
| 依執行流程切分 | 常需跨多層理解完整流程 | 同一規則散落於多個步驟 |
|---|
| 依易變決策切分 | 讀介面與單一決策模組即可 | 替換實作時多數呼叫端不變 |
|---|
| 依 Agent 任務臨時切分 | 邊界跟著提示詞漂移 | 容易產生重疊修改與隱性耦合 |
|---|
LLM 產生的程式碼常在局部語法上合理，卻可能誤解狀態、單位、空值、順序或錯誤語意。介面契約把這些條件從自然語言偏好提升為機器可拒絕的約束。
API schema、型別、precondition、postcondition、database constraint 與 domain invariant 都是古典規格技術的可執行版本。它們不保證需求正確，但能阻止一部分錯誤跨越邊界，並讓 Agent 在生成後立即取得明確失敗訊號。
契約也應限制工具行為，例如禁止修改 migration、限制網路存取、鎖定依賴版本與要求輸出 diff。對 Agent 而言，權限最小化和型別檢查屬於同一件事：把可接受行為縮到可驗證範圍。
當同一個 Agent 同時解讀需求、寫實作、補測試並宣告通過，四個步驟會共享同一個誤解。測試數量增加不等於驗證獨立；真正的 oracle 必須來自需求、既有行為、協定、對照實作或人工核定規則。
可優先加入負向案例、邊界值、property-based test、metamorphic test、差異測試與 mutation testing，因為它們會主動尋找模型沒有想到的失敗。coverage 只回答哪些路徑執行過，仍要放在單次 changeset 與 code review 中判讀哪些未覆蓋行為有風險。
審查也要從逐行挑語法錯誤，轉向檢查任務契約、架構邊界、資料流、失敗模式與測試 oracle。Microsoft 的日誌研究顯示工具被認為更實用，可信度卻沒有自然上升；這正是保留獨立審查的理由。
DORA 2025 的訊號很直接：AI 可能提高吞吐量與產品表現，也可能放大交付不穩定。頻繁提交、回滾、小批次、強自動測試與快速回饋，不是 AI 之前的舊習慣，而是吸收新增變更量的安全閥。
實務上應限制單次 diff、要求任務對應 commit、保存提示與工具版本、鎖定依賴，並讓 CI 產生可追溯證據。正式發布採 feature flag、canary、監控與回滾演練；Agent 可執行程序，但不可自行放寬錯誤率、效能或資料完整性門檻。
衡量成效也要從接受率、程式碼行數轉向端到端週期、review 返工、缺陷逸出、變更失敗率與恢復時間。AI 若只讓 pull request 變多，卻把瓶頸推給審查與維運，組織沒有得到真正的工程增益。
工程師不必和模型比打字，而要負責問題定義、取捨、邊界、oracle 與事故責任。AI 可以提出候選實作；合併與上線必須由一條能被反證的證據鏈決定。
可直接採用的判斷規則是：每一個 AI 產生的 diff，都必須附帶至少一項能證明它錯誤的獨立機制，例如 schema 拒絕、負向測試、對照輸出、review checklist、監控告警或回滾門檻。找不到反證方式，代表需求或設計仍不夠清楚。
古典軟體工程真正回歸的原因，不是人類重新手寫所有程式，而是生成成本下降後，規格、模組、契約、驗證、版本與維運成為系統中最稀缺的判斷能力。
AI 變更進入正式環境前的六道門
FIGURE 04 / FLOW模組邊界限制上下文、檔案權限與 blast radius
小批次整合可追溯 commit、CI、有限 diff
