Google 作為一個像 Microsoft 一樣熱衷於推廣 AI 軟體的公司，近期報告了其在內部使用 AI 技術的成果，並取得了令人滿意的效果。
在一篇預印本論文中，Google 的電腦科學家 Stoyan Nikolov、Daniele Codecasa、Anna Sjovall、Maxim Tabachnyk、Satish Chandra、Siddharth Taneja 和 Celal Ziftci 回答了論文標題提出的問題："Google 如何在內部代碼遷移中使用 AI？"
這個問題引起了廣泛關注，特別是在 Amazon 宣稱使用其 Q Developer AI 編碼助手將 Java 8 應用遷移到 Java 17，從而節省數億成本之後。
這些 Google 軟體工程師通過講述他們如何應用大語言模型 (LLMs) 來加速代碼遷移過程，試圖滿足人們的好奇心。
作者在論文中指出："我們發現使用 LLMs 能顯著減少遷移所需時間，並降低開始和完成遷移項目的障礙。"
他們的重點是針對特定產品領域 (如廣告、搜索、Workspace 和 YouTube) 開發的定製 AI 工具，而不是提供代碼補全、代碼審查和問答等通用服務的通用 AI 工具。
Google 的代碼遷移包括：將 Google Ads 超過 5 億行代碼庫中的 32 位 ID 改為 64 位 ID；將舊的 JUnit3 測試庫轉換為 JUnit4；以及用 Java 標準的 java.time 包替換 Joda time 庫。
Google 工程師解釋說，int32 到 int64 的遷移並不簡單，因為這些 ID 通常是通用定義的 (C 中的 int32_t 或 Java 中的 Integer)，不容易搜索。它們存在於數千個文件中的數萬個代碼位置。需要跟蹤多個團隊的變更，並考慮跨多個文件的類接口變更。
作者解釋說："如果完全手動完成，預計需要數百個軟體工程師年的工作量和複雜的跨團隊協調。"
對於基於 LLM 的工作流程，Google 的軟體工程師實施了以下流程：
廣告團隊的工程師使用代碼搜索、Kythe 和自定義腳本的組合來識別需要遷移的 ID。
然後，由熟悉該領域的人員觸發運行基於 LLM 的遷移工具包，生成通過單元測試的驗證更改。這些更改會由同一工程師手動檢查並可能進行修正。
之後，代碼更改會發送給負責受影響代碼庫部分的多個審查者。
結果顯示，變更列表 (CLs) 中 80% 的代碼修改完全是 AI 的產物；其餘要麼是人工編寫的，要麼是經過人工編輯的 AI 建議。
作者觀察到："我們發現在大多數情況下，人類需要撤銷模型做出的一些不正確或不必要的更改。鑑於修改代碼的複雜性和敏感性，需要花費精力仔細向用戶推出每個更改。"
基於此，Google 進一步開展了基於 LLM 的驗證工作，以減少詳細審查的需求。
即使需要仔細檢查 LLM 的工作，作者估計完成遷移所需的時間減少了 50%。
在 LLM 的協助下，僅用了三個月時間就完成了 JUnit3 到 JUnit4 的轉換，遷移了 5,359 個文件並修改了 149,000 行代碼。約 87% 的 AI 生成的代碼無需更改就可以提交。
至於 Joda-Java 時間框架的切換，作者估計與預計的手動更改時間相比節省了 89% 的時間，不過沒有提供具體數據支持這一說法。
作者總結道："LLMs 為協助、現代化和更新大型代碼庫提供了重要機會。它們具有很大的靈活性，因此，各種代碼轉換任務可以在類似的工作流程中進行並取得成功。這種方法有可能從根本上改變大型企業維護代碼的方式。"
Google 工程師還強調，LLMs 應該被視為傳統遷移技術的補充，這些技術依賴於抽象語法樹 (ASTs) 和類似 grep 的搜索。他們指出，可能需要額外的工具來防止人工審查過程成為瓶頸。
LLMs 應與其他工具結合使用的另一個原因是它們可能成本很高——因此最好不要不必要地使用它們。
作者指出："儘管每個 Token 的預測成本已steadily steadily 下降，但遷移通常需要處理數千個文件，成本可能會快速累積。"
即便如此，毫無疑問 AI 已經深刻改變了 Google 開發內部軟體的方式。根據論文，"現在代碼中由 AI 輔助完成的字符數量已經超過了開發人員手動輸入的數量。"
