如果你的 team 還在用「AI 生了幾行 code」當 KPI，那接下來會發生什麼事？
最近看到一篇分析把 software engineering 拆成三層：decide、execute、deliver。作者的核心論點很直接，AI 壓縮了中間那層（execute），但上下兩層幾乎沒動。
GitHub 做的那份大型研究，10 萬開發者，AI 輔助之後寫出的 code 行數成長了 8 倍，但 release 頻率只多了 30%。這個落差不是意外，是結構性的。
我講一下我自己的觀察好了。
AI 真正壓縮的是什麼
我帶後端 team 也有幾年了。說實話，programmer 每天真正在「純寫 code」的時間，沒有外行人想的那麼多。一天八小時，大概有三到四小時是在理解需求、問問題、跟前端或 PM 對齊、debug 一個搞不清楚為什麼會發生的問題、然後 review 別人的 PR。
純粹的 implement 時間，大概佔三分之一不到。
AI 把這三分之一加速了，有時候是幫你補 boilerplate，有時候是直接把一個 CRUD 的 scaffold 給你。速度的確快很多。但剩下那三分之二的工作，AI 基本上沒有進去。
decide 那層：搞清楚這個 feature 要不要做、做到什麼程度、trade-off 是什麼。這需要對 codebase 有記憶、對業務有理解、對過去那些踩過的坑有記憶。AI 沒有這些。它每次對話都從空白開始。
deliver 那層：確認這個東西真的能跑、在 production 的條件下不會炸、rollout 有沒有問題、monitoring 有沒有 cover 到。這層更不可能自動化，因為你的 production 環境不是 AI 看得到的 context。
把 code 行數當指標，會把你帶去哪
這才是我真正想講的部分。
前陣子聽到一個狀況，不是我們 team，是業界朋友那邊。他們引入了 coding agent 之後，管理層很興奮，PR 數字漲了，code 產出量也漲了，開始把「AI 輔助產出的 code 行數」寫進季報。
幾個月後發生了什麼？
Verification debt 開始堆積。 因為 PR 出得快，review 的速度跟不上，reviewer 壓力大，開始傾向快速 approve，很多「看起來沒問題」的 code 過了。這些 code 不是有明顯 bug，而是那種邏輯上有點怪、edge case 沒處理、或者架構決策跟整個 codebase 的設計不一致的東西。
短期看不出來。三到六個月後開始爆。到時候你花在修那些問題的時間，遠超過當初 AI 幫你省下來的時間。
這不是 AI 的問題，是把錯誤的東西當成輸出指標。
code 行數、PR 數量、agent 跑了幾個回合，這些都不是輸出，這些是 activity。輸出是：release 出去的 feature 有沒有在 production 穩定跑、用戶有沒有因此得到價值、技術債有沒有控制住。
verification 為什麼沒辦法省
我做過一個很土的實驗。讓 AI 幫我生一段 database migration script，場景是把一個舊的 column 做 backfill 然後加 index。AI 生出來的 script 在 local 跑沒問題，在 staging 也沒問題，但是那個 index 沒有加 CONCURRENTLY。
在 production 跑這段，整個 table 會 lock。我們是 fintech，24/7 的交易系統，任何 downtime 都是事故。
AI 不知道這個 constraint，因為它不知道你的 production traffic pattern 是什麼、你的 DB 版本是什麼、你過去有沒有在這張表上出過事。我知道，因為我在這個 codebase 待了夠久，我記得上次有人不小心在 production lock 住這張表的事。
這個 verify 的動作，不是「測試有沒有通過」那麼簡單。它需要你帶著對系統的整體理解去看，去問「這個在我們的 production 環境裡，是不是真的沒問題。」
這不是 AI 能替你做的。它能幫你生出 script，但 accountability 還是在你這裡。
那 coding agent 到底應該擺在哪一層
Execute 那層是沒問題的。讓它幫你生 boilerplate、補測試、寫 migration template，很合理。甚至做一些有明確規格的 feature，指定好 input/output，AI 去 implement，你再仔細看過，這個 flow 也說得通。
但如果你把它定位成「我只要給它一個模糊的需求，它會負責 decide 怎麼做、怎麼 ve
rify、然後 deliver」，那你會得到一個速度快、品質不穩定、問題延遲爆發的系統。
安慰工程師說「你的工作不會消失」不是我想做的事。重新定義 coding agent 的正確位置才是重點：它是 execute 層的工具，不是 decide 和 verify 層的替代品。這個邊界搞清楚，才知道怎麼管這個工具、怎麼量工程師真正的產出。
code 出得快不等於工程做得好。這個道理在沒有 AI 的時候就成立，現在更重要。
作者：鍵盤工人