編輯 | 云昭

Anthropic首席執(zhí)行官Dario時不時就會出來發(fā)聲，聲稱人工智能即將取代人工編碼，或者拋出一個驚人的數(shù)字，預(yù)測在短短6個月內(nèi)將有90%的編碼工作將被AI取代。

這種措辭無疑有夸大的成分，但這里想說的是，這并非空穴來風(fēng)，或許6個月內(nèi)AI不會取代90%的程序員，但取代90%的編程工作不無可能！因為企業(yè)接納和適配大模型的速度遠(yuǎn)比我們想象得要快！

ps：多說一嘴，前OpenAI創(chuàng)始成員Karpathy提出的Vibe Coding（氛圍編程）的概念，其實也是變相承認(rèn)了大模型在編程工作中的“取代”作用。

1.愛彼迎怒遷代碼6周搞定18個月工作量

近日，全球知名的民宿短租公寓預(yù)訂平臺愛彼迎披露了一次大模型驅(qū)動的內(nèi)部代碼遷移工作。

起因是愛彼迎希望擺脫之前用于 React 的 JavaScript 測試工具Enzyme，因為其對組件內(nèi)部的深度訪問已經(jīng)不再符合現(xiàn)代React測試實踐。

該公司已經(jīng)完成了首次大規(guī)模的LLM驅(qū)動的代碼遷移，將大約3500個React組件測試文件從Enzyme遷移到React Testing Library（RTL）。

令人意外地是，本來預(yù)計需要1年半的工程量，僅僅6周就搞定了！

“我們最初估計，如果手工完成這項工作，將需要1.5年的工程時間，但通過使用前沿模型和強(qiáng)大的自動化工具，我們僅用6周就完成了整個遷移過程?！睈郾擞能浖こ處烠harles Covey-Brandt在一篇博客文章中表示。

2.如何做到的？

2023年中期，愛彼迎在公司內(nèi)部驗證了使用LLM成功將數(shù)百個Enzyme文件轉(zhuǎn)換為RTL的概念，僅用了幾天時間。隨后，該公司在去年構(gòu)建了一個可擴(kuò)展的“LLM驅(qū)動遷移”管道。

該管道將遷移過程分解為自動驗證和重構(gòu)步驟?！懊總€文件都會經(jīng)過驗證階段，一旦檢查失敗，我們就引入LLM來修復(fù)它?！?Covey-Brandt表示。這種方法使得一次性遷移數(shù)百個文件變得容易。

為了提高遷移成功率，團(tuán)隊最初嘗試了提示工程，但發(fā)現(xiàn)暴力重試循環(huán)最為有效。他們實施了一個系統(tǒng)，每個遷移步驟都會多次進(jìn)行驗證，并根據(jù)錯誤動態(tài)更新提示內(nèi)容，包括錯誤信息和文件的最新版本。

除了增加重試次數(shù)外，團(tuán)隊還增加了提示上下文。一種富有上下文的提示工程方法幫助LLM理解各種團(tuán)隊特定的模式、常見的測試方法以及代碼庫的整體架構(gòu)。

“我們的提示內(nèi)容擴(kuò)展到了4萬到10萬token之間，涉及多達(dá)50個相關(guān)文件、大量手動編寫的少量示例，以及同一項目中現(xiàn)有的、編寫良好且通過測試的文件示例?！盋ovey-Brandt表示。

利用上述技術(shù)，愛彼迎僅用4小時就完成了75%的目標(biāo)文件遷移。然而，仍有900個文件未能通過基于步驟的驗證標(biāo)準(zhǔn)。隨后，該公司開發(fā)了目標(biāo)重運行工具。遷移狀態(tài)評論跟蹤每個文件的進(jìn)度，而重運行功能允許按失敗步驟進(jìn)行篩選。

“經(jīng)過4天的‘采樣、調(diào)整、清理’循環(huán)，我們完成的文件比例從75%提升到了97%，只剩下不到100個文件。” Covey-Brandt表示。對于剩余的文件，該公司認(rèn)為進(jìn)一步的重試嘗試似乎已經(jīng)達(dá)到了通過自動化修復(fù)的極限。他們手動處理了剩余的文件。

