背景與問題
AI coding agent（AI 程式碼代理工具，指能根據指令自動產生、修改程式碼的智慧助理）在軟體開發流程中快速普及，程式碼產出速度大幅提升，但瓶頸也隨之轉移。科技媒體 InfoQ 報導了一項由獨立研究機構 Coleman Parkes 受 Undo 公司委託進行的調查，結果顯示開發速度加快之後，真正的挑戰移到了除錯、程式碼理解與維護上。Undo 本身是一家專注於以 AI 技術擴大根本原因分析（root-cause analysis，即追溯系統故障真正成因的技術方法）規模的公司。這項調查訪問了 300 名負責交付關鍵任務軟體（mission-critical software，指故障會造成嚴重後果、可靠性要求極高的系統）的資深工程主管，多數受訪者的開發環境以 C/C++ 為主。
調查特別聚焦於「程式碼必須被理解」的環境。受訪者認為最吃力的任務，是弄清楚程式碼實際做了什麼、會如何影響既有程式碼庫，以及在應用程式行為不如預期時進行除錯。數據直接反映了這個現象：團隊平均每週只花 9.8 小時撰寫程式碼，卻要花 16.9 小時處理開發過程中發現、或客戶在生產環境中回報的問題，除錯相關工作佔平均每週工時的 42%，幾乎是寫程式時間的兩倍。
核心發現：理解缺口
除錯比重上升之外，調查指出另一個正在浮現的挑戰是程式碼理解（code comprehension）。過去工程師親手撰寫程式碼時，會自然建立對系統行為與設計脈絡的理解；如今大部分程式碼由 AI 產生，這種內建的理解不復存在。結果是缺陷更容易在開發階段逃逸，而一旦問題終究發生，團隊裡往往沒有人具備足夠的知識，能把故障一路追溯回根本原因。
量化數據顯示，35% 由 AI 生成的程式碼，在團隊尚未完全理解之前就進入了生產環境。同時，80% 的受訪者表示 coding agent 在複雜程式碼庫中難以解決困難問題。這也是為什麼約三分之一的團隊只在結構單純的程式碼庫中，使用 AI agent 協助理解與除錯；面對複雜系統時，仍需要搭配其他技術手段，才能建立足夠的信心。
生產環境的實際代價
理解缺口並非抽象風險，調查呈現了它在生產環境中的具體代價。81% 的團隊在過去六個月內至少經歷過一次影響內部使用者或客戶的生產事故或服務中斷，其中 14% 每月發生多次。93% 的團隊曾因 AI 幻覺（hallucination，指模型產生看似合理但實際錯誤的輸出）而做出錯誤的根因判斷或問題診斷，18% 每月遭遇多次。另有 91% 的團隊曾發生測試逃逸（test escape，指缺陷未被測試環節攔截而流入生產）、嚴重缺陷或最佳化不良的程式碼進入生產環境，8% 的團隊每月多次發生這類問題。
整體而言，79% 的工程主管承認 AI agent 確實能大幅加快程式碼產出，但隨之而來的工作重心轉移——花更多時間除錯與「拆解」AI 生成的程式碼——使整體發布週期並沒有比以前更快。Undo 創辦人暨執行長 Greg Law 總結調查結果時指出，工程師面對「幾乎正確、但又不完全對」的程式碼，往往得耗費數天釐清究竟哪裡出錯以及原因為何；agent 擅長快速寫出大量程式碼，但在除錯上的能力明顯較弱。
脈絡、影響與限制
這份調查呼應了軟體工程社群自 AI coding agent 普及以來的持續辯論。一個反覆出現的擔憂是：當 agent 產出程式碼的速度超過人類審查的能力，該如何控管品質。為此業界發展出幾種常見做法，例如 test-first red-green loop（先寫測試、確認測試失敗、再實作讓測試通過的循環式開發方法）與 automated fallback（自動回退機制，在 agent 產出異常時自動還原或切換備案）。不過較廣泛的共識是，AI agent 並未改變軟體工程的本質——這門學問從來不只是寫程式，而是理解限制條件、做出取捨，並確保最終系統的行為符合預期。
解讀這份調查時需要注意幾點限制。第一，調查由 Undo 委託進行，而該公司的核心業務正是 AI 根因分析，調查結論的方向與其商業利益一致，結果可能偏向放大除錯與理解問題的嚴重性。第二，樣本集中於以 C/C++ 開發關鍵任務系統的資深主管，這類環境對正確性的要求遠高於一般應用，調查結果未必能直接推論到 Web 開發或腳本語言為主的團隊。第三，數據來自受訪者自述與回憶，反映的是主觀感受而非客觀量測。即便如此，調查仍點出一個具體且值得正視的問題：當程式碼產出速度不再受限于人力，理解與驗證的能力反而成為新的稀缺資源，團隊在導入 AI agent 時若只看重生成速度，很可能只是把成本從寫程式轉嫁到除錯與事故處理上。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。