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 辅助完成的字符数量已经超过了开发人员手动输入的数量。"
