19 октября 2026 года OpenAI представила новые результаты в области программирования на языках с ограниченным представлением в обучающих данных. Исследование по теме OpenAI и COBOL включает создание движка, совместимого с SQLite, и миграцию существующих программ. Показатели улучшились во внутренних тестах компании, однако для специалистов, обслуживающих такие системы, ключевым остаётся сохранение поведения программного обеспечения: включая правила, которые внешне более современный код способен незаметно изменить.
Что измеряют оба теста?
OpenAI разграничивает две возможности. MultiLangBench оценивает, сколько работоспособного программного обеспечения модель способна создать на двадцати языках. Второй тест касается перевода программ на COBOL с сохранением их выходных данных. Оба являются бенчмарками, опубликованными самим разработчиком, а не отчётом о завершённых банковских миграциях. Объявление обновляет картину агентного кодирования OpenAI: оно делает задачи и критерии успеха наблюдаемыми, что позволяет проверить заявленный прогресс.
Согласно данным OpenAI, на MultiLangBench GPT-6 Astra показывает средний процент прохождения тестов 87,4% против 26,8% у GPT-5.6 Sol при максимальном уровне рассуждения. В задаче миграции COBOL GPT-6.1 Sol достигает 86,6% при низком уровне рассуждения против 5,4% у предшественника, а при высоком уровне рассуждения результат составляет 97,9%. На MultiLangBench GPT-6 Luna набирает 40,3%. Тесты имеют разные критерии, поэтому эти проценты не образуют единого рейтинга.
Our latest model advances bring stronger capabilities for building and migrating software in low-resource programming languages such as COBOL, Fortran, and Visual Basic.
, OpenAI (@OpenAI) October 19, 2026
These languages power software that banks, governments, and businesses depend on. Progress here means… pic.twitter.com/Mulo5P3iCO
Для тех, кто следит за внедрением искусственного интеллекта на предприятиях, принципиально важно понять, какой именно вопрос задаётся системе. Написание новой функции и замена программы, работающей годами, могут требовать пересекающихся компетенций, но несут разные риски. Во втором случае кажущееся разумным упрощение способно изменить правило, которое нигде больше не задокументировано. Оценка должна учитывать и то, что новый код обязан сохранить.
Как проверяется восстановленный движок SQLite?
Публичный репозиторий MultiLangBench описывает протокол подробно. Модель получает документацию SQLite 3.40.1 и должна создать исполняемый файл на запрошенном языке. Каждый тестовый случай начинается с исходной базы данных, применяет запрос к проверяемой программе и сверяет результат с эталонной реализацией. Это позволяет оценивать реализации на разных языках через единый интерфейс, а не просто судить о том, выглядит ли код правдоподобно для читателя.
README также разграничивает доступный материал и рекомендуемую выборку. Около 24 000 тестовых случаев были конвертированы из исходного набора; по соображениям стоимости документация указывает подмножество из 272 тестов, допуская расширенные проверки при условии их явного указания. Неверно отождествлять количество случаев в репозитории с количеством, гарантированно выполненным в каждой оценке. Этот нюанс важен: процент становится сопоставимым только тогда, когда явно указаны выборка, среда и правила запуска.
Инструкции требуют среды без доступа к интернету и удаления копий SQLite, которые модель могла бы повторно использовать. Это условия, созданные для изоляции наблюдаемого навыка. При сравнении бенчмарков перечень доступных инструментов является частью результата. Здесь задача состоит в проверке способности построить реализацию: возможность обратиться к оригинальной программе изменила бы условия задачи и сделала бы полученный балл менее информативным.
Почему сохранить выходные данные сложнее, чем переписать?
На наш взгляд, наиболее содержательный критерий связан с преемственностью правил. Программа может компилироваться, быстро отвечать и формировать корректный файл, но при этом иначе обрабатывать граничный случай. Возьмём иллюстративный пример: в архиве пустое поле означает «требует проверки». Перезапись, которая всегда конвертирует его в ноль, пройдёт большинство стандартных тестов, однако изменит смысл незавершённых записей.
Сравнение с предыдущими выходными данными помогает выявить подобные расхождения. Само по себе не решает, было ли старое правило верным. Мы разграничиваем две задачи: воспроизвести существующее поведение и осознанно выбрать, какое поведение изменить. Их смешение затрудняет понимание: является ли расхождение ошибкой миграции или намеренным изменением. Человеческий контроль остаётся необходимым особенно тогда, когда решение зависит от бизнес-правила, а не от грамматики языка.
OpenAI описывает конкретный случай: арифметика с фиксированной точкой в COBOL отбрасывает лишние десятичные разряды, если округление явно не запрошено. Переписывание этой части с применением округления способно дать другие числа без каких-либо ошибок выполнения. Именно поэтому тест миграции требует побайтового соответствия наблюдаемых выходных данных и считает миграцию успешной только при прохождении всех тестов. Критерий «успеха» здесь строже, чем простая компиляция.