愛彼迎的成功案例并非AI驅(qū)動代碼遷移的首例。谷歌和亞馬遜等巨頭過去也曾透露過類似的情況。

3.谷歌的遷移速度提高了50%

今年早些時候，谷歌發(fā)布了一份全面報告，詳細(xì)介紹了其在涉及LLM的代碼遷移中的經(jīng)驗。報告顯示，LLM驅(qū)動的遷移使整個過程的速度提高了50%。

該公司以谷歌廣告代碼庫中將唯一標(biāo)識符類型從32位升級到64位為例。這種轉(zhuǎn)換是必要的，因為32位標(biāo)識符存在超出最大值的風(fēng)險，可能導(dǎo)致系統(tǒng)因整數(shù)溢出而出現(xiàn)故障。

“如果手動完成，整個工作預(yù)計將需要數(shù)百年的軟件工程工作量，并且需要復(fù)雜的跨團(tuán)隊協(xié)調(diào)?！惫雀璞硎荆⒘谐鲞w移過程中可能遇到的諸多挑戰(zhàn)。隨后，該公司設(shè)計了一個基于LLM的遷移工具包和人類工程師/專家的工作流程。谷歌發(fā)現(xiàn)，在變更列表中，80%的代碼修改完全由AI編寫，而剩下的20%則是人工編寫或修改的。

然而，該公司也提到，工程師們有時必須撤銷或調(diào)整某些AI生成的更改，因為這些更改存在不準(zhǔn)確之處或不必要的修改?！斑@一觀察結(jié)果促使我們進(jìn)一步投資于LLM驅(qū)動的驗證，以減輕這一負(fù)擔(dān)。”谷歌表示。

4.工程師喜歡AI驅(qū)動的遷移嗎？

亞馬遜網(wǎng)絡(luò)服務(wù)（AWS）對代碼遷移中的人類與AI合作關(guān)系進(jìn)行了研究。該研究重點關(guān)注使用亞馬遜Q代碼轉(zhuǎn)換工具將遺留Java代碼遷移到現(xiàn)代版本。通過對11名軟件開發(fā)人員的一系列訪談，研究發(fā)現(xiàn)開發(fā)人員將AI視為協(xié)作伙伴。

研究表明，開發(fā)人員希望在遷移過程中保持控制權(quán)，根據(jù)自己的專業(yè)知識指導(dǎo)AI，并作為審查者仔細(xì)驗證更改。

“正如代碼審查有助于初級開發(fā)人員成長一樣，用戶對AI系統(tǒng)的建設(shè)性反饋使其能夠更好地符合預(yù)期，并像程序員吸收反饋一樣不斷修正其理解?！盇WS在報告的一個部分中表示。

此外，研究還建議，人類與AI合作關(guān)系系統(tǒng)的設(shè)計者應(yīng)揭示其局限性，而不是掩蓋不完美之處，以幫助調(diào)整預(yù)期。

研究還發(fā)現(xiàn)了一些錯誤，例如在未驗證是否為正確版本的情況下修改了Java依賴項。

“我覺得我像是被操縱了。第一篇文章說了一個版本，第二篇文章又說另一個版本。到底哪個才是真的？”一位受訪者在回應(yīng)這一錯誤時表示。

此外，即使AI生成了正確的輸出，參與者也表示他們希望對一切進(jìn)行雙重檢查。

“我不知道我是否會完全信任任何AI。我仍然會檢查一切。我不是說它會惡意行事，它確實給出了一個有效的依賴項更新，但我仍然會檢查一切。”

值得注意的是，上述場景是LLM驅(qū)動的代碼遷移，但并非完全由LLM自行完成的遷移，仍然需要人類的監(jiān)督、審查和驗證。

參考鏈接：https://analyticsindiamag.com/global-tech/airbnb-uses-llms-to-pull-off-an-18-month-enzyme-to-rtl-migration-in-just-6-weeks/