Evidence at a glance
Model Gains Meet a Maintenance Problem
On October 19, 2026, OpenAI published an update on its models' coding capabilities in low-resource programming languages, describing software construction and migration results for languages including COBOL, Fortran, and Visual Basic. The problem is specific: these languages have less code and documentation available for models to learn from than languages such as Python and JavaScript, yet they still underpin work ranging from banking transactions to weather forecasting and nuclear reactor safety analysis. OpenAI is not announcing a new language or a migration product. It is describing model improvements alongside two evaluations intended to measure them.
The update is worth a technical leader's attention not simply because a model can now write COBOL. Legacy maintenance is often difficult for reasons beyond syntax. Documentation may be incomplete, original developers may have left, and business rules may survive only in the system's actual behavior. When fixing defects or migrating a language, a team needs to change the implementation without breaking behavior on which other parts of the business depend. That is the central problem these evaluations attempt to examine.
Two Evaluations Test Two Different Capabilities
MultiLangBench tests the ability to build software from scratch. A model must implement a SQLite-compatible database engine in a specified language, organizing a codebase, managing state, handling errors, and adding features without breaking existing functionality during an extended coding session. The evaluation adapts tests from SQLite's existing suite and uses database files as a shared interface across languages. A candidate program receives an initial database and a SQL query, produces a modified database, and is checked against the expected contents using the reference SQLite implementation.
The value of this design is that implementations in different languages face a common kind of functional check, rather than being compared by code length or surface-level syntax. The evaluation reports both test pass rate and API cost, asking how much working functionality a model can build and what it costs to do so. The separate COBOL migration evaluation asks a different question: after an existing program is moved to another language, does its behavior remain intact? Together, the tests cover both building something new and preserving behavior during migration, but they do not amount to a complete acceptance test for a real enterprise system.
High Scores Still Leave Differences Between Languages
At maximum reasoning effort on MultiLangBench, GPT-6 Astra achieves an average test pass rate of 87.4% across 20 languages, compared with 26.8% for GPT-5.6 Sol. OpenAI says Astra improves on the earlier model in every language tested and exceeds 83% in 19 of them. The results are not uniform, however. Visual Basic rises from 27.5% to 89.4%, Fortran from 21.4% to 83.5%, and OCaml from 25.6% to 85.8%. COBOL improves from 10.9% to 72.1%, but remains the hardest language in the evaluation.
GPT-6 Luna presents a different trade-off between capability and cost. At maximum reasoning effort, its average pass rate is 40.3%, below Astra's, while the reported estimated API cost is approximately 78% lower. Luna also outperforms GPT-5.6 Sol in every language tested. Its scores for COBOL, Fortran, OCaml, and Visual Basic are 17.1%, 31.4%, 34.1%, and 41.6%, respectively. The choice is therefore not simply whether a new model is stronger. It is also how much a team is willing to pay in reasoning cost for a higher chance of passing the tests.
A High Migration Score Does Not Eliminate Migration Risk
The COBOL migration results show a particularly sharp rise. GPT-6.1 Sol reaches 86.6% accuracy at low reasoning effort, compared with 5.4% for GPT-5.6 Sol, while the reported cost is 39% lower. At higher reasoning effort, accuracy reaches 97.9%, nearly saturating the evaluation. These figures support a limited but important conclusion: on this specific evaluation, the newer model is more likely to perform the migration correctly, and its improvement at low reasoning effort does not depend on higher reported cost.
But accuracy remains a result defined by the evaluation. It cannot be translated directly into a production migration success rate. The material does not specify the test set's program sizes, the range of business rules, or the distribution of error severity. Nor does it explain how human review, external interfaces, and deployment environments factor into real migrations. A score near saturation shows strong performance on the defined tasks. It does not show that every edge case, historical exception, or hidden dependency in an enterprise codebase has been found. Technical leaders should use this evidence to select candidates and shape pilots, not to declare migration risk resolved.
Put the Model Inside a Behavioral Verification Loop
For maintenance teams, the practical implication is that models can be considered for more specific engineering tasks, rather than treated as general-purpose replacements for legacy-system owners. MultiLangBench's database-file interface illustrates how behavior can be expressed as repeatable inputs and outputs. Teams can use the same idea to consider building regression checks around their own critical programs before asking a model to help repair or migrate them. This is not a deployment method that the material says has already been validated. It is a working judgment drawn from the evaluation's design: define the behavior that must remain stable before deciding whether a model's changes are acceptable.
The next decision should be made by task, not by language label. A team could begin with programs whose boundaries are clear and whose tests can be reproduced, compare models on its own checks and API costs, and have people review the failure cases before expanding a pilot. If critical rules are not covered by tests, or program behavior is difficult to observe, a high benchmark score cannot replace the work of recovering missing knowledge and verifying outcomes. Model capabilities are improving, but with COBOL still the hardest language on MultiLangBench and the evaluation itself limited in scope, the sound judgment is to use models to accelerate verification, not to skip it.