GitLab 調查 1,500 名開發者：這對你的程式碼庫至關重要的原因
過去兩年來，關於 AI 輔助軟體開發的討論一直以「速度」為主導。一項針對 1,500 多名開發者和技術主管的全新 GitLab 調查發現，有 60% 的人表示 AI 寫程式的投資報酬率（ROI）已經超出預期，且 78% 的人指出，自從採用 AI 工具後，他們的團隊編寫和提交（commit）程式碼的速度變得更快了。
但沒有控制的速度是一種負債。
大多數企業組織都是藉由在現有基礎設施上增加 AI 程式編寫工具，來追求代理型工程（agentic engineering）。程式編寫代理（coding agent）確實帶來了速度，但這種速度並未體現在整個軟體生命週期中：僅有 21% 的受訪者表示在程式碼生成之外也獲得了生產力提升。
「沒有控制的速度是一種負債。」
基礎設施的問題影響更深。Git 後端、工具鏈和治理框架最初是為了「人類規模」的並行處理（concurrency）而設計的。然而，代理（agent）是以「機器規模」運作，這種落差很快就會顯現出來。當數百萬個代理工作階段（session）同時存取同一個後端時，平台穩定性就會崩潰；隨著代理大規模接觸依賴關係（dependency），資安風險也隨之擴大；此外，由於代理在非為其設計的基礎設施上低效地消耗 Token，導致成本超支不斷增加。
代理型應用普及速度超越治理
AI 程式編寫工具的採用曲線超越了所需防護欄（guardrails）的發展速度，80% 的組織表示他們採用 AI 工具的速度快於制定治理政策的速度，82% 的組織指出，AI 生成的程式碼有造成新形式技術債的風險，而他們的組織尚未做好管理這種風險的準備。
在實務上，這意味著在代理的負載下會面臨平台穩定性的挑戰，代理大量接觸依賴關係會擴大安全與合規風險，且代理因為缺乏完整的上下文（context）而帶著虛假的自信運作。只有 28% 的組織表示其軟體開發生命週期工具已與共享數據和工作流程完全整合，這意味著大多數團隊正試圖在一個從未為其設計的工具鏈中，去治理代理的行為。
代理型工程需要代理型基礎設施
代理型工程需要兩樣東西：代理型程式編寫與代理型基礎設施。大多數組織擁有前者，但缺乏後者。
代理型基礎設施涵蓋四個領域：執行層、上下文層、治理層和編排（orchestration）層，它們共同協作。
第一是機器規模的執行。Git 後端、CI/CD 管線（pipeline）和部署系統是為人類步調的開發而設計的。在代理時代，它們需要處理數百萬個代理工作階段而不崩潰。當生產環境發生事件時，從症狀追溯到源頭的路徑應該只需幾分鐘，而不是幾天。
第二是與程式碼隨行的上下文。正如賓士（Mercedes-Benz）車輛軟體開發平台業務負責人 Bastian Stahmer 最近在一個座談會上所說：「代理的能力完全取決於餵給它的上下文與語義。」連結程式碼、工作項目、管線、安全發現和生產訊號的上下文圖譜（context graph），是讓代理在規模化運作下真正發揮作用，並抑制虛假自信的關鍵。
「代理的能力完全取決於餵給它的上下文與語義。」
第三是融入流程的治理。代理的行為需要與身份綁定、根據政策進行記錄，並可向審查人員進行證明。低風險的變更可以快速通過，而高風險的變更則會觸發審查。對於在需要完整追溯性與人類問責制的汽車監管標準下運作的賓士而言，GitLab 就是其實現問責的控制面（control plane）。
第四是編排。執行、上下文和治理的成效，完全取決於協調它們的系統。編排層根據團隊定義的政策，協調整個軟體生命週期中的代理行為，決定哪些代理運作、運作順序，以及如何管理失敗與交接。沒有了編排層，代理型基礎設施就只是一堆獨立的功能，而非一個運作中的系統。
下一步
根據 85% 的受訪者，軟體領域中 AI 的下一階段將不再側重於「生成程式碼」，而是側重於「治理程式碼」。這一轉變反映出企業對 AI 的思考已逐漸成熟，從單純的生產力工具轉變為需要在規模化運作下被信任、追溯和維護的基礎能力。
當治理融入平台時，速度與控制便不再互相衝突。追溯性成為競爭優勢。上下文成為組織記憶（institutional memory）。而程式碼庫非但不會累積無形風險，反而會成為隨著時間推移而變得更加可靠的資產。