Как LLM снижает стоимость модернизации legacy-систем в госсекторе: COBOL, его российские аналоги и практический план миграции

800 млрд строк кода, которые никто не помнит

По оценкам отрасли, COBOL обрабатывает около 95% транзакций через банкоматы в США. Сотни миллиардов строк COBOL-кода работают в продакшене каждый день — финансы, авиация, государственные системы. Разработчиков, которые писали эти системы, давно нет в штате. Документация отстала от кода на десятилетия.

В России ситуация другая по стеку, но идентичная по сути. Критические госсистемы работают на PL/I, Natural/ADABAS, кастомных 4GL-средах и ранних версиях C/C++ с процедурной архитектурой 1980–1990-х. Налоговые системы ФНС, расчётные модули СФР (бывший ПФР), ядро АБС крупных банков — всё это legacy с возрастом 20–35 лет.

Проблема не в языке. Проблема в утраченном знании: бизнес-логика закодирована в миллионах строк, которые никто не может прочитать целиком. Любая попытка модернизации начиналась с найма десятков консультантов на годы reverse engineering. Стоимость такого подхода делала проекты экономически нецелесообразными.

LLM-инструменты меняют эту экономику кардинально.

---

Почему legacy в госсекторе — особый случай

Модернизация legacy-кода в госсистемах принципиально отличается от рефакторинга типового enterprise-приложения. Три фактора делают задачу сложнее.

Регуляторная нагрузка. Каждое изменение в системе ФНС или СФР затрагивает расчёты, привязанные к федеральному законодательству. Бизнес-логика — это не просто код, а закон в машинном виде. Ошибка при миграции — это не баг, а нарушение прав миллионов граждан.

Скрытые зависимости. Системы развивались 20–30 лет путём накопления: новые модули добавлялись поверх старых, связи между компонентами шли через файлы, глобальные структуры данных, промежуточные базы. Статический анализ не видит таких неявных связей — они проявляются только в рантайме.

Кадровый разрыв. Специалисты по Natural/ADABAS, PL/I, старым процедурным фреймворкам уходят на пенсию. Замены нет — эти технологии не преподают. Средний возраст инженера, способного сопровождать ядро типичной legacy-системы в крупном российском банке, — 55+ лет.

В такой ситуации классический подход «нанять армию консультантов, потратить 3 года на анализ, ещё 3 на переписывание» перестаёт работать. Не потому что денег нет — потому что людей нет.

---

Как LLM меняет экономику модернизации

LLM-инструменты автоматизируют именно те фазы, которые раньше съедали 60–70% бюджета: исследование кодовой базы, восстановление документации и анализ рисков.

Автоматическое исследование и картирование кода

LLM читает кодовую базу целиком и строит карту системы: точки входа, пути исполнения, вызовы подпрограмм, потоки данных между модулями, зависимости между сотнями файлов.

Критически важно — это не простой call graph. LLM выявляет неявные зависимости: общие структуры данных, файловые операции, создающие связность между модулями, последовательности инициализации, влияющие на поведение в рантайме. Именно эти скрытые связи делают миграцию рискованной, и именно их ручной анализ стоил месяцы работы консультантов.

На выходе — документация рабочих процессов. LLM трассирует движение данных от входа до выхода и генерирует описания пайплайнов обработки, которые никто не помнит, но от которых зависит вся система.

В нашей практике GovTech-проектов: то, что раньше занимало 4–6 месяцев работы аналитиков, с LLM-инструментами укладывается в 3–5 недель. С оговоркой — результат требует верификации инженером, знающим предметную область.

Анализ рисков и приоритизация

После картирования LLM оценивает, какие компоненты можно мигрировать безопасно, а какие требуют осторожности:

• Модули с высокой связностью — повышенный риск при миграции
• Изолированные компоненты — кандидаты на раннюю независимую модернизацию
• Дублированная логика — возможности для рефакторинга
• Участки с накопленным техдолгом — фиксируются до начала миграции, а не в процессе

Для госсистем добавляется ещё один слой анализа: регуляторная карта. Какие модули реализуют нормы конкретных ФЗ и постановлений, какие расчёты привязаны к датам вступления законов в силу, где заложены переходные периоды. LLM способен извлечь эту информацию из кода и комментариев, но верификация — только с юристами и предметными экспертами.

Инкрементальная реализация с непрерывной проверкой

Миграция идёт по одному компоненту за раз. LLM транслирует логику в целевой язык, создаёт API-обёртки вокруг legacy-компонентов, которые остаются на месте, и выстраивает инфраструктуру для параллельной работы старого и нового кода.

