Ключевые выводы

Техническое наследие — это не возраст фреймворка, а накопленная сложность. Пятнадцатилетний проект — это несколько поколений технологий, устаревшая документация и бизнес-логика, вшитая в SQL и задачи по расписанию. Проблема не в том, что «написано на Java 8», а в том, что изменение одного поля может затронуть пять интеграций.

ИИ за часы даёт то, на что у человека уходят недели — но только при правильной подготовке данных. Без индексации репозитория, схемы БД и истории коммитов модель видит фрагменты и достраивает остальное из общих паттернов. С RAG, семантическим поиском и агентными инструментами (Cursor, Claude Code, Windsurf Deep Wiki) картина складывается на порядок быстрее.

Сильные стороны ИИ — поиск, анализ влияния изменений и документация. Где считается стоимость, кто меняет статус документа, какие модули читают таблицу orders_legacy — такие вопросы модель закрывает за минуты, если репозиторий доступен.

Слабые стороны — «почему так решили» и слепое доверие. ИИ не был на совещании в 2014 году, не знает про договор с банком и может уверенно описать несуществующий API. Галлюцинации опасны именно потому, что звучат правдоподобно.

Оптимальная модель — эксперт + ИИ. Разработчик или архитектор задаёт рамки, проверяет выводы и принимает решения; модель — аналитик, который не устаёт читать три миллиона строк.

Введение: почему унаследованные системы остаются главной болью

Большинство компаний не переписывают системы каждые пять лет. Они развивают их: добавляют модули, прикручивают интеграции, меняют процессы под регуляторику. ERP в ритейле, CRM в B2B, банковский учёт, госсистемы — всё это живёт десятилетиями. Бизнес зависит от них ежедневно; простой стоит дороже, чем год сопровождения.

Типичный «зрелый» корпоративный проект выглядит так: 1,5–4 млн строк кода, 8–15 тыс. файлов, 200–600 таблиц в основной БД плюс отдельные хранилища отчётности, 20–40 внешних интеграций (банки, ЭДО, маркетплейсы, 1С, шина данных). Команда менялась пять–десять раз; часть авторов уже не на связи.

Введение нового человека в такую систему — это не «прочитай стартовую документацию». Это месяцы чтения кода, расспросов коллег, разбора инцидентов и постепенного понимания, где правда в коде, а где только в голове у двух людей. Руководство закономерно спрашивает: можно ли поручить первичный разбор ИИ?

Ответ 2026 года — да, частично и при условиях. Но не «загрузить архив в ChatGPT и получить архитектуру». Нужен процесс: индексация, инструменты с доступом к репозиторию, проверка человеком. Ниже — что именно понимает модель, где ошибается и как это внедряют на практике.

Что представляет собой типичный проект с 15-летней историей

Техническое наследие разных эпох

За пятнадцать лет через один репозиторий (или семейство репозиториев) проходят несколько волн технологий. В начале — монолит на Java или .NET, JSP или WebForms, хранимые процедуры. Потом — REST-сервисы, фронт на Angular или React, отдельный сервис отчётности. Где-то «временный» Python-скрипт для выгрузки в Excel до сих пор в проде. Микросервисы выделяли частично: три новых сервиса рядом с ядром, которое никто не решается трогать.

Следы множества команд видны в стиле кода, именовании, комментариях на разных языках и слоях абстракции, которые друг друга дублируют. «Старые» модули часто работают стабильнее «новых» — потому что их уже десять лет чинят по краям.

Отсутствие актуальной документации

Страница корпоративной вики «Архитектура v3» датирована 2019 годом и описывает систему до миграции на Kafka. Swagger есть только у новых API; старые обмениваются XML по схеме, которую знает один интегратор. Реальное поведение часто отличается от описанного: флаг в конфиге, задача по расписанию в 02:00, ручной шаг оператора.

Часть знаний — только в головах: «не трогай эту таблицу до закрытия месяца», «эта конечная точка API устарела, но банк всё ещё бьёт в неё». Такие правила редко попадают в git.

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

Сложные бизнес-процессы

