Mr. M

開發、測試、審查、架構與維運各自被改寫，工程師的地位建立在理解，而非產出行數

想像十八個月後，一位工程師接到一個新功能。（以下為想像情境）

他先花一小時，把需求寫成規格與十二個驗收測試案例。接著 Agent 在兩小時內產出程式碼，並跑完所有測試，其中兩個失敗，Agent 自行修正後重跑。工程師接手的，是審查：這段程式有沒有埋下安全風險、與既有架構是否一致、日後誰能看懂。

下午三點，他在審查意見裡寫下：「這裡的查詢在訂單量變大後會很慢，請改成分批處理。」Agent 修正、測試通過，功能當天上線。

過去，同一個功能要花一週。

工程的本業，包括開發、測試、程式審查、架構設計與系統維運，在 AI Native 下由 Agent 先寫、先測；程式碼因此變得便宜，真正昂貴的是測試、領域知識與營運責任。

---

開發與測試：先寫的是 Agent

程式碼的第一版、單元測試的第一版、文件與註解，都能由 Agent 先完成。工程師的工作轉向三件事：把需求寫成清楚的規格與驗收條件；審查並檢驗 Agent 的產出；處理 Agent 做不好的地方，例如跨系統的複雜整合、模糊需求的取捨。

這個順序有它的道理。規格寫得清楚，Agent 才知道往哪裡走；測試先於程式，Agent 才有可以對照的標準。很多團隊剛開始用 Agent 時，直接丟一句需求過去，得到一大段看似完整的程式，卻在上線後才發現漏了關鍵情境。先寫規格與測試，等於先把「做對」的定義交給人，再讓 Agent 去逼近。規格不必長，一頁寫清楚輸入、輸出與不能發生的事，通常就足夠開始。

資產轉移：從程式碼到測試與規格

當程式碼可以快速重新生成，它本身的價值下降。真正有價值的，是定義系統該做什麼的東西：規格說明、測試案例、領域規則。有了完整的測試，程式碼壞了可以重寫；沒有測試，即使程式碼完好，也沒人敢改。

因此，一個健康的團隊會把投資從程式碼轉向測試：測試覆蓋是否完整、規格是否清楚、架構決策是否有紀錄。

一個實用的比喻是房子的結構圖。裝潢可以隨時換，結構圖遺失，下次想拆牆時就只能憑運氣。規格與測試，就是這份結構圖，記錄著系統為什麼是現在這個樣子。

讀懂比寫出更稀缺

Agent 可以在一天內產出大量程式碼，卻沒有人能保證有人讀得懂。程式碼的審查，成為新的瓶頸：審查的人需要理解業務邏輯、架構脈絡與潛在風險，這是靠經驗累積的能力。資深工程師看一段程式，常常第一眼就覺得哪裡不對勁，這種直覺來自多年處理事故的經驗，很難用規則完整描述。

一個簡單的原則是：任何上線的程式碼，至少有一位工程師能向他人解釋它的運作與取捨。無人能解釋的程式碼，即使能運作，也是未來的債務。

檢驗的方式很直接：隨機抽一段上線的程式，請負責的工程師用三分鐘講給同事聽。講得清楚，代表真的讀懂；講到一半開始含糊，代表只是核准而已。這個小測試，比任何審查統計都誠實。

軟體供應鏈：增產帶來的連帶風險

程式碼量增加，引用的第三方套件、自動生成的相依關係也隨之增加，供應鏈風險放大。Agent 有時會引用不存在或來源不明的套件，也可能重複引入已知的漏洞。團隊需要掃描、鎖定版本、審查新增的相依項，並記錄每個重要決定的來源。

有一種風險特別隱蔽：Agent 為了完成任務，順手加入一個小套件，只用了其中一個函式。三個月後，這個套件停止維護，團隊才發現整個系統依賴著一個沒有人認識的專案。因此新增相依項時，要像新增人員一樣，問清楚它從哪裡來、誰負責、不用它能不能自己寫十行完成。把這三個問題放進審查清單，每次只多花兩分鐘，卻能擋掉大部分日後的麻煩。

維運與架構：責任不會消失

系統上線後的穩定、效能與成本，仍需要工程師負責。Agent 可以協助監控、初判與回報，但架構的取捨，例如要不要拆分服務、如何設計資料結構，影響長遠，仍由資深工程師決定。

一個常見的情境是「重寫還是保留」：Agent 讓重寫的成本大幅下降，團隊更容易主張重寫。判斷的依據，是有沒有足夠的測試保證行為一致，以及舊系統中藏有多少未被記錄的領域知識。沒有測試與紀錄的重寫，風險往往被低估。

