譯者 | 核子可樂

審校 | 重樓

AI正成為加速代碼生成的有力推手，幫助開發(fā)者以前所未有的效率產(chǎn)出更多成果，為超高生產(chǎn)力、縮短開發(fā)周期、快速發(fā)布功能開啟新的可能。

但不少工程團隊也注意到由此帶來的趨勢：盡管單個開發(fā)者的代碼生成速度更快，但項目的整體交付時間并未縮短。這并非錯覺，METR最新研究發(fā)現(xiàn)，AI編程助手反而令資深開發(fā)者的生產(chǎn)力降低了19%。報告指出，“研究期間，開發(fā)者本以為使用AI能夠?qū)㈤_發(fā)周期縮短20%；可令人意外的是，啟用AI實際反而將完成時間拉長了19%。換言之，AI工具其實拖慢了開發(fā)速度?！?/span>

這種日益脫節(jié)的感受錯位，提示出“生產(chǎn)力悖論”。雖然開發(fā)生命周期中“代碼生成”這個孤立環(huán)節(jié)的速度大幅提升，但代碼審查、集成和測試等其他環(huán)節(jié)卻遭遇速度瓶頸。這也是現(xiàn)代流水線上的典型難題——單一環(huán)節(jié)的提速不僅不能讓整體效率增長，反而會造成嚴重的生產(chǎn)堆積。

本文將探討工程團隊如何診斷代碼堆積問題，重新調(diào)整工作流程以發(fā)揮AI速度優(yōu)勢，同時避免犧牲代碼質(zhì)量或加重開發(fā)者負擔。

AI生成代碼為何需要人工審核

生成式AI工具擅長生成語法正確、看似“可用”的代碼，但這種表象背后亦存在著危險的誤導。若未經(jīng)深思熟慮和嚴格的人工審核，團隊很可能交付出技術(shù)上可行，但卻在安全、效率、合規(guī)和維護等方面存在嚴重缺陷的成果。

于是乎，AI不斷增加PR數(shù)量及相應代碼量，但可用的審查人員及其日均處理能力卻保持不變。若不加以控制，這種不平衡必然導致倉促、表面化的粗糙審查，進而引發(fā)bug和漏洞；而如果放慢審查節(jié)奏，開發(fā)者的工作也將被拖累。

更令人頭痛的是，開發(fā)者使用AI的具體方式也各不相同。目前存在三種開發(fā)者體驗（DevX）流程，其對整體團隊造成的壓力亦有所區(qū)別：

1. 傳統(tǒng)開發(fā)者體驗（八成人工、二成AI）：資深開發(fā)者將軟件開發(fā)視為一門技藝，對AI輸出持懷疑態(tài)度，主要用其處理搜索查詢或者解決一些小型樣板任務。

2. 增強型開發(fā)者體驗（五成人工、五成AI）：現(xiàn)代高級用戶能夠流暢與AI協(xié)作，完成獨立的開發(fā)任務、故障排查及單元測試生成，借此提高效率并快速解決具有明確定義的問題。

3. 自主開發(fā)者體驗（二成人工、八成AI）：熟練的敏捷工程師們會將大部分代碼生成和迭代工作交給AI智能體，自身負責審查、測試和集成AI輸出，更多扮演系統(tǒng)架構(gòu)師和QA專家的角色。

不同工作流程對應不同的工具和支持需求，一刀切式的工具或純凈管理方法在多種工作模式間注定失敗。而唯一的共性，就是始終關(guān)注人類的參與和協(xié)調(diào)。

倦怠與瓶頸是風險根源

若不對軟件開發(fā)生命周期進行系統(tǒng)性調(diào)整，AI產(chǎn)出必將帶來更多下游工作。雖然快速生成上千行代碼看似效率極高，但隱性成本也會快速堆積，包括審查工作量增加、bug量累積、管理復雜性提高等。

人類開發(fā)者更傾向于創(chuàng)建較小的原子提交，以降低審查難度。但AI卻可能在一條提示詞下生成大量變更，導致審查者難以理解其整個范圍和影響。核心問題不僅僅是重復代碼，更在于理清這些變更所需要的大量時間與認知負荷。

METR的研究也進一步凸顯出這項挑戰(zhàn)。研究證實，即使開發(fā)者接納了AI生成代碼，也需要投入大量時間進行審查和編輯，方可確保其達到高標準：

75%的開發(fā)者表示他們會閱讀每一行AI生成的代碼，56%的開發(fā)者表示他們經(jīng)常需要進行重大修改以清理AI代碼。在調(diào)查中，100%的開發(fā)者均表示AI生成的代碼需要修改。

質(zhì)量保證方面同樣受到影響。以測試生成為例，測試覆蓋率當然重要，但AI的介入只是表面上提高了這項指標，但實際上很可能未進行有意義的行為測試。換言之，測試系統(tǒng)不僅需要完成預期任務，還得優(yōu)雅處理錯誤并保證在意外狀態(tài)下不致崩潰。

如何針對AI調(diào)整工作流程

為了高效運用AI以擺脫這種悖論，團隊必須改進開發(fā)實踐與文化，將注意力從單一開發(fā)者產(chǎn)出轉(zhuǎn)向整體系統(tǒng)的健康狀況。

首先，領(lǐng)導者必須加強代碼審查流程，并在開發(fā)人員和團隊層面強化責任制。這需要為PR設(shè)定明確的可審查性標準，并授權(quán)審查人員駁回過大或缺乏上下文的變更。

其次，負責任地推進自動化。使用靜態(tài)和動態(tài)分析工具協(xié)助測試和質(zhì)量檢查，但始終保證人工參與以解釋結(jié)果并做出最終判斷。

最后，協(xié)調(diào)預期。領(lǐng)導層必須明確，原始編碼速度只是一種虛假的效率指標。真正的目標是可持續(xù)的高質(zhì)量產(chǎn)出，這需要一種平衡的方法，使質(zhì)量和可持續(xù)性與生成速度保持同步。

除了文化上的轉(zhuǎn)變之外，以下兩項舉措也能帶來立竿見影的效果：

1. 建立通行的提示詞規(guī)則與上下文要求，引導AI生成符合組織最佳實踐的代碼。建立防護措施，防止AI產(chǎn)生幻覺或使用已棄用的庫，大大提高輸出可靠性。具體方式包括向AI提供上下文，例如經(jīng)過核準的庫列表、內(nèi)部實用函數(shù)及內(nèi)部API規(guī)范等。

2. 在流程早期引入分析工具。不要等PR出現(xiàn)才意識到AI生成代碼不夠安全。通過將分析工具直接集成至開發(fā)者IDE，即可立即發(fā)現(xiàn)并修復問題。這種立足早期的方法可確保在成本最低時解決問題，防止其在審查階段成為瓶頸。

新的AI時代下，我們的訴求應當是構(gòu)建更加智能的系統(tǒng)。工程團隊現(xiàn)在應專注于創(chuàng)建穩(wěn)定且可預測的指導框架，引導AI根據(jù)業(yè)務標準生成代碼，并使用核準且安全的資源以保證輸出與整體架構(gòu)相一致。

因此，生產(chǎn)力悖論并非不可避免，只要我們的工程系統(tǒng)能夠與AI工具同步發(fā)展。把握團隊成員的三種AI開發(fā)工作流程，即可成功邁出建立彈性更好、效率更高的軟件開發(fā)生命周期的第一步。

原文標題：The productivity paradox of AI-assisted coding，作者：Edgar Kussberg