ERP, CRM, учёт в банке и госсекторе — не типовые CRUD-приложения. Накоплена бизнес-логика: согласования, лимиты, налоговые правила, статусы документов, многоэтапные заказы. Ошибка — не баг в интерфейсе, а штраф, блокировка счёта или отказ регулятора.

Высокая стоимость ошибок меняет правила игры: «быстро нагенерировать патч» недостаточно. Нужно понимать последствия. ИИ помогает найти, где считается сумма; человек решает, можно ли менять формулу до релиза.

Связанные материалы: почему ERP превращаются в монолиты, как проектировать систему на десятилетие.

Как современные ИИ-модели анализируют код

Что изменилось за последние годы

Три сдвига сделали анализ унаследованного кода реалистичным.

Контекстное окно выросло с тысяч до сотен тысяч и миллионов токенов. Целиком «прочитать» репозиторий всё равно нельзя, но в одну сессию помещается целый модуль, схема БД или цепочка вызовов.

Понимание кода у специализированных моделей (Claude, GPT-4o, Gemini, Codestral и др.) стало достаточным для трассировки зависимостей, объяснения SQL и сопоставления DTO с таблицами — не идеально, но на уровне разработчика среднего уровня на первом проходе.

Инструменты для репозиториев вышли за рамки чата: Cursor и Claude Code индексируют проект, ходят по файлам, ищут по коду, смотрят историю авторства; Windsurf Deep Wiki строит живую вики; корпоративные решения на базе RAG подключают GitLab, Jira и экспорт внутренней базы знаний.

Какие данные может анализировать ИИ

Чем больше источников связано в одном контуре (индекс + RAG), тем меньше модель додумывает. Отдельно код без схемы БД — типичный источник ошибок: ИИ найдёт сущность Order, но не увидит триггер в PostgreSQL.

Как ИИ строит картину проекта

Типичный конвейер анализа выглядит так. Сначала граф зависимостей: импорты, вызовы между пакетами, HTTP-клиенты к другим сервисам. Затем сущности предметной области: заказ, контрагент, накладная — по моделям, таблицам и REST-путям. Дальше сценарии: «создание заказа → резерв → оплата → отгрузка» как цепочка классов и очередей. Наконец точки интеграции: внешние URL, топики Kafka, каталоги SFTP.

Агент не «запоминает весь проект», а ходит по нему запросами: «где обновляется status в таблице shipments», «кто вызывает LegacyBillingAdapter». Это ближе к работе опытного разработчика с поиском по репозиторию и IDE, чем к магии.

Эксперимент: дать ИИ проект возрастом 15 лет

Ниже — реконструкция типичного сценария на основе реального класса систем (оптовая ERP, монолит + несколько сервисов). Цифры усреднённые; ваш проект может отличаться, но порядок величин узнаваем.

Исходные условия

• ~2,8 млн строк Java, Kotlin, SQL, JavaScript, XML конфигов
• ~11 400 файлов в основном монорепозитории + 4 дополнительных репозитория
• ~380 таблиц в Oracle (ядро) + 90 в PostgreSQL (отчёты)
• 34 интеграции: банки, ЭДО, маркетплейсы, 1С, SMS, таможня
• Документация: ~40 % модулей без актуального описания; вики частично противоречит коду

ИИ-контур: индексация репозитория, доступ к дампу DDL (без персональных данных), git только для чтения, агент в IDE. Без доступа к боевым логам и без «устных историй» от команды.

Что ИИ понимает за первые часы анализа

За 4–8 часов сессий (не один непрерывный прогон, а серия целевых запросов) модель с инструментами обычно выдаёт:

Архитектуру верхнего уровня: монолит core-app, вынесенные сервисы печати и уведомлений, ночная пакетная обработка в 01:00–04:00, шина для событий заказов.

Основные сущности: контрагент, договор, заказ, отгрузка, счёт-фактура, платёж — с привязкой к пакетам и таблицам.

Ключевые сценарии: оформление заказа, согласование скидки, резервирование склада, выставление счёта, сверка с банком — с указанием точек входа (REST, действие в интерфейсе, планировщик задач).

Точки интеграции: список адаптеров, URL, форматы, частые точки отказа (таймаут банка, повторные попытки в очереди).

