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 在內的各種程序中使用純英文提示生成代碼。