РАЗРАБОТКА

OpenAI заявила о резком росте качества миграции legacy-кода

GPT-6.1 Sol достиг 86,6% точности при миграции COBOL-кода при низком уровне рассуждений, заявила OpenAI.

✍️ Редакция iTech News | 21.10.2026 | ⏱ 4 мин | Источник: BleepingComputer
OpenAI заявила о резком росте качества миграции legacy-кода

OpenAI заявила, что GPT-6.1 Sol справляется с переносом COBOL-программ в современные языки с точностью 86,6% при низком уровне рассуждений. Для компаний, у которых критичные процессы до сих пор живут на мейнфреймах, миграция legacy-кода может перестать быть проектом на годы с очередью из редких специалистов — но только если не путать хороший бенчмарк с готовностью к промышленному запуску.

О результатах, опубликованных OpenAI, сообщает BleepingComputer. Компания сравнила GPT-6.1 Sol с GPT-5.6 Sol на задаче переноса программ с COBOL в C++, Java, Kotlin, Python и Rust при сохранении исходного поведения. При одинаковом низком уровне reasoning новая модель показала 86,6% точности против 5,4% у предшественника, причём, по оценке OpenAI, обошлась в 61% его API-затрат. При более высоком уровне рассуждений результат достиг 97,9% — почти потолок для этой оценки.

Речь не о декоративном умении написать пару строк на языке из учебника. COBOL по-прежнему обслуживает заметную часть мировой финансовой инфраструктуры: OpenAI приводит оценки, согласно которым на нём работают более 40% систем интернет-банкинга, 80% операций по картам в физических точках и 95% транзакций через банкоматы. Fortran, другой старожил из тестов, используется в прогнозировании погоды и расчётах, связанных с безопасностью ядерных реакторов. Ошибка при переносе такого кода — это не неудачный релиз лендинга, который можно быстро откатить.

Проверка не ограничилась COBOL

Для оценки навыков работы с редкими и старыми языками OpenAI создала MultiLangBench. В этом наборе модель должна с нуля собрать совместимый с SQLite движок базы данных на одном из 20 языков. Средний процент успешно пройденных тестов у GPT-6 Astra составил 87,4%; у GPT-5.6 Sol — 26,8%. Разрыв особенно заметен там, где у моделей традиционно меньше обучающих примеров и документации.

В COBOL показатель вырос с 10,9% до 72,1%, в Fortran — с 21,4% до 83,5%, в OCaml — с 25,6% до 85,8%, в Visual Basic — с 27,5% до 89,4%. Такие цифры выглядят сильнее привычных демонстраций на Python и JavaScript: для популярных стеков генерация кода давно стала базовой функцией, а вот специалисты по COBOL и Visual Basic часто одновременно являются носителями бизнес-логики, накопленной десятилетиями.

Практический сценарий для команды — не нажать кнопку «переписать на Rust», а использовать модель как ускоритель инвентаризации и перевода. Она может помочь разобрать зависимые модули, подготовить черновой код на целевой платформе, сгенерировать тесты на эквивалентность поведения и объяснить фрагменты, которые давно никто не трогал. Это способ сократить ручную работу и снизить зависимость от узкого рынка экспертов, а не лицензия на вывод из процесса архитекторов, тестировщиков и владельцев предметной области.

Ключевой риск миграции legacy-кода — в том, что тесты бенчмарка не содержат весь багаж реальной системы: закрытые форматы данных, ночные пакетные обработки, договорённости с внешними контрагентами, странные исключения в расчётах и требования регуляторов. Модель может корректно сохранить логику функции и одновременно не знать, что поле фиксированной длины однажды было зарезервировано под интеграцию с платёжным шлюзом. Поэтому результат OpenAI следует воспринимать как сигнал о более зрелом инструменте для подготовки миграции, а не как доказательство автономной замены команды.

Что меняется для бизнеса

Для IT-директоров и фаундеров важен не только процент точности, но и экономика процесса. Если модель действительно даёт сопоставимый результат при меньшей стоимости API, можно чаще запускать анализ старого кода, строить прототипы целевой архитектуры и покрывать тестами участки, до которых годами не доходили руки. Для разработчиков это означает рост спроса на инженеров, способных проверить семантику переноса, настроить контуры валидации и связать новый стек с реальными бизнес-правилами.

Следующая проверка будет проходить уже не на SQLite-движках, а на закрытых корпоративных репозиториях. Там станет ясно, превращается ли миграция legacy-кода в предсказуемый инженерный конвейер или модели пока лишь заметно быстрее создают качественные черновики. Исходные цифры и описание эксперимента можно сверить в материале BleepingComputer.

Поделиться: Telegram X LinkedIn