директор по Технологиям, ОАО СберТех, РФ, г. Москва
РЕАЛИЗАЦИЯ AI-АГЕНТОВ ДЛЯ РАЗРАБОТКИ ПО ОБЪЕДИНЯЮЩИХ ПРЕДИКТИВНЫЕ И ЯЗЫКОВЫХ МОДЕЛЕЙ
АННОТАЦИЯ
Задачи обслуживания исходного кода программного обеспечения, позволяющие предотвращать рост «технического долга» и деградацию качества, занимают значительную долю рабочего времени инженера‑разработчика. В статье представлен опыт реализации AI‑агентов для автоматизированного обслуживания исходного кода с использованием предиктивных моделей, которые определяют участки, требующие модификаций, и генеративных (языковых) моделей, выполняющих сами изменения. Описан общий подход к построению предиктивных моделей на основе метрик программного обеспечения и производственного процесса, приведены результаты их применения, а также формат совместного использования предиктивных и языковых моделей. В качестве среды исполнения агентов использовалась интегрированная среда разработки GIGA IDE, а сервис языковой модели, оптимизированной для работы с кодом, предоставлялся GIGA CODE.
ABSTRACT
Software source code maintenance tasks that prevent the growth of technical debt and software degradation take a significant portion of a developer’s time. This paper presents the implementation of AI agents for automated source code maintenance combining predictive models that identify code areas for modification and generative (language) models that perform the actual changes. We describe a general approach to constructing predictive models based on software and software‑production process metrics, report the results of their adoption, and present a format for combining predictive and language models. The integrated development environment GIGA IDE served as the agent runtime, and GIGA CODE provided an LLM optimized for working with source code.
Ключевые слова: AI-агенты, предиктивные модели, генеративные модели, технический долг, обслуживание исходного кода, GIGA IDE, GIGA CODE, Java, Spring, Jakarta.
Keywords: AI agents, predictive models, generative models, technical debt, source code maintenance, GIGA IDE, GIGA CODE, Java, Spring, Jakarta.
Введение
Задача обслуживания исходного кода (source code maintenance), или поддержания его качества, охватывает подзадачи рефакторинга, направленные на повышение понятности, снижение связности модулей, улучшение тестового покрытия, прозрачности функционирования и производительности программного обеспечения. Комплекс таких мероприятий для растущей кодовой базы традиционно относят к управлению «техническим долгом (technical debt)». Согласно оценкам, затраты на обслуживание исходного кода могут составлять до 23% совокупного времени разработчиков, при этом накопленный технический долг влияет на программно‑аппаратный комплекс в целом и на общий IT‑долг, увеличивая расходы на модернизацию. Попытки внедрения подходов Low‑Code/No‑Code/Vibe‑Coding без достаточного инженерного контроля усугубляют проблему: отсутствие понимания того, как работает конечный код, делает эксплуатацию ПО экономически неприемлемой. В таких условиях автоматизация обслуживания исходного кода посредством AI‑агентов становится перспективным направлением, позволяющим удерживать качество и темпы развития систем.
Методы
1. Гипотезы и метрики.
Были сформулированы и проверены гипотезы о влиянии качества исходного кода на метрики программного обеспечения и метрики процесса разработки. Операции обслуживания кода гранулировались так, чтобы каждая управлялась одной метрикой, а добавляемые фрагменты не увеличивали технический долг. Состав метрик и связанных гипотез приведён в Таблице 1.
Таблица 1.
Метрики и гипотезы для агентов
|
Метрика |
Гипотезы |
|
DD (Defect Density) |
Улучшить показатель DD возможно могут следующие мероприятия:
|
|
RDR (Reopened Defects Ratio) |
Улучшить показатель RDR возможно могут следующие мероприятия:
|
|
CFR (Change Failure Rate) |
Улучшить показатель CFR возможно могут следующие мероприятия:
|
|
LT (Lead Time) |
Улучшить показатель LT возможно могут следующие мероприятия:
|
2. Предпосылки кода и сбор данных.
Приняты следующие допущения: (1) используется слоистая архитектура (API, Business Logic, Data Access) для монолитов и микросервисов; (2) анализируемый код написан на Java/Kotlin с использованием Spring и/или Jakarta (JavaX) с маркирующими аннотациями и интерфейсами; (3) значим только код маркированных типов и их публичных членов; (4) каждая модификация в рамках процедуры обслуживания рассматривается как бинарная (выполнена/не выполнена). Для сбора данных разработан набор грабберов, извлекающий код проекта, редуцирующий его до разметок фреймворков и помечающий наличие/отсутствие целевых модификаций (например, инструкций логирования или управления транзакциями). Дополнительно извлекались артефакты жизненного цикла (дефекты, задачи), на основании которых рассчитывались фактические значения метрик (например, DD, RDR, CFR).
3. Построение моделей.
Для подтверждения гипотез строились модели методом Random Forest с оценкой прогностической силы. Гипотеза считалась подтверждённой при получении достаточного качества (R²). Итоговый набор подтверждённых моделей и соответствующие значения R² приведены в Таблице 2. Среди наиболее значимых факторов отбора участков кода для модификаций отмечены: (i) суммарное число полей всех связанных по ссылкам типов параметров сигнатуры метода; (ii) цикломатическая сложность метода, включая вызываемые приватные методы.
Таблица 2.
Итоговый предиктивных моделей на базе исходного состава гипотез
|
Метрика |
Модель на безе метрики |
R2 |
|
DD (Defect Density) |
Оптимизация точек расстановки логов для улучшения понимания исходной проблемы в работе ПО в run-time |
0.96 |
|
DD (Defect Density) |
Оптимизация объема расстановки инструкций управления транзакциями для увеличения консистентности операций |
0.92 |
|
DD (Defect Density) |
Оптимизация кол-ва API-тестов и/или ручных тестов с целью увеличения качества регресса. |
0.93 |
|
LT (Lead Time) |
Оптимизация модульной гранулярности кода для снижения сцепления и упрощения доработок |
0.95 |
4. What‑if анализ и пороговые параметры.
Прикладное применение предиктивных моделей реализовано в формате what‑if анализа. Для каждого маркированного члена оценивается изменение целевой метрики при выполнении модификации. Если модификация улучшает показатель более порогового значения TA и код ещё не модифицирован, изменение предлагается или выполняется автоматически. Если код уже модифицирован и отмена приводит к ухудшению метрики меньше порога TR, пользователю предлагается откат. Параметры TA и TR (TA < TR) вычисляются из предметных требований, а для удобства предлагаются режимы работы агента (например, «Экономия», «Развитие», «Стабилизация»), как показано в Таблице 3.
Таблица 3.
Пример набора режимов работы агента с разным набором порогов
|
Режим |
Как вычислены |
|
Экономия |
Значения TA и TR такие, что проект попадает в 20% проектов с минимальной плотностью инструкций логирования. Ожидается, что низкая плотность логов позволит максимально сэкономит на инфраструктуре для сбора и хранения логов. |
|
Развитие |
Значения TA и TR такие, что проект попадает в 60% проектов со средней плотностью инструкций логирования. Ожидается, что плотность логов будет достаточной для развития проекта без ухудшения метрики. |
|
Стабилизация |
Значения TA и TR такие, что проект попадает в 20% проектов с минимальной плотностью инструкций логирования. Ожидается, что высокая плотность логов позволит как можно быстрее стабилизировать работу ПО. |
5. Архитектура и среда выполнения.
Агенты реализованы в виде плагинов к интегрированной среде разработки GIGA IDE, использующих её API для построения редуцированной модели кода (элементы Elements). Предиктивные модели исполняются на серверной стороне. Генерация изменений выполняется либо по шаблонам, либо с использованием GIGA CODE (LLM, оптимизированной под код), предустановленного в GIGA IDE. Упрощённая архитектура агента показана на Рис. 1.
/Slekenichs.files/image001.png)
Рисунок 1. Типовая архитектура Агента
Результаты
Получены предиктивные модели с высокими значениями R² для задач оптимизации расстановки логов, управления объёмом транзакций, наращивания тестового покрытия и оптимизации модульной гранулярности. Сводные результаты приведены в Таблице 2. Практическая реализация обеспечила: (1) валидацию проекта на предмет точек, требующих изменений; (2) автоматическую модификацию кода в выявленных местах; (3) интерактивные предложения по текущему открытому файлу; (4) конфигурирование параметров работы агента.
Обсуждение
Использование одной и той же метрики (например, DD) в нескольких моделях не противоречит практике, поскольку наибольший эффект достигается в разных и слабо пересекающихся слоях архитектуры (например, управление транзакциями эффективнее на уровне доступа к данным). Полученные факторы важности согласуются с экспертным опытом и подтверждают, что целевую функцию следует подбирать с учётом слоя (API, Business Logic, Data Access). Ограничения исследования включают зависимость от архитектурных и технологических предпосылок (Java/Kotlin, Spring/Jakarta) и необходимость дальнейшей проверки для других языков и фреймворков (например, Python/Django или FastAPI).
Заключение
Исследование подтвердило применимость предиктивных моделей, построенных на основе показателей ПО и производственного цикла, для автоматизации обслуживания исходного кода: они позволяют определять конкретные места модификаций и, в комбинации с языковыми моделями, существенно сокращать трудозатраты разработчиков и минимизировать влияние технического долга — особенно при смене стадии жизненного цикла ПО. Дальнейшее развитие предполагает расширение набора агентов и метрик, поддержку новых языков программирования и архитектур.
Список литературы:
- AI-ассистент разработчика GIGA CODE [Электронный ресурс]. – Режим доступа: https://gigacode.ru/ (дата обращения: 14.09.2025).
- Интегрированная среда разработки GIGA IDE [Электронный ресурс]. – Режим доступа: https://gigaide.ru/ (дата обращения: 14.09.2025).
- Besker T., Martini A., Bosch J. Software developer productivity loss due to technical debt—A replication and extension study examining developers’ development work // Journal of Systems and Software. – 2019. – Pp. 41–61.
- Breiman Leo. Random Forests // Machine Learning journal. – 2001. – Vol. 45 (1). – Pp. 5–32.
- Cunningham W. The WyCash portfolio management system // Proceedings of the Object-Oriented Programming Systems, Languages, and Applications. – OOPSLA ’92, – Vancouver: British Columbia, Canada, 1992. – Pp. 29–30,
- Dalal V., Krishnakanthan K., Münstermann B., Patenge R. Tech debt: Reclaiming tech equity. – Retrived from: https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/tech-debt-reclaiming-tech-equity (accessed date: 05.10.2025)
- Dominic-Madori D. Vibe coding has turned senior devs into ‘AI babysitters,’ but they say it’s worth it – Retrived from: https://techcrunch.com/2025/09/14/vibe-coding-has-turned-senior-devs-into-ai-babysitters-but-they-say-its-worth-it/ (accessed date: 05.10.2025)
- Walker A. The case against vibe coding – Retrived from: https://www.theserverside.com/tip/The-case-against-vibe-coding (accessed date: 05.10.2025)