Зміст
Корпоративна система віком десять–п’ятнадцять років — це не «старий код», а живий організм: мільйони рядків, сотні таблиць, десятки інтеграцій і знання, які ніколи не потрапили во внутрішню базу знань. Адаптація нового розробника в такому проєкті легко розтягується на місяці. Головне питання 2026 року: чи здатний сучасний ШІ побудувати карту системи швидше за людину — і де проходить межа його можливостей?
Ключові висновки
Технічна спадщина — це не вік фреймворку, а накопичена складність. П’ятнадцятирічний проєкт — кілька поколінь технологій, застаріла документація і бізнес-логіка, вшита в 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 і експорт внутрішньої бази знань.
Які дані може аналізувати ШІ
| Джерело | Що дає моделі |
|---|---|
| Вихідний код | Логіка, залежності, API |
| SQL-схеми та міграції | Модель даних, еволюція таблиць |
| OpenAPI, WSDL, protobuf | Контракти інтеграцій |
| Документація (навіть застаріла) | Наміри та глосарій |
| Історія комітів | Хто змінював, коли, навіщо (якщо повідомлення коміту чесне) |
| Логи, конфіги, прапорці функцій | Реальна поведінка в середовищах |
Чим більше джерел пов’язано в одному контурі (індекс + RAG), тим менше модель додумує. Окремо код без схеми БД — типове джерело помилок: ШІ знайде сутність Order, але не побачить тригер у PostgreSQL.
Як ШІ будує картину проєкту
Типовий конвеєр аналізу: спочатку граф залежностей (імпорти, виклики між пакетами, HTTP-клієнти); потім сутності предметної області (замовлення, контрагент, накладна); далі сценарії («створення замовлення → резерв → оплата → відвантаження»); нарешті точки інтеграції (зовнішні URL, топики Kafka, каталоги SFTP).
Агент не «запам’ятовує весь проєкт», а ходить по ньому запитами: «де оновлюється status у таблиці shipments», «хто викликає LegacyBillingAdapter».
Експеримент: дати ШІ проєкт віком 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 %, але знімає 80 % рутини.
Генерація документації
З коду можна зібрати опис модулів, OpenAPI там, де його не було, діаграми компонентів, глосарій сутностей. Команди на вебінарі Platform9 і Monday.com називають живу документацію репозиторію одним із перших джерел окупності від ШІ.
Швидка адаптація нових розробників
Нова людина ставить у чат з RAG: «як у нас влаштоване скасування замовлення», «чому два PaymentService». Відповіді з посиланнями на файли скорочують час до першого коміту.
Обмеження штучного інтелекту
Обмеження контексту
Навіть мільйон токенів — не 2,8 млн рядків. Потрібні індексація, розбиття на фрагменти, ієрархічні зведення по модулях.
Відсутність бізнес-контексту
Код показує що; рідко чому. «Тимчасовий» обхід обмеження API банку 2017 року виглядає як безглуздий if — поки не розповість архітектор.
Галюцинації та помилки інтерпретації
Модель може впевнено назвати неіснуючу кінцеву точку API, переплутати v1 і v2 API. Правило: будь-який висновок ШІ для бойових рішень перевіряється посиланням на файл і рядок або запуском тесту.
Як компанії впроваджують ШІ для роботи з успадкованими системами
Індексація репозиторію
Мінімальний контур: код (усі релевантні репо, включно з SQL і інфраструктурою), схема БД (DDL, міграції Flyway/Liquibase), документація (експорт внутрішньої бази знань, ADR, README). Оновлення індексу — за вебхуком при злитті в основну гілку, не раз на рік.
Для секретів: індекс без .env, ключів, персональних даних; політика в корпоративних AI-контурах — окрема тема.
Створення внутрішньої бази знань
Граф залежностей + семантичний пошук. Вікі стає вторинним шаром: генерується з коду, рев’юється, версіонується поруч із репо.
Використання RAG-підходу
Звичайний ChatGPT не бачить ваш git. RAG підтягує актуальні фрагменти за запитом: клас, міграція, сторінка вікі. Без RAG відповіді — усереднений форум Stack Overflow; з RAG — «у вашому InvoiceService.java рядок 142».
Чому чату недостатньо: успадкований код вимагає точності і посилань на джерело. RAG + інструменти агента — стандарт 2026 для внутрішніх систем.
Автоматичне оновлення знань
При злитті в основну гілку — переіндексація модулів, зведення змін для архітектурної карти. Документація перестає бути знімком 2019 року.
Чи може ШІ замінити досвідченого розробника
Що ШІ вже вміє краще за людину
Швидкість пошуку, паралельний обхід модулів, чернетки діаграм і таблиць залежностей — за умови індексу.
Що поки залишається задачею людини
Архітектурні рішення — компроміси на десятиліття. Бізнес-процеси, оцінка ризиків, комунікація з замовником.
Оптимальна модель роботи
Розробник / архітектор — експерт і фінальний фільтр. ШІ — аналітик і навігатор. Так само, як сильні команди вибудовують життєвий цикл розробки навколо агентів.
Майбутнє: як зміниться супровід старих проєктів
Самодокументовані системи
Документація генерується з основної гілки; розбіжність вікі і коду стає помилкою CI.
Цифрові архітектурні помічники
Внутрішній асистент відповідає на питання про наслідки змін і технічний борг. Зв’язка з моніторингом і тикетами дасть контекст інцидентів.
Що чекає проєкти з длинною історією через 5 років
Адаптація — тижні замість місяців. Супровід — менша залежність від «єдиного, хто пам’ятає». Розвиток — більше ресурсів на продукт, менше на «археологію коду». Успадковані системи не зникнуть — вони довше еволюціонуватимуть, рідше переписуватимуться з нуля — якщо архітектура терпить зміни.
Часті питання
Чи може ChatGPT «прочитати» весь наш репозиторій за один раз?
Ні. Потрібна індексація, RAG або агент з пошуком по файлах. Завантаження архіву у веб-чат — лише для маленьких проєктів.
Скільки часу економить ШІ на адаптації нового розробника?
Первинна карта системи стискається з тижнів до днів; повне володіння контекстом — як і раніше місяцями, але продуктивна робота починається раніше.
Чи небезпечні галюцинації для успадкованого коду?
Так. Вимагайте посилань на файли, рев’ю людиною і тести на критичних шляхах.
Чи потрібен окремий RAG, якщо є Cursor?
Для одного розробника в IDE часто достатньо. Для всієї команди і відповідності вимогам — централізований корпоративний контур.
Чи може ШІ замінити архітектора на проєкті з довгою історією?
Ні. Він прискорює збір фактів; рішення залишаються за людиною з відповідальністю перед бізнесом.
Що індексувати в першу чергу?
Основну гілку бойових репозиторіїв, DDL і міграції БД, OpenAPI/контракти, ADR і інструкції з експлуатації.
Як перевірити, що ШІ не вигадав залежність?
Відкрити файл, знайти символ по коду, прогнати тест. Для сумнівних місць — друга думка моделі або колеги.
Чи підходить це для держсектору та банків?
Так, при розміщенні на власній інфраструктурі або в приватній хмарі, без витоку коду у зовнішні SaaS без договору.
Читати далі
Ця стаття — опорний матеріал кластера про успадкований код і ШІ:
Висновок
Чи може ШІ розібратися в проєкті з 15-річною історією? — Так, у значній частині і швидше за людину на етапі первинної розвідки — за умови індексації та агентних інструментів.
Межа сьогодні — неформальний контекст, «чому так зроблено», повнота залежностей при динамічному коді і відповідальність за бойове середовище.
Майбутнє — зв’язка експерт + ШІ. Практичний крок на цей тиждень: проіндексувати основну гілку, підключити IDE-агент або RAG і провести контрольний експеримент — три типових питання новачка з перевіркою відповідей досвідченим розробником.