Автор 20-річної страхової платформи пропустив 108 тікетів підтримки через спеціально розроблений конвеєр ШІ-агентів, і результатом став робочий процес, який перетворює завдання для старшого розробника, що тривало кілька годин, на кілька хвилин — зсув, який може змінити підхід підприємств до підтримки застарілого коду.

Чому застарілі системи важливіші за новий код

Розглянута страхова програма — це моноліт із 2,3 мільйона рядків коду та приблизно 1000 пакетів PL/SQL. Через її розмір жодна людина не здатна осягнути всю кодову базу. Додайте до цього лабіринт специфічних для клієнтів параметрів конфігурації, розрізнену документацію та архів тікетів, що ведеться з 2017 року, — і справжнім вузьким місцем стає «пошук контексту», а не написання коду.

Типовий сучасний хайп навколо ШІ зосереджений на генерації нового коду для проєктів «з нуля» (greenfield projects). У цьому випадку складною частиною є не синтаксис PL/SQL, а пошук конкретної логіки, відповідної конфігурації та історичного тікета, в якому вперше було описано проблему. Досвідчений розробник може годинами збирати докупи підказки з GitLab, SVN, вікі-сторінок та старих тікетів підтримки. ШІ-агент виконує ту саму роботу за лічені хвилини.

Робочий процес на практиці

Коли надходить новий тікет, автор запускає одну команду. Потім агент:

  • Витягує текст тікета та будь-які додані файли через API системи тікетів.
  • Виконує пошук за ключовими словами та векторний пошук по всьому архіву тікетів, щоб знайти схожі минулі випадки.
  • Запитує персональну бібліотеку багаторазових SQL-скриптів.
  • Перевіряє історію коду в системах контролю версій (GitLab або SVN).

Усі знайдені дані збираються в один файл, який також пропонує наступний крок — зазвичай це виправлення коду, чернетка відповіді клієнту або запит на додаткову діагностику.

Вбудовані можливості

Автор визначив 24 «навички» для агента, згруповані у чотири категорії:

  • Доступ до контексту — читання API, інструкцій та баз даних для отримання відповідних фактів.
  • Знання предметної області — інтерпретація правил страхового обліку та архітектури системи.
  • Написання коду — генерація фрагментів PL/SQL та їх підготовка до розгортання.
  • Мета — розпізнавання патернів та автоматичне створення нових навичок за потреби.

Ці навички дозволяють агенту діяти як молодший інженер, який ніколи не спить, знаходячи саме той рядок коду або конфігурацію, на які посилається тікет.

Запобіжні заходи, інтегровані в процес

Автоматизація в робочому середовищі потребує захисних механізмів. Автор дотримується двох простих правил:

  1. Статична валідація — кожен згенерований скрипт проходить через EXPLAIN PLAN щодо живої схеми. Це дозволяє перевірити синтаксичні або логічні помилки без фактичного виконання коду.
  2. Підтвердження двома моделями — другий, незалежний ШІ-агент перевіряє будь-яку зміну, яку вважають ризикованою. Якщо обидві моделі приходять до одного висновку, автор продовжує роботу; в іншому випадку тікет передається на ручну перевірку.

Ці перевірки не дають процесу перетворитися на «чорну скриньку», яка може ненавмисно порушити критичну страхову транзакцію.

Кумулятивний ефект

Результат кожного тікета приєднується назад до запису тікета, створюючи живу базу знань. Коли схожа проблема виникає знову через місяці або роки, агент може прочитати не лише попереднє рішення, а й логіку, яка до нього призвела. Фактично, кожен вирішений тікет стає навчальними даними для майбутніх тікетів, ще більше прискорюючи цикл.

Чесні обмеження

  • Ручне тестування залишається необхідним — автор все одно перевіряє зміни в тестовому середовищі перед розгортанням.
  • Відсутність чітких метрик — хоча економія часу здається значною, автор не кількісно оцінив точне скорочення годин.
  • Персональне налаштування — поточна реалізація працює на одній робочій станції; масштабування на команду потребуватиме додаткових інженерних зусиль.

Ці обмеження не дозволяють назвати цей підхід готовим продуктом, але вони не применшують головного висновку: ШІ може скоротити час збору контексту з годин до хвилин.

За чим спостерігати далі

Експеримент автора є радше доказом концепції (proof-of-concept), ніж комерційним продуктом. Наступні логічні кроки включають:

  • Формалізація метрик – відстеження часу вирішення тікетів до та після впровадження AI-конвеєра для обґрунтування бізнес-кейсу.
  • Командне розгортання – пакування агента як спільного сервісу, щоб кілька інженерів могли користуватися однією базою знань.
  • Інтеграція з CI/CD – пряме подання перевірених скриптів у конвеєр безперервної інтеграції може замкнути цикл від тікета до продакшену без ручної передачі.

Якщо ці розширення будуть успішними, модель може стати шаблоном для інших підприємств, які борються з масивними, застарілими кодовими базами.

Висновки

Справжня цінність ШІ в устарелих середовищах полягає не в автоматичному написанні нового коду, а в миттєвому наданні правильного контексту. Перетворюючи години детективної роботи старшого розробника на кілька хвилин, робочий процес з використанням AI-агента може підтримувати функціональність застарілих систем, знижувати витрати на підтримку та поступово створювати самопідсилювальний репозиторій знань. Експеримент показує, що для застарілого програмного забезпечення найбільший приріст продуктивності забезпечується скороченням часу на пошук відповідей, а не генерацією нового коду.