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

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

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

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

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

衡量開發(fā)者倦怠

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

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

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

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

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

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

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

保持關(guān)注

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

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

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

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

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

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

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

“軟件開發(fā)90%依賴于大腦的運(yùn)作——理解需求、設(shè)計(jì)系統(tǒng)、考慮限制和約束，”他補(bǔ)充道。“將所有這些知識和理解轉(zhuǎn)換為實(shí)際代碼是工作中較為簡單的一部分。”

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

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

效率提升的實(shí)例

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

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

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

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

他表示：“對編程助手的期望應(yīng)適當(dāng)調(diào)整，因?yàn)樗鼈儾粫诘谝淮螄L試中寫出所有代碼，甚至不會寫出全部正確的代碼，這是一個(gè)迭代的過程，正確使用時(shí)，可以使開發(fā)者的編碼速度提高兩到三倍?！?/p>