Это быстрее, чем у нового опытного разработчика без таких инструментов: человек тратит время на навигацию и «где вообще искать».

Что человеку обычно требуется изучать неделями

Карта неочевидных зависимостей: «поле discount_reason влияет на налоговую строку через представление, о котором нет в Java-коде».

Неформальные правила: сезонные регламенты, договорённости с ключевым клиентом, «костыль» под один регион.

Качество и риски: какие модули без тестов, где последний раз был инцидент первого приоритета, кого звать при падении ночной пакетной обработки.

Политика изменений: что можно выкатывать в пятницу, что требует окна с администратором БД.

ИИ ускоряет первые 60–70 % карты, но не заменяет разговоры с командой и опыт инцидентов. Срок адаптации с «трёх месяцев до шести недель» при хорошем контуре — реалистичная цель; до «одной недели полного понимания» — нет.

Где ИИ показывает лучшие результаты

Поиск бизнес-логики

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

«Где согласуется документ» — цепочка движка согласований + таблица approval_steps + уведомления.

«Где меняется статус» — поиск по перечислению, обновление в преобразователе, обработчик события.

Человек тоже может, но за дни; ИИ — за минуты, если индекс актуален.

Анализ влияния изменений

Перед рефакторингом поля client_id или удалением таблицы нужен анализ влияния изменений. ИИ перечисляет: сущности JPA, отчёты, интеграционные DTO, хранимые процедуры, тесты. Не гарантирует 100 % (динамический SQL, reflection), но снимает 80 % рутины.

Особенно ценно перед миграцией БД или сменой типа поля: модель показывает, какие сервисы и задачи по расписанию читают колонку.

Генерация документации

Из кода можно собрать описание модулей, OpenAPI там, где его не было, диаграммы компонентов (Mermaid, PlantUML), глоссарий сущностей. Windsurf Deep Wiki и аналоги делают это полуавтоматически; команды на вебинаре Platform9 и Monday.com называют живую документацию репозитория одним из первых источников окупаемости от ИИ.

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

Быстрая адаптация новых разработчиков

Новый человек задаёт в чат с RAG: «как у нас устроена отмена заказа», «почему два PaymentService», «куда смотреть логи интеграции с банком X». Ответы с ссылками на файлы сокращают время до первого коммита.

Это не замена ментору, а сжатие первых недель блуждания по репозиторию.

Ограничения искусственного интеллекта

Ограничения контекста

Даже миллион токенов — не 2,8 млн строк. Нужны индексация, разбиение на фрагменты, иерархические сводки по модулям. Без этого модель видит кусок и достраивает картину по шаблону.

Старый код с копипастой и магическими строками увеличивает шум: ИИ может «объединить» два похожих класса в один в воображении.

Отсутствие бизнес-контекста

Код показывает что; редко почему. «Временный» обход ограничения API банка 2017 года выглядит как бессмысленный if — пока не расскажет архитектор.

Исторические ограничения (лицензия, железо, договор SLA) в git не лежат. ADR помогают, если их писали; в унаследованных проектах — часто нет.

Галлюцинации и ошибки интерпретации

Модель может уверенно назвать несуществующую конечную точку API, перепутать v1 и v2 API, пропустить вызов через reflection. Риск слепого доверия выше у менеджмента, чем у разработчиков — потому что ответ звучит структурированно.

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

Как компании внедряют ИИ для работы с унаследованными системами

Индексация репозитория

Минимальный контур: код (все релевантные репо, включая SQL и инфраструктуру), схема БД (DDL, миграции Flyway/Liquibase), документация (экспорт внутренней базы знаний, ADR, README). Обновление индекса — по вебхуку при слиянии в основную ветку, не раз в год.

Для секретов: индекс без .env, ключей, персональных данных; политика в корпоративных AI-контурах — отдельная тема.

Создание внутренней базы знаний

Граф зависимостей (модули, сервисы, таблицы) + семантический поиск («где упоминается лимит кредита»). Инструменты: корпоративный RAG (Azure AI Search, Elasticsearch + embeddings, локальные решения), IDE-агенты с индексом проекта.

