代碼分析公司發(fā)現(xiàn)，AI開發(fā)工具在關(guān)鍵編程指標(biāo)上沒有顯著優(yōu)勢，盡管其他人報告稱代碼助手在代碼審查方面帶來了小幅提升。

在GenAI浪潮中，編程助手是一個顯而易見的早期用例，但承諾的生產(chǎn)力提升并未如預(yù)期般顯著，甚至可能不存在。

許多開發(fā)者表示，AI編程助手提高了他們的工作效率，但最近一項研究對其產(chǎn)出進(jìn)行了衡量，發(fā)現(xiàn)并無顯著提升。根據(jù)提供代碼和協(xié)作數(shù)據(jù)洞察的公司 Uplevel 的研究，使用 GitHub Copilot 還引入了41%更多的漏洞。

該研究衡量了拉取請求(PR)周期時間，即將代碼合并到代碼庫的時間，以及 PR 吞吐量，即合并的拉取請求數(shù)量。研究發(fā)現(xiàn)，使用 Copilot 的開發(fā)者在這些方面沒有顯著改進(jìn)。

Uplevel 使用其客戶生成的數(shù)據(jù)，將大約800名開發(fā)者在使用 GitHub Copilot 三個月期間的產(chǎn)出與使用前的三個月進(jìn)行了比較。

衡量開發(fā)者倦怠

除了衡量生產(chǎn)力外，Uplevel 的研究還考察了開發(fā)者倦怠的因素，發(fā)現(xiàn) GitHub Copilot 在這方面也沒有幫助。標(biāo)準(zhǔn)工作時間之外的工作時長在使用代碼工具的測試組和控制組中都減少了，但在不使用 Copilot 時減少得更多。

Uplevel 的研究是出于對 AI 編程助手普及后所宣稱的重大生產(chǎn)力提升的好奇，Uplevel 的產(chǎn)品經(jīng)理兼數(shù)據(jù)分析師 Matt Hoffman 說道。今年8月發(fā)布的一項 GitHub 調(diào)查顯示，97% 的軟件工程師、開發(fā)者和程序員報告使用了AI編程助手。

“我們看到不同的研究顯示，人們說‘這對我們的生產(chǎn)力非常有幫助’，但我們也看到一些人表示，‘你知道嗎?我反而更多地成了(代碼)審查員?！?Hoffman 說道。

GitHub Copilot 的一位代表沒有對這項研究發(fā)表評論，但指出了一項最近的研究，表示開發(fā)者使用該編程助手編寫代碼的速度提高了55%。

Hoffman 說，Uplevel 團(tuán)隊最初也預(yù)計會看到一些生產(chǎn)力提升。

“我們的團(tuán)隊假設(shè)是，PR周期時間會縮短，”Hoffman 說道，“我們認(rèn)為他們會寫出更多代碼，而且我們實際上認(rèn)為漏洞率會降低，因為你在使用這些GenAI工具幫助你在發(fā)布前審查代碼?！?/p>

Hoffman 承認(rèn)，除了 PR 周期時間和 PR 吞吐量外，可能還有其他方式來衡量開發(fā)者的生產(chǎn)力，但 Uplevel 認(rèn)為這些指標(biāo)是衡量開發(fā)者產(chǎn)出的有力標(biāo)準(zhǔn)。

保持關(guān)注

此外，Uplevel 并未建議企業(yè)停止使用編程助手，因為這些工具正在快速進(jìn)步。

Hoffman 補充道：“我們聽說人們現(xiàn)在更多地成為代碼的審查者，而不是過去那樣直接編寫代碼，有時你可能會對生成的代碼過于信任，認(rèn)為它正在執(zhí)行你期望的任務(wù)。你需要密切關(guān)注生成的內(nèi)容，確保它真正符合你的預(yù)期。”

在實際工作中，開發(fā)團(tuán)隊報告了不同的結(jié)果。

Gehtsoft USA 是一家定制軟件開發(fā)公司，其 CEO Ivan Gekht 表示，他們的開發(fā)者在使用基于大型語言模型(LLM)的編程助手時，并未看到顯著的生產(chǎn)力提升。Gehtsoft 已經(jīng)在沙盒環(huán)境中測試了這些編程助手，但尚未在客戶項目中使用它們。

“理解和調(diào)試 AI 生成的代碼變得越來越具有挑戰(zhàn)性，故障排查的資源消耗如此之大，以至于重寫代碼比修復(fù)它更容易?！薄狪van Gekht，Gehtsoft CEO

他表示：“使用 LLM 提高生產(chǎn)力不僅要求 LLM 在能力上與人類相媲美，還要求用戶知道如何最有效地使用 LLM。LLM 不具備批判性思維、自我意識或思考能力。”

Gekht 補充道，寫幾行代碼與全面的軟件開發(fā)之間有很大的區(qū)別。他認(rèn)為，編寫代碼就像寫一句話，而開發(fā)軟件就像寫一本小說。

“軟件開發(fā)90%依賴于大腦的運作——理解需求、設(shè)計系統(tǒng)、考慮限制和約束，”他補充道?！皩⑺羞@些知識和理解轉(zhuǎn)換為實際代碼是工作中較為簡單的一部分?！?/p>

與 Uplevel 的研究類似，Gekht 也認(rèn)為 AI 助手會在代碼中引入錯誤。AI 生成的代碼的每一次新迭代都會因不同部分使用了不同的提示而導(dǎo)致一致性降低。

他說：“理解和調(diào)試 AI 生成的代碼變得越來越具有挑戰(zhàn)性，故障排查所需的資源消耗如此之大，以至于重寫代碼比修復(fù)它更容易?！?/p>

效率提升的實例

云服務(wù)提供商 Innovative Solutions 的編程助手使用體驗則大不相同，該公司的 CTO Travis Rehl 表示，使用像 Claude Dev 和 GitHub Copilot 這樣的編程助手，公司的生產(chǎn)力得到了顯著提升。公司還使用了自家開發(fā)的 Anthropic 集成來監(jiān)控拉取請求并驗證代碼質(zhì)量。

Rehl 觀察到，開發(fā)者的生產(chǎn)力提升了兩到三倍，這體現(xiàn)在開發(fā)者工單的完成速度、客戶交付成果的周轉(zhuǎn)時間以及通過代碼中漏洞數(shù)量來衡量的工單質(zhì)量上。

他還提到，團(tuán)隊最近通過使用編程助手在24小時內(nèi)完成了一個客戶項目，而過去完成同樣的項目大約需要30天。

然而，Rehl 認(rèn)為，關(guān)于編程助手的某些炒作——比如聲稱它們將取代整個開發(fā)團(tuán)隊，而不是簡單地作為補充或重新塑造開發(fā)流程——是不切實際的。他補充說，編程助手可以用于快速替換代碼或通過重新設(shè)計代碼片段來優(yōu)化代碼路徑。

他表示：“對編程助手的期望應(yīng)適當(dāng)調(diào)整，因為它們不會在第一次嘗試中寫出所有代碼，甚至不會寫出全部正確的代碼，這是一個迭代的過程，正確使用時，可以使開發(fā)者的編碼速度提高兩到三倍?！?/p>