生成式 AI 正在帮助企业完成一项迟来的任务：更新自己的信息技术系统，将老旧过时的代码重写成现代编程语言形式，特别是那些广泛应用、但比披头士乐队还要“古老”的编程语言。

摩根士丹利全球技术与运营主管 Mike Pizzi 最近曝出，该公司内部通过自己构建的 AI 工具，在今年已经审查了 900 万行遗留代码，为开发者节约下 28 万小时的工作时长。这样的成果迅速引发了大家的关注。

使用自有代码库训练工具 

今年 1 月，摩根士丹利发布了一款名为 DevGen.AI 的工具，其基于 OpenAI 的 GPT 模型并由内部开发团队构建而成。DevGen.AI 能够将 Cobol 等语言编写的陈旧代码整理为简单的英语规范，再由开发者根据规范进行代码重写。

之所以选择自己构建，是因为在摩根士丹利看来，哪怕有了市面上主流 AI 编码工具的加持，对遗留软件进行现代化升级也难以找到有效的解决途径。

Pizzi 表示，这些商业 AI 工具更擅长编写新的现代代码，却不一定精通那些人气较低或者年代久远的编程语言，更不用说针对特定业务需求定制的语言了。他补充称，虽然不少科技企业正朝这个方向努力，但目前其产品还不具备企业应用所需要的灵活性。

鉴于此，摩根士丹利决定不再等待。“我们意识到，只有自主开发才能实现某些在其他商业产品中难以获得的重要功能。”Pizzi 表示。虽然现有工具在未来的迭代和改进中也许会实现同类功能，“但这至少是个抢先一步的机会”。

摩根士丹利使用自有代码库来训练 DevGen.AI，其中包含大量已不再广泛使用、甚至从未真正普及的编程语言。

Pizzi 介绍，该工具的真正优势在于将遗留代码“翻译”成英文规范，就相当于代码功能图谱。当前，熟悉或者能够理解某些古老或者小众编程语言的开发者越来越少。有了这些规范，任何开发者都可以利用现代编程语言实现遗留代码的现代化改造。

如今，该公司全球约 1.5 万名开发者已经在使用 DevGen.AI 处理一系列任务，包括将遗留代码翻译成简单的英语规范、隔离现有代码片段以满足监管 / 查询等需求，甚至可以将遗留代码的零散片段完全翻译成现代代码。

但他也承认，就整体代码“翻译”而言，这项技术仍有一定的进步空间。从技术上讲，DevGen.AI 能够使用 Python 这类新语言重写 Perl 等代码，但却不一定擅长将其编写成能够充分利用 Python 所有优势特性的高效成果。而这正是人类工程师的最大存在意义。

Pizzi 还乐观地表示，软件工程领域所能容纳的人才规模不会减少，反而会随着代码总量的增加而继续增长，其中就包括帮助摩根士丹利达成业务目标的更多 AI 应用。目前该公司有数百款 AI 用例正在开发，旨在拓展业务、推进工作流程自动化并提高运作效率。

但 Pizzi 同时强调，实现这一切的前提，在于建立一套现代化、标准化且精心设计的总体架构。

他总结道，“科技总是在吐故纳新。如今随着 AI 发展，这种现代化改造也变得愈发重要。”

值得注意的是，摩根士丹利这种选择直接与模型构建方合作，而非单纯使用“开箱即用”技术产品的做法，正越来越多地被金融服务机构采用。比如，法国巴黎银行（BNP Paribas）与 Mistral AI 建立了合作关系，加拿大道明银行（TD Bank）与 Cohere 开展合作。

用 AI 帮工程师理解旧代码库 

“一个不是空泛吹嘘、而是真正实用且没有被炒作的 AI 应用实例。”有网友如此评价摩根士丹利的做法。

实际上，不只摩根士丹利，其他企业也开始谨慎地尝试运用生成式 AI 工具更新自己的 IT 系统。

已经营 75 年的薪资处理服务商 ADP 的首席数据官 Amin Venjara 表示，“在我们这个行业，传统企业面临的最大问题就在于，到处都有 Cobol 代码的存在。”他补充称，精通 Cobol 的开发者数量正在减少，“如今别说雇用 Cobol 工程师了——年轻一代从业者里听说过 Cobol 的都不多。”

