Автор 20-летней страховой платформы пропустил 108 тикетов техподдержки через кастомный конвейер на базе ИИ-агентов. Результатом стал рабочий процесс, который превращает многочасовую задачу уровня senior-разработчика в считанные минуты — сдвиг, способный изменить подход предприятий к поддержке legacy-кода.

Почему устаревшие системы важнее нового кода

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

Типичный хайп вокруг современного ИИ сосредоточен на генерации свежего кода для greenfield-проектов. В данном случае сложность заключается не в синтаксисе PL/SQL, а в поиске конкретного фрагмента логики, соответствующей конфигурации и исторического тикета, в котором впервые была описана проблема. Опытный разработчик может тратить часы, собирая воедино зацепки из GitLab, SVN, вики-страниц и старых тикетов техподдержки. ИИ-агент выполняет ту же работу за минуты.

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

Когда поступает новый тикет, автор запускает одну команду. Затем агент:

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

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

Встроенные возможности

Автор определил 24 «навыка» для агента, сгруппированных в четыре категории:

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

Эти навыки позволяют агенту действовать как junior-инженер, который никогда не спит, находя именно ту строку кода или конфигурации, на которую ссылается тикет.

Предохранители, встроенные в цикл

Автоматизация в рабочей среде требует мер защиты. Автор следует двум простым правилам:

  1. Статическая валидация — каждый сгенерированный скрипт прогоняется через EXPLAIN PLAN по живой схеме. Это позволяет проверить синтаксические или логические ошибки без фактического выполнения кода.
  2. Подтверждение двумя моделями — второй, независимый ИИ-агент проверяет любое изменение, признанное рискованным. Если обе модели приходят к одному и тому же выводу, автор продолжает работу; в противном случае тикет передается на ручную проверку.

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

Накопительный эффект

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

Честные ограничения

  • Ручное тестирование сохраняется — автор по-прежнему проверяет изменения в тестовой среде перед внедрением.
  • Отсутствие жестких метрик — хотя экономия времени кажется существенной, автор не количественно оценил точное сокращение рабочих часов.
  • Персональная настройка — текущая реализация работает на одной рабочей станции; масштабирование на команду потребует дополнительных инженерных усилий.

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

За чем следить дальше

Эксперимент автора — это скорее proof-of-concept, чем коммерческое предложение. Следующими логическими шагами станут:

  • Формализация метрик — отслеживание времени решения заявок до и после внедрения ИИ-конвейера для обоснования бизнес-кейса.
  • Командное развертывание — упаковка агента в виде общего сервиса, чтобы несколько инженеров могли использовать одну и ту же базу знаний.
  • Интеграция с CI/CD — прямая передача проверенных скриптов в конвейер непрерывной интеграции может замкнуть цикл от заявки до продакшена без ручной передачи задач.

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

Итог

Реальная ценность ИИ в legacy-средах заключается не в автоматическом написании нового кода, а в мгновенном предоставлении нужного контекста. Превращая многочасовую «детективную работу» ведущего разработчика в несколько минут, рабочий процесс с ИИ-агентом позволяет поддерживать работоспособность устаревающих систем, снижать затраты на поддержку и постепенно создавать самообновляемый репозиторий знаний. Эксперимент показывает, что для legacy-ПО наибольший прирост производительности достигается за счет сокращения времени на поиск ответов, а не за счет генерации нового кода.