自動補全適用于小型任務，但當今的開發(fā)者需要超越逐行輔助的AI工具，這些工具能夠適應更廣泛的項目環(huán)境，從而實現(xiàn)真正的生產(chǎn)力提升。

譯自AI Code Assistants Are Moving Beyond Auto-Complete: Here’s What’s Next，作者 Ado Kukic。

直到最近，AI 代碼助手這個術語還與自動補全功能同義。這是有原因的。AI 輔助代碼補全功能，它會在開發(fā)者輸入時預測并建議接下來的幾個字符、單詞或行，是根據(jù)工作流程和需要提供相關幫助的一個很好的例子。我從事專業(yè)編寫和維護代碼已有20多年了。在 AI 輔助代碼補全之前，各種開發(fā)者工具已經(jīng)通過依賴 IDE 中內(nèi)置的語言服務器功能提供了類似的功能。因此，AI 驅動的代碼補全感覺像是 IDE 及其為開發(fā)者提供的幫助的自然發(fā)展步驟。

另一種流行的 AI 交互方式，即聊天界面，對于開發(fā)者來說并不被認為非常有價值，因為它主要只回答通用查詢，例如“如何反轉鏈表？”，而這在開發(fā)者的日常工作中并不需要。

因此，完成接受率 (CAR)（一個計算開發(fā)者接受 AI 建議完成的百分比的指標）成為許多 AI 代碼工具的關鍵績效指標。代碼工具的營銷材料重點介紹了它們的自動補全功能，通常展示它們?nèi)绾文軌蛲ㄟ^減少擊鍵次數(shù)來節(jié)省[開發(fā)人員的時間]。

然而，這種情況正在改變。

使自動補全有用的“流程”也限制了它

當你坐下來編寫一段代碼時，代碼會神奇地出現(xiàn)在你的屏幕上，這可能是一種真正類似于流程的體驗。然而，同樣的“上下文”質(zhì)量——在你需要的時候，在你需要的地方提供幫助——使自動補全變得有幫助，這也是限制其效用的原因：

• 范圍有限: 編寫代碼——一項極其依賴人的活動——以人的速度進行。此外，編寫代碼甚至并非一直是主要的開發(fā)者活動。
• 上下文狹窄: 自動補全逐行工作，缺乏對代碼更廣泛上下文或開發(fā)者意圖的理解。
• 對延遲敏感: 必須盡快提供補全，這限制了可以使用的 AI 模型。任何提供建議的延遲都會擾亂開發(fā)者的流程。

因此，由此帶來的軟件開發(fā)速度的提高充其量只是漸進式的。

解決復雜的軟件問題不僅僅需要編寫代碼

我們看到開發(fā)者使用 AI 工具的方式正在發(fā)生轉變。AI 代碼助手僅僅完成你的代碼行已經(jīng)不夠了。工程團隊的需求更多。他們希望解決更復雜的問題。他們希望生成全新的功能，重構遺留代碼，將代碼現(xiàn)代化到更新的語言和框架版本，提高代碼測試覆蓋率，提高對安全和編碼標準的合規(guī)性，等等。所有這些都無法通過自動補全來完成。它需要對組織更廣泛的代碼庫（超出開發(fā)者同時處理的幾個文件）有更深入的理解。大多數(shù) AI 代碼助手都缺乏這種能力。

截至今天，此類任務的最佳界面是良好的 AI 驅動的聊天。開發(fā)人員意識到，同樣的聊天如果缺乏上下文，可能會過于通用而無用（記住反轉鏈表？），但在擁有適當?shù)纳舷挛臅r，它會變成一臺強大的機器。這就解釋了為什么開發(fā)人員轉向面向聊天的編程 (CHOP) 或通過迭代提示改進進行編碼來解決他們的問題。

讓我們來看一個面向聊天編程如何幫助我的最新例子。我正在開發(fā)一個處理大量視頻內(nèi)容的應用程序。用戶會上傳視頻，我的服務需要將它們編碼成各種格式，創(chuàng)建剪輯，將音頻提取到 .mp3 文件中，等等。

許多這些操作都將非常計算密集型，因此我需要構建一個排隊系統(tǒng)，該系統(tǒng)可以調(diào)度作業(yè)，在資源可用時處理任務，并在任務完成后更新隊列。我最初通過依賴 Redis（一個用于創(chuàng)建排隊系統(tǒng)的強大的鍵值存儲）構建了所有功能。

我的實現(xiàn)方案在測試中運行良好，但一旦上線并開始使用我構建的排隊系統(tǒng)，我很快意識到我的實現(xiàn)方案更適合關系數(shù)據(jù)庫。該系統(tǒng)依賴于我需要訪問的各種屬性，這意味著必須查詢大量不必要的數(shù)據(jù)才能從Redis獲取我需要的鍵值對。將所有內(nèi)容重寫為使用SQLite將是一項相當大的工作。盡管如此，由于面向聊天的編程，我只需在我的編碼助手之間通過幾條聊天消息，并使用我的代碼庫作為上下文，就可以進行這項代碼庫范圍內(nèi)的更改。

圖片

AI編碼助手不僅為我提供了關于需要發(fā)生什么的逐步說明，而且還生成了可工作的代碼，用SQLite數(shù)據(jù)庫查詢替換了現(xiàn)有的Redis調(diào)用，生成了與我在Redis中使用的匹配的正確模式，并為我提供了關于去哪里以及更新什么的精確說明，從而節(jié)省了我無數(shù)小時的手動遷移工作。說到遷移，我還讓我的編碼助手編寫了新的功能，將Redis中所有現(xiàn)有的作業(yè)數(shù)據(jù)遷移到SQLite，以便在新版本部署時不會丟失任何數(shù)據(jù)。

圖片

成功取決于結果，而非輸出

隨著這一演變，成功的衡量標準也發(fā)生了變化。完成接受率 (CAR) 仍然很重要，但不再是黃金標準。相反，工程團隊正在關注更全面的衡量指標：

• 節(jié)省的時間: 使用此工具減少了多少總體開發(fā)時間？
• 問題解決能力: 此工具能否幫助解決復雜的編碼難題？
• 代碼質(zhì)量改進: 此工具能否幫助提高代碼庫的整體質(zhì)量和可維護性？
• 學習和適應: 此工具如何適應項目特定的需求和編碼風格？

展望未來

即使在AI使用成為編碼主流的最初兩年中，使用模式也從更“代碼輸入”的活動迅速發(fā)展到更具迭代性設計或轉換的活動。隨著我們繼續(xù)前進，很明顯，自動完成雖然仍然有用，但這只是AI輔助編碼的冰山一角。編碼與在編輯器中努力地進行輸入的日子已經(jīng)過去了。

未來屬于更全面、更上下文感知的AI系統(tǒng)，這些系統(tǒng)能夠真正理解并協(xié)助軟件開發(fā)。我們?nèi)绾味x編碼技能以及未來軟件工作的培訓方式可能與今天的有所不同。通過智能提示最有效地利用AI，并結合其他有助于理解代碼的工具，可能會成為軟件構建方式的重要方面。