編輯 | 云昭

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

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

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

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

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

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

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

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

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

2.如何做到的？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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