这家总部位于新泽西州罗斯兰的公司正探索利用生成式 AI 将其大型机代码从 Cobol（一种最初设计于上世纪 50 年代、至今仍被银行和金融服务企业广泛使用的语言）“翻译”成 Java（一种诞生于 1995 年的相对较为年轻的编程语言）。这个过程将减少物色及培训 Cobol 专家的需求。

总部位于波士顿的在线家具销售商 Wayfair，基于生成式 AI 编码工具已经在帮助这家企业的 2000 名开发者及数据科学家更新了旧代码。Wayfair 公司首席技术官 Fiona Tan 表示，该公司主要使用谷歌提供的编码助手。

成立“短短”二十年的 Wayfair 并不使用 Cobol，但仍拥有 PHP 等语言的遗留代码以及涉及 SQL 等语言的旧有数据库代码，外加大量因开发者离职而难以维护的代码。

“多年以来，企业积累的代码并没能得到充分的文档记录。所以无论使用哪种语言，对代码的追溯和整理都需要耗费大量时间。”Tan 指出。

Wayfair 依靠 AI 工具来帮助减少技术债，解决技术问题带来的种种潜在缺陷与成本难题。Tan 表示，工程师们可以借助 AI 快速掌握新语言，从而降低技术债的处理难度。

还有总部位于旧金山的数据存储与管理厂商 Databricks，正利用生成式 AI 帮助工程师们快速理解公司内部的旧有代码库。

“想要接手旧代码库真的很麻烦。因此，在 AI 协助下快速理解代码库功能对于工程师们来说极具现实意义。”该公司 CIO Zutshi 表示。

AI 厂商也瞄向这个痛点 

过去一年以来，微软 GitHub、亚马逊、谷歌及 IBM 的基于生成式 AI 的编程助手相继问世，开始帮助开发者们完成大量代码片段自动补全以及编写代码文档等任务。一部分开发者估计，编码助手能够将开发生产力提升约四分之一，主要用途包括帮助人们在编写文档时进行拼写检查、处理自动填充等任务。

但除了写新代码，这些 AI 工具开发商也在将目光放在帮助企业处理遗留系统的问题上。

IBM 的 WatsonX 编码助手使用生成式 AI 帮助开发者将代码从 Cobol 迁移至 Java，亦支持继续使用 Cobol。

已有百年之久的 IBM 仍高度依赖其大型机业务，并且需要为众多大型机客户提供技术支持。该公司正积极推广其 WatsonX AI 编码助手，希望帮助客户解决其传统技术方案中的缺陷。

“过去几十年间，我们客户在应用程序上的投入大多达不到如今的水平。也由于其应用程序体量庞大、往往包含数千万行代码，所以客户普遍面临着安全风险、技能挑战和知识差距等现实问题。”IBM Z 大型机软件副总裁 Skyla Loomis 表示。

IBM 的编码助手利用生成式 AI 帮助开发者将 Cobol 代码迁移至 Java，亦支持继续使用 Cobol——这家蓝色巨人强调，企业在短期内还不会彻底放弃 Cobol。作为 IBM 率先推出的大型数据服务器主机的实现基础，Cobol 软件虽在经历岁月洗礼后已经到了需要大量维护的阶段，但基本运行仍然良好。

与其他基于 AI 的编码助手一样，IBM 的工具能够为开发者提供新的代码建议，且允许用户以通俗易懂的自然语言进行提问。

Loomis 表示，IBM 编码助手有望帮助企业将原本需要多年的遗留系统更新任务缩短至一、两年内。她解释称，与现有工具相比，生成式 AI 能够“理解代码意图”并立即将其转换为可用的 Java 代码。

不过，“翻译”代码只是技术系统现代化这项宏观任务中的组成部分。

“如果把这看作一类复杂的工作流自动化工具，那就肯定需要多个 AI 模型协同起效。其中有些模型专注于代码生成，其他模型则负责关系映射和影响分析。”专注于 AI 和云计算的 Gartner 公司分析师 Arun Chandrasekaran 评论称。

对于更为复杂的遗留系统改造，被开发者广泛应用的 GitHub Copilot 还专门发文进行“教学”。GitHub 高级服务交付工程师 Ari LiVigni 在文中表示，将遗留代码现代化远不只是更新语法或替换旧库那么简单，还会遇到下面的挑战：

技术债务：遗留系统通常积压着多年（甚至数十年）累积的技术债。硬编码的逻辑、蔓延的依赖关系，以及那些不知怎么就变成了“永久”方案的“临时”修复，共同构成了一个脆弱、难以维护的混乱系统。

