開發者正在驗證他們未曾編寫——甚至可能不理解——的程式碼

GitLab於週二釋出了其AI問責制報告，聚焦於AI編碼工具給軟體工程團隊帶來的巨大下游壓力，旨在評估“行業對話”的走向。這一敘事似乎已從團隊能多快生成程式碼，轉向他們是否能真正控制所交付的內容。

哈里斯民意調查代表GitLab對六個國家的1528名開發者和技術買家進行了調查。結果顯示，91%的組織正在積極使用兩個或更多AI編碼工具，78%的受訪者表示採用AI工具後開發者編寫和提交程式碼的速度更快。但速度正在超越控制——43%的受訪者表示無法可靠地區分自己程式碼庫中AI生成的程式碼和人類編寫的程式碼。

GitLab首席產品與營銷官Manav Khurana告訴The New Stack，該研究揭示了一個因程式碼產量激增而出現的治理缺口。他指出：“AI已將瓶頸從編寫程式碼轉移到審查程式碼——85%的受訪者證實了這一點。開發者現在需要驗證他們未曾編寫且可能不完全理解的程式碼，負擔加重。編寫程式碼速度的提升被長達數天的審查週期所抵消。”

Khurana提醒，雖然編碼速度提高了，但編寫程式碼只是軟體開發生命週期的一部分：編碼前有需求，編碼過程中有審查、安全、測試和部署，編碼後有增強、整合和維護。他認為解決方案是使用代理基礎設施，使軟體交付的其餘部分與代理編碼保持相同速度。這意味著機器規模的執行、整個生命週期的上下文、內建於流程中的治理以及跨所有層的編排。

接下來是工具鏈問題。Khurana強調：“只有28%的組織表示其SDLC工具完全整合，共享資料和工作流。審查代理生成的合併請求的開發者可以看到誰呼叫了代理以及它關聯了哪個問題。但他們通常無法看到——除非從多個系統中拉取——它涉及了哪些安全發現、受何種政策管轄以及引入的風險是否已解決。”

GitLab的理念是，當治理內建於平臺時，程式碼審查基於團隊和公司的政策自動進行。所有代理操作都與身份關聯、記錄在政策中，並在審查流程中自動呈現。Khurana建議：“目標是讓治理層對開發者透明，從而使審查者能夠專注於需要人類判斷的決策。”

在提供機器規模代理執行方面，GitLab開發了新的Git後端和介面，聲稱將“可靠地支援數百萬代理會話”且速度極快。在其測試中，與當前一代Git相比，觀察到牆壁時鐘時間最多快50倍，網路流量最多減少1000倍。Khurana澄清：“我們還為上下文進行了工程設計。GitLab Orbit（今年6月10日推出）為代理提供了一個上下文圖，連線程式碼、流水線、工作項、安全發現和生產訊號。在我們的測試中，代理工作速度提升11倍，所需令牌減少4.5倍，幻覺減少45倍。更重要的是，代理現在可以回答以前無法回答的問題，因為它們可以透過一次圖形呼叫獲取所需的所有上下文。”此外，還在推進額外的治理和編排開發，以確保代理操作根據團隊定義的策略自動協調。

關鍵在於，GitLab報告將AI問責制定義為回答關於任何一行AI生成程式碼的三個問題的組織和技術能力：這些程式碼來自哪裡？它原本要做什麼？一旦投入生產，誰對其負責？GitLab表示，大多陣列織目前無法回答這些問題。由於不清楚AI程式碼執行的“誰、什麼、哪裡”（推測還包括“為什麼”和“何時”），Khurana表示成本上升通常是治理缺口擴大的明確訊號。他解釋，代理在並非為其構建的基礎設施上低效消耗令牌，表明缺乏上下文和治理層。

Khurana堅持：“大多陣列織透過將AI編碼工具疊加在現有基礎設施上來追求代理軟體工程，問題迅速顯現。這是GitLab方法的不同之處。GitLab正在構建其他工具未能解決的代理基礎設施——從機器規模執行到上下文、治理和整個軟體生命週期的編排。編碼助手使單個開發者更快——而我們做的是使整個系統以機器速度移動而不失去控制。”

GitLab研究的其他資料提供了兩個重要百分比：91%的組織可能在未來12個月內投資AI程式碼治理工具；98%已經分配或預計分配預算。此外，85%的人同意軟體中AI的下一個階段將更少關注程式碼生成，更多關注治理。

Khurana指出了企業在思考AI方面的“成熟化”，如果做得好，會將AI程式碼功能從生產力工具轉變為可擴充套件的基礎能力。這種成熟化對高層工程專案管理有影響，也對剛起步的初級開發者有影響。他總結：“現在最重要的技能之一是判斷力。投資於深入理解系統（不僅僅是語法）並能將程式碼追溯迴流水線、安全發現和生產訊號的初級開發者，是使代理工程工作的人。”我們知道代理能比任何開發者更快地生成程式碼，但當前它們無法評估這些程式碼是否適合系統及其需要滿足的需求。