COBOL 或通用商业导向语言（Common Business Oriented Language）是最古老的编程语言之一，其历史可追溯到 1959 年左右。但它的持久生命力令人惊讶；根据 2022 年的一项调查，在生产系统中使用的 COBOL 行数超过 8000 亿行，而 2017 年估计为 2200 亿行。
但是，COBOL 因其难以驾驭同时又效率低下而声名狼藉。为什么不迁移到更新的语言呢？这是因为对于大型企业来说，由于世界上的 COBOL 专家为数不多，这往往是一个复杂且成本高昂的命题。澳大利亚联邦银行在 2012 年更换其核心 COBOL 平台时，耗时五年，花费超过 7 亿澳元。
为了给COBOL应用程序的现代化问题提供一个新的解决方案，IBM今天发布了IBM Z的Code Assistant，它使用代码生成人工智能模型将COBOL代码翻译成Java。Code Assistant for IBM Z将于2023年第四季度全面上市，并将于今年9月初在拉斯维加斯举行的IBM TechXchange大会上进行预览。
IBM Research首席科学家Ruchir Puri表示，Code Assistant for IBM Z旨在帮助企业重构其大型机应用程序，最好能同时保持性能和安全性。Code Assistant 可在本地运行，也可作为托管服务在云中运行，它由代码生成模型 CodeNet 提供支持，该模型不仅能理解 COBOL 和 Java，还能理解约 80 种不同的编程语言。
"IBM建立了一个全新的、最先进的人工智能代码生成模型，可以将传统的COBOL程序转换为企业级Java，生成的代码具有高度的自然性，"Puri在接受电子邮件采访时说。"除了代码转换，代码助手还支持完整的应用现代化生命周期，帮助开发人员在现代架构中理解、重构、转换和验证翻译后的代码。"
CodeNet 使用 1.5 万亿个标记进行训练，拥有 200 亿个参数，并设计了一个大型上下文窗口--32,000 个标记--以"捕捉更广泛的上下文"，从而实现"更高效的 COBOL 到 Java 转换"。参数是模型从历史训练数据中学到的部分，本质上定义了模型处理问题（如生成文本）的技能，而"标记"则代表原始文本（例如，"fantastic"一词的"fan"、"tas"和"tic"）。至于上下文窗口，它指的是模型在生成额外文本之前所考虑的文本。
如今有很多工具、应用程序和服务可以将 COBOL 应用程序转换为 Java 语法，其中一些是完全自动化的。Puri 承认这一点，但他认为 Code Assistant 在降低成本和生成易于维护的代码的同时，采取了避免牺牲 COBOL 功能的措施，这与市场上的某些竞争对手的产品不同。
Puri 说："IBM 为 IBM Z 大型机打造的代码助手能够混合和匹配 COBOL 和 Java 服务。如果系统的'理解'和'重构'功能建议应用程序中的某个子服务需要保留在 COBOL 中，它就会保持这种状态，而其他子服务则会转换成 Java。"
这并不是说 Code Assistant 是完美无缺的。斯坦福大学最近的一项研究发现，使用类似代码生成人工智能系统的软件工程师更有可能导致他们开发的应用程序出现漏洞。事实上，普里警告说，在经过人类专家审查之前，不要部署代码助手生成的代码。
Puri 说："与任何人工智能系统一样，企业的 COBOL 应用程序可能存在独特的使用模式，而 IBM Z 代码助手可能尚未掌握这些模式。必须使用最先进的漏洞扫描仪扫描代码，以确保代码的安全性。"
撇开风险不谈，IBM 无疑认为代码助手等工具对其未来的发展非常重要。目前，IBM 大约 84% 的大型机客户运行 COBOL，其中大部分是金融和政府部门的客户。虽然 IBM 大型机部门在其整体业务中仍占很大比重，但该公司将大型机视为通向其托管和促进的广阔、有利可图的混合计算环境的桥梁。
IBM也看到了更广泛的代码生成人工智能工具的前景--打算与GitHub Copilot和亚马逊CodeWhisperer等应用竞争。今年 5 月，IBM 在其 Watsonx AI 服务中推出了 fm.model.code，该服务为 Watson Code Assistant（沃森代码助手）提供了支持，允许开发人员在包括红帽的 Ansible Lightspeed 在内的各种程序中使用纯英文提示生成代码。