集成挑战：遗留系统的现代化不可能孤立进行。这些系统通常需要与更新的技术栈集成，而麻烦往往就出在这里。API 可能无法对齐，数据格式可能冲突，整个系统感觉就像是用胶带勉强粘在一起的纸牌屋，摇摇欲坠。

数据迁移与兼容性：遗留系统常常伴随着过时的数据格式或存储方式，这让整个现代化过程变得极其复杂。在确保与现代系统兼容的前提下，转换和迁移这些数据是最棘手的部分之一。

成本与资源压力：遗留系统现代化的代价很大。它需要时间、资金，以及已经人手吃紧的高级工程师。更还有组织内部的阻力：“反正没坏，干嘛要修？”。

性能与可扩展性限制：由于硬件限制、效率较低的代码和应用架构，遗留系统常常难以满足现代的性能要求。

安全漏洞：遗留代码的关键问题在于：它通常是在当今安全标准出现之前很久就写好了。那时候，“安全”可能意味着锁好服务器机房的门，而不是防范 SQL 注入或勒索软件。因此，遗留系统可能存在大量安全漏洞，现代攻击者可是乐见其成。

测试困难：遗留代码现代化的“终极 Boss”就是测试。每一次小改动都有可能意外引发系统其他部分的问题，而且这些问题可能要几周后才会显现。

因此，LiVigni 亲自用 Copilot 演示如何对遗留代码进行现代化改造，并给出建议：不要试图一次性重构整个系统，应先聚焦于某个函数或模块，然后再逐步深入；在修改任何一行代码之前，先编写测试来验证当前的行为；做好版本控制，在隔离的环境中测试和审查更改。

最后，他还提出一点：始终审查 Copilot 的建议。“Copilot 的建议通常非常精准且具有参考价值，但人类的审查仍然是关键。务必逐条检查 Copilot 提出的更改，确保它们符合你系统的上下文和代码规范。”

一切生成式 AI 工具的引入都会带来新的风险。部分技术领导者表示，尽管基于 AI 的快速代码编写极具诱惑力，但这也可能导致文档不完整或者混入大量无关代码，因此需要更严格的人为监督。

“要想快速行动，就必然要背负一定量的技术债。我们要做的就是在效率与负担之间寻求平衡点。”ADP 公司的 Venjara 说道。

一些隐忧 

虽然像摩根士丹利这样的企业已经取得了不小收获，不过仍有一些细节问题引发了开发者们关注。

在 AI 编程工具在遗留代码的“翻译”问题上，有开发者提出疑问：使用者怎么能验证那些内容呢？他们是 Python 开发者，而 Perl 对他们来说简直像天书一样。虽然节省了大量时间，但如果重新实现的逻辑是错误的，那后果可能会很严重。

开发者 zach_miller 认为，这个问题应该归为：“他们用 AI 写的代码是否比不用 AI 写的更容易出错”，而不是“他们用 AI 写的代码是否 100% 没有 bug”。

“我怀疑，任何一个团队如果要在一段合理的时间内从一种他们不熟悉的语言进行大规模重构，无论有没有 AI，都不太可能写出完全没有 bug 的代码。”zach_miller 表示，“但如果问题是前者（即 AI 写的代码是否更容易出错），除非它真的 bug 多到不可接受，否则我会想：AI 带来的开发速度提升是否能抵消那些可能多出来的 bug？毕竟如果更早完成，他们就能有更多时间来专注于修复 bug。”

对此，开发者 iforgotpassword 认为，这取决于当开发者面前已经摆着一份清晰又简单的描述、告诉他们需要实现什么功能时，他们是否还有能力和意愿去费力查看旧代码。

“当然，说到底管理层只关心哪条路更省钱——包括因为 AI 给出错误描述而引发的任何事故所造成的成本。这可能也取决于谁在使用这项技术。如果是银行用，代价可能是数百万甚至数十亿美元。如果是医疗设备，那代价可能就是人命了。不过至少到时候我们可以甩锅给 AI，这样就没有人是过错方了。”

参考链接：

https://www.wsj.com/articles/can-ai-solve-legacy-tech-problems-companies-are-putting-it-to-the-test-36d9c490

https://www.wsj.com/articles/how-morgan-stanley-tackled-one-of-codings-toughest-problems-4f465959

https://github.blog/ai-and-ml/github-copilot/modernizing-legacy-code-with-github-copilot-tips-and-examples/