Вики становится вторичным слоем: генерируется из кода, ревьюится, версионируется рядом с репо.

Использование RAG-подхода

Обычный ChatGPT не видит ваш git. RAG подтягивает актуальные фрагменты по запросу: класс, миграция, страница из вики. Без RAG ответы — усреднённый форум Stack Overflow; с RAG — «в вашем InvoiceService.java строка 142».

Почему чата недостаточно: унаследованный код требует точности и ссылок на источник. RAG + инструменты агента — стандарт 2026 для внутренних систем.

Автоматическое обновление знаний

При слиянии в основную ветку — переиндексация затронутых модулей, сводка изменений для архитектурной карты, опционально комментарий к PR «изменены потребители таблицы X». Документация перестаёт быть снимком 2019 года.

Может ли ИИ заменить опытного разработчика

Что ИИ уже умеет лучше человека

Скорость поиска по миллионам строк без усталости. Параллельный обход десятков модулей. Черновики диаграмм и таблиц зависимостей. Память на имена файлов и сигнатуры — при условии индекса.

Что пока остаётся задачей человека

Архитектурные решения: выделить сервис, менять границу домена, выбрать стратегию постепенного вытеснения монолита — это про компромиссы на десятилетие.

Бизнес-процессы: согласование с владельцем продукта, регуляторика, переговоры с интегратором.

Оценка рисков: «можно ли в пятницу», «нужен ли план отката», «кого предупредить».

Коммуникация: объяснить финансовому директору, почему рефакторинг займёт квартал, а не «ИИ сказал, что просто».

Оптимальная модель работы

Разработчик / архитектор — эксперт и финальный фильтр. ИИ — аналитик, технический писатель и навигатор. Ритуалы: вопрос → ответ с цитатами → проверка → решение → ADR. Так же, как сильные команды выстраивают жизненный цикл разработки вокруг агентов, а не «спросили ChatGPT и задеплоили».

Будущее: как изменится сопровождение старых проектов

Самодокументируемые системы

Документация генерируется из основной ветки и публикуется автоматически; расхождение вики и кода становится ошибкой CI. База знаний — живой артефакт, не PDF.

Цифровые архитектурные помощники

Внутренний ассистент отвечает: «что сломается, если удалим колонку», «какой технический долг в модуле billing», «кто последний менял интеграцию с банком Y». Связка с мониторингом и тикетами даст контекст инцидентов — то, чего сегодня нет в чистом RAG по коду.

Что ждёт проекты с длинной историей через 5 лет

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

Частые вопросы

Читать дальше

Эта статья — опорный материал кластера про унаследованный код и ИИ. Углубление:

• Как проектировать систему, которая проживёт 10 лет — почему связанность дороже «устаревшего» стека
• Почему ERP превращаются в монолиты — корень сложности, которую разбирает ИИ
• За хайпом: как команды внедряют ИИ в разработку — RAG, Deep Wiki, контекст для агентов
• Эволюция архитектуры веб-приложений — слои технологий в одном продукте
• Современный ERP: платформенный дизайн — куда двигать унаследованный код, а не только описывать его
• Безопасность AI-агентов в Docker — контур для корпоративного доступа к коду

Заключение

Может ли ИИ разобраться в проекте с 15-летней историей? — Да, в значительной части и быстрее человека на этапе первичной разведки. Архитектура, сущности, сценарии, интеграции, анализ влияния изменений и черновики документации — сильные стороны при индексации и агентных инструментах.

Граница сегодня — неформальный контекст, «почему так сделано», полнота зависимостей при динамическом коде и ответственность за боевую среду. Галлюцинации реальны; доверять без проверки нельзя.

Будущее — не замена разработчиков, а связка эксперт + ИИ: меньше месяцев на «археологию кода», больше на развитие продукта. Для компаний с унаследованными системами практический шаг на эту неделю — проиндексировать основную ветку, подключить IDE-агент или RAG и провести контрольный эксперимент: три типовых вопроса новичка («где статус заказа», «кто пишет в таблицу X», «какие сервисы зависят от адаптера Y») — с проверкой ответов опытным разработчиком. Разница во времени покажет окупаемость без презентаций про «трансформацию».