用 Agent 寫程式一段時間後，功能做不做得出來，已經很少是最花時間的問題。比較常發生的是程式改得很快，對系統的理解卻沒有一起更新。畫面能動、測試也可能會過，但過幾天要再改功能時，才發現自己不確定原本為什麼這樣設計，也不知道一次修改會影響哪些地方。
近年的軟體工程討論通常把這種理解落差稱為「認知債」（cognitive debt）。Margaret-Anne Storey 在〈From Technical Debt to Cognitive and Intent Debt〉中，將它說明為團隊對系統的共同理解逐漸流失。這篇文章沿用這個概念，但我比較想談的是實際使用 Agent 之後，人需要理解到什麼程度、這些理解怎麼留下來，以及什麼時候不能再把做出來的東西當成一次性的原型。
人需要理解什麼，以及怎麼留下來
談到認知債，很容易讓人以為使用 Agent 之後，還是得把它產生的程式碼逐行讀完。實際上沒有人能同時理解一套系統的所有細節。寫程式很像在整理一張很大的流程圖。一開始先看到前端、後端與資料庫，需要處理後端問題時，再往下看 API、服務邏輯和資料存取。人的注意力有限，一次只能在一個範圍內思考，所以開發過程本來就會在抽象與具體之間來回移動。
因此，不需要等到所有細節都懂了才開始做。用了 Agent 以後，人會比較常停留在上層，處理架構、模組分工和工作順序；真的出現問題時，再往下檢查相關的實作。不過有些事情還是要留在人的理解範圍內：
- 系統要解決什麼問題，又是怎麼啟動與運作的。
- 主要模組各自負責什麼，資料會依照什麼順序流動。
- 哪些地方的風險比較高；發生異常時，要先看哪些 log、測試結果或外部現象。
Peter Naur 在〈Programming as Theory Building〉（1985）談過類似的問題。軟體開發有些知識很難從原始碼本身還原，例如現實世界和程式之間如何對應、當時為什麼選擇某個設計，以及原本的設計要怎麼適應後來的新需求。這些知識主要存在參與開發的人腦中，這也是我以前在〈原始碼的價值〉想討論的事情。
既然每個人的注意力有限，Agent 一次能取得的 context 也有限，就需要把重要的理解留下來。不同的資訊適合留在不同地方：
- 用架構圖、資料流和任務拆解，記錄現實問題如何對應到程式。
- 用決策紀錄、Git commit 與 diff，說明修改發生的背景。
- 用規格、驗收條件、測試與 log，記錄系統預期怎麼運作，並拿實際結果進行比較。
這些做法並不是 Agent 出現後才發明的。軟體工程原本就在處理多人協作、需求變動、系統維護與風險控制，只是以前主要用來協調人與人，現在也成為人和 Agent 交換脈絡、確認結果的方式。
很多計算機科學問題有相對明確的答案，例如演算法、資料結構、通訊協定和作業系統的基本原理，AI 很適合協助產生實作，再用測試確認。軟體工程面對的情況比較不一樣。專案擁有的資源、使用環境、團隊習慣與維護時間都會影響選擇，所以不會只靠一個標準答案解決。以軟體工程的角度，Andrew Ng 建議學習全端程式設計、資料管理、系統架構、可靠性與安全性，以及生產環境的擴展與維運。這些領域共同需要的能力，是根據實際情況做選擇，並且知道要用什麼證據確認結果。
Agent 接手更多實作工作後，人花在規劃與決策上的時間會增加。我的使用經驗也比較接近管理一個小團隊：要先說明方向、補充背景、查看進度，發現理解有落差時再修正。專案能不能繼續往前，最後常常取決於人能不能把需求想清楚、做出決定，並且把這些決定傳達給下一個執行者。
探索需求與長期維護是兩種不同的工作
這不表示每個專案從第一天開始都要把完整的軟體工程流程搬進來。有些需求還很模糊，本來就很難事先規劃。這時候用 vibe coding 快速做出幾個版本，拿在手上試一試，通常比一直坐著討論更容易知道真正需要什麼。這些原型的目的本來就是幫助探索需求，之後丟掉也沒有關係。以前的軟體開發也會製作 prototype，只是現在 Agent 讓這個過程快了很多。
等到需求比較清楚，做出來的東西準備長期使用，就要換一種做法。可以把原型中確認過的需求整理成規格，重新安排架構與工作順序，再讓 Agent 分段執行，並用測試和驗收結果檢查。這不一定代表所有程式都要重寫，但不能只因為原型目前能動，就直接把它當成可以長期維護的系統。
實際上可以從幾個情況判斷是不是該切換：
- 程式已經變得臃腫，同一個功能改了好幾次，繼續修改很容易破壞其他地方。
- 使用時間從幾天延長到幾個月甚至更久，開始需要考慮穩定性與後續維護。
- 除了自己以外，已經有其他人開始使用或依賴這個系統。
到了這個階段，出問題後不能只說是模型產生的，還是要有人負責修正、說明影響，並避免同樣的問題再次發生。
使用 Agent 學習開發時，還是需要保留一些自己思考與動手確認的過程。只把範例交給 Agent 執行，雖然可以得到結果，但自己不一定會形成對問題的理解。比較好的做法是先提出假設，再用執行結果確認。測試可以幫助我們把預期行為和邊界寫清楚；重構則是帶著一個具體目的，再比較目前的做法有什麼成本，是否有更合適的設計。《Beyond Vibe Coding》談到維護 AI 產生的程式碼時，也把持續測試與重構放在很重要的位置。
Agent 已經可以負責很多原本需要手動完成的工作，但需求怎麼定義、系統要做到什麼程度、哪些風險可以接受，仍然要由人判斷。使用 Agent 加快開發的同時，也需要知道怎麼檢查結果；當原型準備長期使用或開始被其他人依賴，就應該補上規格、測試、版本紀錄與後續觀測，讓系統可以繼續維護。
參考資料：
- Peter Naur, “Programming as Theory Building,” Microprocessing and Microprogramming, Vol. 15, No. 5 (1985), pp. 253–261.
- Margaret-Anne Storey, “From Technical Debt to Cognitive and Intent Debt” (2026)
- 《Beyond Vibe Coding》(O’Reilly)
- Andrew Ng：AI Engineering Skills Map
- 原始碼的價值