Каждый шаг — либо проходит валидацию и фиксируется, либо откатывается, пока объём изменений мал. Никогда не бывает ситуации, когда в работе массив изменений на недели, и откат означает потерю месяцев.

---

Российский контекст: где именно это применимо

ФНС и налоговые системы

Ядро АИС «Налог-3» и смежных систем содержит модули, написанные в 1990–2000-х. Расчётная логика привязана к Налоговому кодексу, и каждое изменение НК порождает патчи поверх патчей. LLM-анализ позволяет:

• Восстановить карту соответствия «модуль кода → статья НК»
• Выявить мёртвый код от отменённых норм (по нашим оценкам, до 15–25% кодовой базы в типичной legacy-системе такого класса)
• Обнаружить дублирование расчётов между подсистемами

СФР (бывший ПФР) и социальные расчёты

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

Банковский сектор

АБС крупных банков — классический legacy. Ядро расчёта процентов, комиссий, операционного дня часто написано на C, PL/SQL или проприетарных языках 1990-х. Банки уже инвестируют в модернизацию, но часто идут путём полной замены — дорого и рискованно. LLM-подход с инкрементальной миграцией снижает риск: старая и новая система работают параллельно, результаты сверяются автоматически.

---

Сравнение подходов: цифры, которые меняют решение

Параметр	Классический подход	LLM-assisted подход
Фаза анализа	6–12 месяцев	1–2 месяца
Стоимость анализа	15–40 млн ₽	3–8 млн ₽
Документирование	Ручное, неполное	Автоматическое + ручная верификация
Скрытые зависимости	Выявляются в процессе (поздно)	Выявляются до начала миграции
Риск при миграции	Высокий	Управляемый
Legacy-эксперты	5–10 специалистов	1–2 для верификации

Цифры — оценки на основе опыта GovTech-проектов и открытых данных по стоимости legacy-модернизации в банковском секторе РФ.

---

Практический план: что делать прямо сейчас

Шаг 1. LLM-аудит кодовой базы (2–4 недели)

Выберите один ограниченный контур системы — модуль расчёта конкретного налога или одну подсистему АБС. Запустите LLM-анализ:

• Картирование зависимостей и потоков данных
• Генерация документации на естественном языке
• Выявление мёртвого кода и дублирования
• Оценка связности модулей

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

Шаг 2. Регуляторная карта (1–2 недели)

Совместно с юристами и предметными экспертами сопоставьте модули кода с нормативными актами. Зафиксируйте, какие расчёты привязаны к каким ФЗ и постановлениям. Это критический артефакт для любой миграции в госсекторе.

Шаг 3. Пилотная миграция одного компонента (4–8 недель)

Выберите компонент с чёткими границами и средней сложностью. Полный цикл:

1. LLM-анализ и документирование
2. Генерация тестов на соответствие
3. Трансляция в целевой язык
4. Параллельный запуск старого и нового кода
5. Сверка результатов на реальных данных

Шаг 4. Оценка и масштабирование

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

---

Ограничения: честный разговор

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

Галлюцинации — реальный риск. LLM может уверенно описать несуществующую зависимость или неверно интерпретировать фрагмент кода. Каждый результат анализа требует верификации. В контексте госсистем цена ошибки — не баг-репорт, а неправильно начисленные пенсии или налоги.

Проприетарные языки. LLM хорошо работает с COBOL — на нём обучалось достаточно данных. С российскими проприетарными средами ситуация хуже. Может потребоваться few-shot prompting с примерами из конкретной кодовой базы.

Сертификация и ИБ. В госсекторе РФ есть требования к сертификации средств разработки. Использование облачных LLM для анализа кода госсистем может быть ограничено. Варианты — on-premise развёртывание открытых моделей или работа с обезличенными фрагментами.

Не все системы стоит мигрировать. Если legacy стабильно работает, нагрузка не растёт, а бизнес-логика не меняется — стоимость миграции может не окупиться. LLM-аудит как раз помогает принять это решение на основе данных, а не интуиции.

---

Экономика изменилась

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

LLM не превращает модернизацию в тривиальную задачу. Но смещает основную стоимость с ручного анализа на экспертную верификацию. Это принципиально другая экономика: вместо 10 legacy-инженеров на 2 года — 2 эксперта на 6 месяцев при поддержке LLM-инструментов.

Начните с аудита. Возьмите ограниченный контур, запустите LLM-анализ, оцените качество результатов на вашей кодовой базе. Минимальное вложение даст данные для принятия решения — мигрировать, модернизировать частично или оставить как есть.

Мы в VibeLab помогаем с аудитами и пилотными миграциями для госсектора и enterprise. Если у вас legacy-система, которая давно просится на модернизацию — обсудим конкретику по вашему случаю.