工程管理在程式碼成本崩塌後
程式碼成本崩塌後的工程管理
從生產到驗證的轉變
生產看似可行程式碼的成本已經崩塌，從根本上打破了許多傳統工程管理實踐所基礎的假設。雖然生成「管道」—腳手架、樣板碼和初始草稿—的速度已加速，但軟體交付的瓶頸已從編寫程式碼的行為轉移到驗證其正確性並承擔其部署風險的行為。
生產成本的崩塌
生產看似可行的程式碼現在變得便宜且豐富。然而，這並不意味著工程組織會自動變得更快。收益在綠地工作和樣板碼中最為明顯，但在處理複雜現有系統的深度工作時，常常會消失或倒轉。
由於生產成本已下降，傳統指標如速度、拉取請求數量和已關閉的工單變得積極具有誤導性。當提升這些指標最便宜的方式是產生更多數量，而數量不再稀缺時，這些代理指標不再與業務價值相關聯。持久的管理做法是衡量業務成果和系統健康，將程式碼數量視為需要證明的成本，而非值得讚美的產出。
重新定義正確性與驗證
驗證現在分為兩個不同的類別：機械性和語義性。
機械驗證
機械驗證—檢查類型、測試、契約和 lint 規則—正在變得更快，因為 AI 代理可以以人類無法匹配的速度運行測試循環並修復差異。這種效率僅在人類已經以機器可檢查的格式定義了什麼是「正確」時才有可能。因此，投資於機器可檢查的正確性（強規格和不變式）現在是組織可以進行的最高槓桿基礎設施投資之一。
語義驗證
語義驗證—確保程式碼實際執行業務政策並管理監管風險—仍然是以人為中心的任務。AI 檢查工具常與 AI 生成工具共享相同的訓練資料和盲點，意味著它們可能以相同的方式失敗。
這導致了一個關鍵的悖論：雖然單次檢查變得更便宜，但因為便宜的生成邀請了更多數量，總驗證工作量反而增加。結果是事件特徵的轉移：組織可能會看到更少的「低級」錯誤，但更多的系統性失敗，因為高數量的看似可行輸出通過了高數量的看似可行審查。
更新管理的「舊規則」
許多長期存在的管理公理基於已不再成立的假設。為保持效果，這些規則必須重新校準：
- "董事不應該編寫程式碼"：這不再是關於交付功能，而是關於校準。董事需要足夠直接接觸 AI 工具，以區分一個真正更快的團隊和一個僅僅在大量產出「slop」（自信但錯誤的輸出）的團隊。
- "保護團隊免受業務影響"：雖然保護工程師免受昂貴的上下文切換仍然有效，但讓他們缺乏業務背景現在很危險。在缺乏業務背景的情況下提示 AI 的工程師會大規模產出流暢但錯誤的工作。管理應該從預設過濾上下文轉變為有意識地選擇特定上下文。
- "我們在提交前需要共識"：共識適用於不可逆的決策。由於可逆的技術選擇現在撤銷成本更低，應該由最小的可能群體來做出，以保持速度。
- "我們需要更多人頭"：現在必須根據工作是否需要人類判斷或僅僅是生產來審查人頭請求。協調成本和入門拖延無論語法成本如何都保持不變。
初級工程師管線危機
目前尚無證實的方法可以在 AI 輔助環境中培訓初級工程師。歷史上，高層判斷是透過執行 AI 現在吸收的任務來發展的：修復小錯誤和編寫樣板碼。如果編寫的實踐被移除，培養高級工程師的管線可能會中斷，其影響可能只會在三到五年後才顯現。
管理角色的未來
管理正在分為兩個功能：資訊路由和判斷。
- 資訊路由：彙總狀態並將更新翻譯成儀表板。此功能正被 LLM 商品化，其價值趨向於零。
- 判斷與擁有：雇用、晉升並承擔錯誤決策的後果。此功能無法自動化，因為它需要一個模型來描述組織的未寫信任關係和制度史。
在「代理極限」下，組織圖將停止記錄誰生產，開始記錄誰簽署。人頭將不再衡量容量，而是衡量組織能夠承擔多少責任和風險。
社區觀點與反論
儘管程式碼成本崩塌是主導敘事，但從從業者討論中浮現出幾個關鍵的反論：
"假設是 LLMs 應該編寫程式碼而人類工程師進行審查……我根本不同意這種觀點……理解程式碼仍然是瓶頸。但理解真正是在編寫循環中獲得的。"
一些人認為，AI 最有效的部署方式是讓人類編寫而 LLMs 進行審查，從而保留深度系統理解所需的認知循環。另一些人指出，「程式碼成本」可能實際上正以技術債的形式增加，因為 AI 允許程式碼債的積累速度快於其清理速度。此外，一些人認為，軟體組織的主要瓶頸從來不是編寫程式碼的行為，而是團隊組織、系統設計和工作優先順序。
SUMMARY: 隨著 LLMs 大幅降低產出程式碼的成本，工程管理必須將焦點從追蹤產出量轉移到確保規格品質與人類責任。
TITLE: 工程管理在程式碼成本崩塌後