23 февраля 2026 года цена акций IBM упала на 13 процентов за один день, что стало самым резким однодневным падением с октября 2000 года. Причиной стало объявление лаборатории искусственного интеллекта о возможности модернизации COBOL. Советы директоров компаний, использующих мэйнфреймы, прочитали это объявление и задались вопросом, может ли ИИ теперь преобразовать их COBOL и позволить им отключить мэйнфреймы. Ответ IBM, опубликованный в тот же день, был точным: «Трансляция практически не отражает реальной сложности, которая заключается в архитектуре данных, замене среды выполнения, целостности транзакций и нефункциональных требованиях, заложенных в платформу». Рынок перепутал две разные проблемы и оценил решение одной так, как если бы оно было решением обеих.
Две основные проблемы — это понимание и перевод. Это не этапы одной и той же деятельности. Это действительно разные технические задачи, с которыми ИИ справляется, обладая действительно разными возможностями и действительно разными рисками. ИИ значительно удешевил понимание кода COBOL. Он не сделал его значительно дешевле в плане замены. Это различие важно именно потому, что организациям, принимающим решения об инвестициях в модернизацию, необходимо знать, за решение какой проблемы они платят, что именно ИИ дает в каждом случае и где оставшаяся работа по проверке, независимо от инструментов ИИ, поглотит бюджет, высвободившийся благодаря экономии на понимании и переводе.
Структурная основа, необходимая для ИИ.
SMART TS XL ИИ выявляет недоступные программы до начала трансляции, поэтому вы переводите то, что работает, а не то, что существует.
УЗНАТЬ БОЛЬШЕ…Различие, которое рынок неправильно понял.
Понимание и перевод — это не одна и та же проблема.
Понимание — это дисциплина, изучающая, что делает код и почему, извлекая бизнес-цель из технической реализации. В контексте COBOL понимание означает: какие бизнес-правила закодированы в этой программе? Какие условия регулируют каждый путь выполнения? Какие данные она считывает и производит? Какие нижестоящие системы зависят от ее результатов? Что должен знать бизнес-аналитик об этой программе, чтобы написать спецификацию для ее замены? Понимание — это семантика, смысл, а не синтаксис.
Перевод — это дисциплина, заключающаяся в преобразовании кода с одного языка на другой с сохранением его поведения. В контексте COBOL перевод означает: создать код на Java (или Python, или Go), который делает то же, что и COBOL, для всех входных данных, при любых условиях, с достаточной численной эквивалентностью для последующих систем, которые обрабатывают выходные данные. Перевод — это структурная и поведенческая эквивалентность; новый код должен пройти все тесты, которые прошел бы старый код, включая тесты на граничные случаи, которые рассматривал первоначальный разработчик и о существовании которых вы, возможно, никогда не знали.
| Размеры | постижение | Переводы |
|---|---|---|
| Ответ на вопрос | Что означает этот код? | Что именно делает этот код? |
| Тип выхода | Естественный язык, документация | Исполняемый код |
| Последствия ошибки | Исправлено путем проверки человеком. | Инцидент на производстве |
| Возможности ИИ | Выдающиеся юристы с магистерской степенью превосходно владеют прозой. | Требуется слабый детерминизм. |
| Ограничение масштаба | Управляется с помощью контекстных окон. | Масштаб портфеля не соответствует контекстному ограничению. |
| Профиль риска | Низкий уровень, ошибки подлежат проверке. | Высокий уровень, ошибки незаметны до момента срабатывания. |
| Роль человека | Валидатор и обогатитель | Рецензент и проверяющий |
Эти проблемы взаимосвязаны, для качественного перевода требуется определенное понимание, но это не одна и та же проблема, и разрыв в возможностях ИИ между ними значителен. Понимание ИИ кода COBOL действительно впечатляет. Перевод кода COBOL на Java, пригодный для использования в производственной среде, — это действительно сложная задача, и именно смешение этих двух подходов на рынке объясняет, почему Gartner прогнозирует, что более 70 процентов проектов по выводу из эксплуатации мэйнфреймов, начатых в 2026 году, не принесут желаемых результатов.
Где понимание с помощью ИИ действительно приносит результаты
Проблема понимания текста обладает особенностью, которая делает ИИ хорошо подходящим для её решения: результатом является естественный язык, а генерация естественного языка — это то, что хорошо получается у больших языковых моделей. Когда ИИ читает программу на COBOL и создаёт документацию — описание того, что делает программа, объяснение её бизнес-правил, перечисление потоков данных — результатом является текст. Ошибки в этом тексте исправимы: человек-эксперт может обнаружить неправильно сформулированное бизнес-правило и исправить его без каких-либо последующих технических последствий. Стоимость ошибок понимания заключается в исправлении документации, а не в производственном инциденте.
Документирование бизнес-правил. Большая языковая модель, представленная блоком COBOL EVALUATE, потенциально содержащая сотни условий WHEN, накопленных за десятилетия изменений в законодательстве, может создать структурированное описание того, что каждое условие означает с точки зрения бизнеса. Для программ, где исходная документация больше не существует или никогда не существовала, это действительно ценно. В программе COBOL, реализующей логику расчета налогов в 63 юрисдикциях, эти правила для юрисдикций закодированы в структуре EVALUATE; ИИ может извлекать и документировать их быстрее, чем любой ручной процесс. Полученные результаты должны быть проверены экспертом в предметной области, но эксперт проверяет результаты работы ИИ, а не восстанавливает знания с нуля, что является гораздо более быстрым процессом.
Вот как выглядит понимание искусственного интеллекта на практике. Рассмотрим следующий исходный код на языке COBOL:
кобол
EVALUATE TRUE
WHEN CUST-COUNTRY = 'US' AND CUST-STATE = 'CA'
COMPUTE TAX-AMT = GROSS-AMT * 0.0725
WHEN CUST-COUNTRY = 'US' AND CUST-STATE = 'TX'
COMPUTE TAX-AMT = GROSS-AMT * 0.0825
WHEN CUST-COUNTRY = 'UK'
COMPUTE TAX-AMT = GROSS-AMT * 0.20
WHEN CUST-COUNTRY = 'DE'
COMPUTE TAX-AMT = GROSS-AMT * 0.19
WHEN OTHER
MOVE ZERO TO TAX-AMT
END-EVALUATE.
Грамотно подготовленная магистерская программа (LLM) дает следующие результаты:
Business Rule: Tax Calculation
This paragraph applies jurisdiction-specific tax rates to GROSS-AMT:
- US/California: 7.25% (CA state sales tax)
- US/Texas: 8.25% (TX state sales tax)
- United Kingdom: 20% (UK VAT standard rate)
- Germany: 19% (DE MwSt standard rate)
- All other countries: tax-exempt (TAX-AMT = 0)
Note: No rate exists for other US states. Orders from NY, FL, IL
will be tax-exempt under current logic -- likely a gap requiring review.Полученные результаты действительно ценны: в них задокументированы четыре бизнес-правила, выявлен вероятный пробел (штаты США без явно указанных тарифов), и все это за несколько часов. Эксперт в данной области проверяет их, подтверждает наличие пробела и добавляет в тестовые примеры. Задача по пониманию выполнена правильно.
Описание зависимостей. Инструменты статического анализа создают графы зависимостей, показывающие, какие программы вызывают какие процессы, какие файлы копибуков используются совместно, какие наборы данных передаются между программами. Искусственный интеллект может создать на основе этого графа описание на естественном языке: «Процесс CUSTPROC вызывается 14 программами, в основном в ночном пакетном окне. Он использует CUSTMSTR совместно с 47 программами и выводит данные в файл CUST-REPORT-FILE, который используется в процессе подготовки нормативной отчетности». Это описание более полезно для адаптации новых сотрудников и анализа архитектуры, чем один только граф зависимостей, и ИИ создает его за считанные секунды на основе структурированных данных о зависимостях.
Генерация тестовых примеров на основе изученного поведения. После того как ИИ задокументирует поведение программы, он может сгенерировать тестовые примеры, охватывающие задокументированные пути выполнения. Это не то же самое, что доказательство поведенческой эквивалентности: тестовые примеры охватывают пути, которые ИИ понял, и могут не охватывать пути, которые он не понял. Но охват 60 процентов путей выполнения с помощью тестов, сгенерированных ИИ, лучше, чем нулевой охват, который наблюдается во многих устаревших программах, и это обеспечивает отправную точку для ручного расширения тестов, необходимого для проверки поведенческой эквивалентности.
Распознавание закономерностей в схожих программах. Крупные портфели COBOL часто содержат множество программ, имеющих схожую структуру, один и тот же шаблон обработки, применяемый к различным сущностям, или один и тот же расчет нормативных требований, параметризованный по-разному. Искусственный интеллект может выявлять эти сходства в тысячах программ и группировать их по типу шаблона, что позволяет разработать стратегию миграции, которая обрабатывает каждый шаблон один раз и применяет решение систематически, а не рассматривает каждую программу как уникальную.
Общая черта: результаты работы ИИ по пониманию текста представляют собой текст, текст может быть проверен человеком, а проверка человеком выявляет ошибки до того, как они приведут к техническим последствиям. Профиль риска, связанный с пониманием текста ИИ, достаточно низок, чтобы предоставляемая им ценность была подлинной, а допускаемые ошибки — управляемыми.
Где перевод с помощью ИИ дает завышенные обещания
Перевод обладает особенностью, которая делает его принципиально сложнее для ИИ, чем понимание текста: результатом является исполняемый код, и исполняемый код должен быть абсолютно точным. Перевод с точностью до 95 процентов приводит к созданию программы, которая не работает для 5 процентов входных данных, что в системе обработки финансовых транзакций может представлять собой ошибку в отчетности перед регулирующими органами, несоответствие в расчете баланса или нарушение требований соответствия. Стоимость ошибок перевода заключается не в исправлении документации, а в производственном инциденте.
Ошибка в точности численных расчетов. В COBOL используется упакованная десятичная арифметика (COMP-3), которая выдает точные десятичные результаты. В Java же... double и Python float Используется двоичная система с плавающей запятой IEEE 754, которая не может точно представлять большинство десятичных дробей. Программа на COBOL, которая вычисляет... 0.1 + 0.2 с помощью COMP-3 получается точно 0.3Аналогичный расчет в Java с double производит 0.30000000000000004Для финансового учреждения, где этот расчет выполняется 10 миллионов раз за ночь при подготовке нормативной отчетности, накопленная ошибка — это не просто странность, связанная с числами с плавающей запятой, а несоответствие в финансовой отчетности. ИИ-переводчик, генерирующий Java-код без явной обработки сопоставления COMP-3 с BigDecimal, систематически вносит эту ошибку, и делает это для каждого поля, которое ИИ переводит. double , а не BigDecimal.
Разница в коде незначительна; последствия очевидны:
кобол
* COBOL: COMP-3 packed decimal -- exact arithmetic
77 UNIT-PRICE PIC S9(7)V99 COMP-3.
77 QUANTITY PIC S9(5) COMP-3.
77 LINE-TOTAL PIC S9(11)V99 COMP-3.
COMPUTE LINE-TOTAL = UNIT-PRICE * QUANTITY.
* UNIT-PRICE = 19.99, QUANTITY = 3
* LINE-TOTAL = exactly 59.97 -- no rounding error
Ява
// Java: naive AI translation uses double -- introduces error
double unitPrice = 19.99;
int quantity = 3;
double lineTotal = unitPrice * quantity;
// lineTotal = 59.96999999999999... not 59.97
// Correct translation requires BigDecimal:
// BigDecimal lineTotal = new BigDecimal("19.99").multiply(new BigDecimal(3));В одной транзакции ошибка незаметна. В 10 миллионах ночных транзакций, суммированных в отчете о регулятивном капитале, это существенное расхождение. Перевод с помощью ИИ, который явно не учитывает поля COMP-3, будет производить эту замену каждый раз.
Зависимость от параметров компилятора. Идентичный исходный код COBOL может демонстрировать различное поведение при использовании разных параметров компилятора. NUMPROC(MIG) против NUMPROC(NOPFD) изменяет способ обработки числовых исключений. Параметры RMODE, AMODE и DATA влияют на адресацию. Искусственный интеллект, который переводит исходный код COBOL, не зная, какие параметры компилятора использовались, переводит исходный код программы, а не её поведение. Переведённый код Java может соответствовать исходному коду, но не поведению в производственной среде.
Проблема ложных срабатываний в масштабе. Исследования показывают, что модели класса GPT-4 демонстрируют от 33 до 60 процентов ложных срабатываний в задачах общего перевода кода, генерируя правдоподобно выглядящий код, который добавляет или удаляет поведение, отсутствующее в исходном коде. Для программы с 847 условиями EVALUATE 5-процентный уровень ложных срабатываний означает, что примерно 42 условия переведены неправильно. Эти 42 условия представляют собой бизнес-правила, которые перевод незаметно нарушил. Без полного тестового корпуса, проверяющего каждое условие, эти нарушения остаются незамеченными до тех пор, пока конкретная комбинация входных данных, которая их вызывает, не попадет в рабочую среду.
На кону стоят цифры:
Error Type | Detection Point | Cost Range
--------------------|--------------------|------------------
Comprehension error | Human review | Hours to fix
Translation error | Test suite | Days to isolate
Translation error | Production | $10K-$500K+ incident
Equivalence gap | Regulatory audit | $50K-$5M+ penaltyАсимметрия: ошибки понимания выявляются до того, как они повлекут за собой технические последствия. Ошибки перевода проходят проверку и приводят к проблемам в процессе производства или, что еще хуже, при подаче документов в регулирующие органы.
Ограничение контекстного окна. IBM watsonx Code Assistant for Z обеспечивает структурную точность преобразования COBOL в Java на уровне 80% и выше для отдельных программ в рамках контекстного окна. Портфель COBOL-кода, состоящий из 5 миллионов строк, включает тысячи программ с межпрограммными зависимостями, которые охватывают программы, не способные одновременно находиться в одном контекстном окне. Программа, вызывающая подпрограмму, интерфейс которой, по мнению ИИ, отличается от предположений вызывающей программы, создает несоответствие интерфейса, которое не было бы выявлено ни одним из вариантов преобразования по отдельности. Для преобразования в масштабе портфеля требуется понимание взаимодействия между программами, а не только внутри них.
Проблема контекстно-свободного перевода. Программа на COBOL, обрабатывающая конкретное бизнес-событие, делает это с учетом контекста, заложенного в окружающей ее системе, расписания пакетной обработки, определяющего время ее выполнения, наборов данных, которые должны быть доступны при запуске, порядка обработки записей, а также последующих программ, считывающих ее выходные данные перед запуском. Искусственный интеллект, переводящий программу без понимания этого контекста, переводит исходный код, но не саму роль. Переведенный код на Java может быть внутренне корректным, но при этом давать сбои в работе, поскольку он запускается в неправильное время, в неправильном порядке и без необходимых данных, на которые опирался его предшественник COBOL.
Разрыв в поведенческой эквивалентности
Наиболее существенная проблема, которую не решают ни системы искусственного интеллекта для понимания, ни системы искусственного интеллекта для перевода, — это доказательство поведенческой эквивалентности, то есть демонстрация того, что модернизированная система выдает те же результаты, что и устаревшая система, для всех входных данных, имеющих значение для бизнеса и регулирующих органов.
Эквивалентность поведения — это не проблема тестирования в стандартном смысле. Это не вопрос «проходит ли новая система набор тестов?», поскольку набор тестов для устаревшей системы COBOL часто отсутствует или охватывает лишь часть путей выполнения программы. Это вопрос: для каждого входного параметра, когда-либо получавшегося производственной системой, выдает ли модернизированная система тот же результат? И для каждого входного параметра, который производственная система может получить в будущем, включая крайние случаи, возникающие только при редких рыночных условиях, периодах отчетности перед регулирующими органами или в конкретных обстоятельствах, связанных с клиентами, выдает ли модернизированная система эквивалентный результат?
Для ответа на этот вопрос необходимы: характеристика поведения существующей системы, полученная на основе фактического выполнения в производственной среде (а не из документации и не только из исходного кода), тестовый корпус, проверяющий весь спектр этого поведения, и система сравнения, способная определить, что означает «эквивалентность» для выходных данных, где представление различается (EBCDIC против UTF-8, упакованное десятичное число против BigDecimal, пакетный файл против записи в базе данных).
Ничего из этого не предоставляют инструменты перевода на основе ИИ. Оценка IBM однозначна: перевод практически не отражает реальной сложности модернизации. Работа по поведенческой эквивалентности, параллельное выполнение, структура согласования, утверждение регулирующими органами — вот где концентрируются затраты и риски, и именно здесь ИИ оказывает наименьшее влияние на общую стоимость программы. ИИ сжимает начальный этап проекта модернизации: понимание и первоначальный перевод. Он не сжимает заключительный этап: проверку, тестирование на эквивалентность и параллельную валидацию.
Правильная модель: основа статического анализа, семантический слой ИИ.
Наиболее эффективная способность ИИ к пониманию заключается не только в самом ИИ, но и в его работе на структурном фундаменте, который обеспечивает статический анализ. Ограничения понимания ИИ (ограничения контекстного окна, иллюзии сложной межпрограммной логики, вероятностный, а не детерминированный анализ) преодолеваются статическим анализом. Ограничения статического анализа (он создает структурные факты, но не семантические описания) преодолеваются ИИ.
Правильное разделение труда: статический анализ обеспечивает структурную определенность (детерминированность, полноту, отсутствие иллюзий). Искусственный интеллект обеспечивает семантическую насыщенность (описания на естественном языке, распознавание образов, генерация тестов). Ни один из них сам по себе недостаточен. Вместе они обеспечивают полное понимание.
Структурную основу, которую обеспечивает статический анализ:
Полный перечень программ. Каждая программа в портфеле, включая программы, которые не были учтены в документации, и программы, которые контекстное окно ИИ никогда не сможет обработать одновременно. Статический анализ обрабатывает весь портфель без ограничений по контексту.
Точный граф зависимостей. Каждая связь CALL, каждая связь COPY, каждый поток данных между программами должны быть детерминированы из источника, а не вероятностно выведены из обучающих данных. Когда инструмент искусственного интеллекта описывает зависимости программы, это описание должно основываться на графе зависимостей, полученном в результате статического анализа, а не на вероятностном представлении ИИ о том, от чего обычно зависят программы.
Идентификация мертвого кода. Программы, недоступные из любого пути выполнения в производственной среде, не входят в область модернизации. Статический анализ позволяет с уверенностью их идентифицировать; ИИ не может этого сделать, поскольку у ИИ нет трассировок выполнения во время выполнения, необходимых для различения рабочего кода от мертвого кода только с помощью статического анализа.
Инвентаризация схемы данных. Каждая запись FD, каждая книга копибуков, каждое поле COMP-3 с указанием точности, извлеченные из исходных артефактов, а не реконструированные из памяти ИИ, содержащей информацию о том, как обычно выглядят определения полей COBOL.
Поверх этой структурной основы, понимание ИИ добавляет семантический слой: описания того, что делает каждая программа, на естественном языке, документацию по бизнес-правилам, повествование о потоках данных между программами, распознавание образов, которое группирует похожие программы. Эта комбинация — детерминированная структурная точность, полученная в результате статического анализа, и семантическое богатство естественного языка, обеспечиваемое ИИ, — представляет собой модель, которая выдает результаты понимания, на которые команда по модернизации может действительно полагаться.
Что это значит для вашей программы модернизации?
Практическое распределение инвестиций в ИИ на основе данного анализа:
Инвестируйте в понимание ИИ. Генерация документации, извлечение бизнес-правил, описание зависимостей, генерация тестовых примеров на основе задокументированного поведения — это высокоэффективные и низкорисковые способы применения ИИ, которые сокращают самый дорогостоящий традиционно ручной этап модернизации. Делайте это в первую очередь, до перевода, потому что понимание влияет на каждое последующее решение.
Используйте ИИ-перевод как генератор черновиков, а не как финальный вариант. ИИ-перевод создает исходный код на Java или Python, который разработчик проверяет, исправляет и подтверждает корректность, а не готовый к использованию код, который можно развернуть без проверки человеком. Обработка результатов ИИ-перевода как черновика снижает стоимость перевода, сохраняя при этом человеческую ответственность, необходимую для проверки эквивалентности.
Не учитывайте экономию на переводе, достигаемую с помощью ИИ, в счет затрат на проверку. ИИ сокращает время, необходимое для создания переведенной программы. Он не сокращает время, необходимое для доказательства эквивалентности переведенной программы оригиналу. Планируйте бюджет этапа проверки независимо от экономии на переводе, достигаемой с помощью ИИ, поскольку объем проверки не уменьшается с увеличением скорости перевода.
Сначала создайте структурную основу. Инструменты анализа кода с помощью ИИ, которым не хватает структурной основы, точного графа зависимостей, полного перечня кода программы и схемы данных, дают неполные результаты там, где код наиболее сложен. Программы, которые больше всего нуждаются в анализе с помощью ИИ, как правило, самые сложные, наиболее зависимые от других программ и с наибольшей вероятностью превосходят возможности ИИ по точному анализу только исходного кода.
Как SMART TS XL Поддерживает улучшенное понимание кода COBOL с помощью ИИ.
SMART TS XL обеспечивает основу для структурного анализа, благодаря чему понимание портфелей COBOL искусственным интеллектом становится точным, а не вероятностным.
Функция статического анализа кода предоставляет структурные данные на уровне программы, необходимые инструментам понимания ИИ: перечисление каждого условия EVALUATE, извлечение каждой формулы COMPUTE, описание каждого шаблона доступа к данным. Когда инструменты документирования ИИ работают с исходным кодом, используя эти структурные данные в качестве контекста, они создают описания, основанные на том, что код фактически содержит, а не на том, что обычно делают похожие программы.
Отображение зависимостей приложений обеспечивает контекст между программами, который не может одновременно содержаться в контекстных окнах ИИ. Граф зависимостей, отображающий 14 вызывающих функций CUSTPROC, 47 функций обмена копибуками и 3 выходных потока данных, дает инструментам понимания ИИ полную картину роли программы в портфеле, не требуя, чтобы каждая зависимая программа находилась в одном и том же контекстном окне одновременно.
Анализ модернизации устаревшего кода позволяет получить перечень неиспользуемого кода и распределение сложности, которые невозможно надежно воспроизвести с помощью искусственного интеллекта: какие программы недоступны из производственной среды (исключены из области анализа), какие программы имеют наибольшую сложность (где ошибки при анализе кода обходятся дороже всего), и как выглядит область миграции данных, определяемая на основе фактических записей дескрипторов файлов, а не на основе документации.
Функция корпоративного поиска позволяет запрашивать данные из структурного каталога для поддержки понимания с помощью ИИ: находить каждую программу, реализующую определенный шаблон, каждый блок EVALUATE с более чем N условиями, каждую программу, обращающуюся к определенному набору данных, а также запросы, которые основывают понимание ИИ на структурных данных, а не на вероятности, полученной из обучающих данных.
Для организаций, где ИИ теперь является частью инструментария модернизации, SMART TS XLСтруктурный анализ — это тот уровень, который обеспечивает точность понимания ИИ в масштабе портфеля, устраняя ограничения контекстного окна, риск возникновения ошибок в межпрограммной логике и разрыв в детерминизме, отделяющий структурный анализ от вероятностной генерации.
Искусственный интеллект изменил стоимость понимания, а не стоимость доказательства.
В 2026 году изменилась стоимость понимания. Искусственный интеллект значительно удешевил и ускорил процесс понимания того, что делает программа на COBOL, документирования ее бизнес-правил, описания ее поведения и определения ее места в портфеле. Это подлинный и существенный вклад в экономику модернизации. Для программ, где ранее этап понимания требовал недель работы специалистов, ИИ может создать черновой вариант понимания за несколько часов, который специалисты проверяют и дорабатывают, вместо того чтобы создавать его с нуля.
Что не изменилось, так это стоимость подтверждения. Проверка поведенческой эквивалентности, параллельное выполнение, одобрение регулирующих органов, проверка миграции данных — все это остается на том же уровне, что и до появления ИИ, поглощая от 40 до 50 процентов бюджета модернизации независимо от скорости завершения этапов понимания и перевода. IBM была права 23 февраля 2026 года: перевод практически не отражает реальной сложности. Реальная сложность заключается в проверке поведенческой эквивалентности, и эта сложность не уменьшается с ускорением перевода.
Организации, эффективно использующие ИИ в модернизации COBOL, — это те, кто инвестирует в понимание ИИ там, где ИИ действительно превосходен, и рассматривает перевод с помощью ИИ как отправную точку для проверки человеком, а не как готовый продукт, готовый к внедрению. Они понимают, что удешевление начального этапа проекта не означает удешевление его конечного этапа. И они создают основу структурного анализа, необходимую для точного понимания ИИ на уровне портфеля проектов, где происходит наиболее важная работа по пониманию.