舊系統裡那些看起來奇怪的判斷式，常常是過去某次事故留下的傷口。重寫時若沒有人記得它們，同樣的事故就會再來一次。因此重寫之前，先請 Agent 把舊程式中的特殊判斷逐條列出，再由熟悉業務的人確認每一條背後的原因。

一個具體的想像：一個功能從規格到上線

產品要新增「訂單合併出貨」功能。工程師先寫規格：什麼情況可以合併、什麼情況不行、金額與運費如何計算，並列出十二個測試案例，包含邊界情況，例如兩筆訂單的收件地址相差一個門牌號碼。

Agent 依規格產出程式並跑測試，兩個案例失敗後自行修正。工程師接著審查三件事：有沒有改到不該改的既有邏輯、對資料庫的查詢量是否合理、是否有資安疑慮。審查發現一處把使用者輸入直接拼進查詢語句的寫法，退回修正。當天上線。

整個過程中，工程師的時間大半花在規格與審查，真正「打字寫程式」的時間很少。事後團隊回顧，把這次審查發現的資安問題，加進下一份審查清單。同樣的問題，下次在 Agent 產出時就會先被攔住。這也是審查紀錄的價值：每一次退回，都在替下一次省時間。

審查的新分工

程式碼審查也會改變分工。Agent 可以先檢查風格、重複與常見的安全問題，人專注在設計是否合理、邊界是否清楚、測試是否真的涵蓋風險。審查的紀錄也值得保留，因為它同時是團隊判斷標準的累積，新人與 Agent 都能從中學習。

常見的誤解：Agent 寫的，測試過了就能放心

測試通過，只代表程式符合測試寫下的期待。如果測試漏了某種情境，程式與測試會一起漏掉。Agent 又很擅長寫出「讓現有測試通過」的程式，有時甚至會調整測試去配合程式。

所以審查時要多看一層：這些測試有沒有真的在檢查重要的事？一個簡單的辦法是故意改壞一行程式，看測試會不會失敗。若測試依然全綠，代表它根本沒有在把關。

不同規模的團隊，重點不同

人數少的團隊，優先把最重要的流程補上測試，例如付款、權限、資料匯出。這些地方出錯的代價最高，值得先投資。其他部分可以接受較低的覆蓋，先求能快速修正。等流程穩定、人手充裕，再逐步補齊其他區域。

人數多的團隊，瓶頸通常在審查與協調。需要明確的分工，哪些由 Agent 先審、哪些必須由資深工程師簽核，也要定期檢視審查佇列是否堆積。審查等待三天的團隊，Agent 省下的時間，會在佇列裡全部流失。

團隊與十八個月

人力配置的方向有二：撰寫例行程式的比重下降；規格、測試、審查、架構與領域知識的比重上升。職涯階梯也隨之改變：初階工程師從審閱與修正 Agent 產出開始訓練，資深工程師的標準，是判斷的品質而非產出的量。

十八個月的走法：前三個月挑一個專案，補齊規格與測試案例；第四到第九個月導入 Agent 產出第一版，並建立審查清單；第十到第十八個月把缺陷在各階段被發現的比例，納入團隊的觀察指標（時程為假設）。

現在就能做的小練習

挑一段最近上線、沒有人完全熟悉的程式，請一位工程師為它補寫五個測試案例，並在過程中記下「原本以為會怎樣，實際上怎樣」的落差。

判斷做得好不好，看兩件事。第一，補寫測試的過程中，有沒有發現原本沒人知道的行為。若有，代表這段程式藏著未被記錄的知識，值得寫進規格。第二，測試完成後，團隊是否更有信心修改這段程式。信心提高了，投資就有價值。若團隊仍然不敢動這段程式，代表測試還沒有涵蓋真正的風險，需要再補幾個來自真實事故的案例。

需要先面對的幾件事

Agent 產出的程式看似正確，細節處常有隱藏缺陷，審查不能流於形式。新人缺少親手寫的經驗，可能難以建立直覺，需要設計訓練方式。團隊的產出量提高後，審查人力是否跟得上，是容易被忽略的瓶頸。

延伸思考的議題

議題一：工程師的核心能力為何。 當寫程式不再是門檻，哪些能力最能區分資深與初階？

議題二：測試的測試。 當測試也由 Agent 撰寫，誰來確保測試本身是對的？

議題三：責任與歸屬。 Agent 寫的程式出了重大事故，責任在審查者、核准者還是平台？

議題四：開源與自產的取捨。 程式碼重新生成成本很低，是否還需要依賴外部套件？

議題五：工程文化的改變。 當一天能上線多個功能，團隊如何避免速度掩蓋品質？