Систему нельзя переписать заново, но можно понять и перенести по частям

Начинать нужно не с выбора новой технологии, а с карты системы: какие модули существуют, кто ими пользуется, какие процессы они обслуживают и как связаны между собой. В унаследованных системах связи часто неочевидны: модуль, который считался второстепенным, может оказаться точкой, через которую проходит половина операций. Языковые модели здесь помогают быстро получить черновик описания каждого модуля, который затем проверяют инженеры и эксперты предметной области.

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

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

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

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

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

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

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

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