Как я внедрил агента в бекенд-прод для решения рутинных задач

TL;DR

Мы собрали рабочего ИИ-агента-разработчика, который сам анализирует задачи в Jira, уточняет детали, пишет код, запускает сборку, фиксит ошибки ^[1], создаёт MR в GitLab и отправляет его человеку на ревью. Он работает параллельно на нескольких задачах, благодаря чему суммарное время выполнения пачки задач падает почти втрое. Команда избавилась от рутины, а скорость разработки выросла без расширения штата.

Использовали: Ollama + Qwen3 Coder, PostgreSQL, Docker, GitLab/Jira API, систему строгих JSON-действий.

Столкнулись с контекстом, “галлюцинациями”, GPU и самовольными правками кода – всё решаемо архитектурой.

ИИ не заменяет разработчиков, он снимает тупую монотонную работу и экономит деньги.

1. Предпосылки и проблема

Мы оказались в абсолютно классической для продуктовой команды ситуации: 23 микросервиса, дедлайны подгорают, задач свалилось много, а людей мало. По каждому сервису было по одной-двум задачам – всего около 46, и каждая требовала мелких, но внимательных доработок. Где-то обновить зависимости, где-то поправить ручки, где-то переписать кусок бизнес-логики.

Сами по себе задачи мелкие, но когда их несколько десятков, они начинают жрать время как прожорливая JVM на старом ноуте. Проблема была не в сложности, а в количестве. Средняя скорость разработчика – примерно задача в час. Физически не хватало рук.

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

• не требует расширения штата,

• разгружает команду от рутины,

• ускоряет закрытие однотипных тасков,

• помогает укладываться в ср��ки, а не смотреть на дедлайны как на мемы.

Так появилась мысль: а что если попробовать внедрить ИИ-агента, который будет сам разбирать задачи, уточнять детали, писать код, тестировать и отдавать готовый MR? Не как замену живым разработчикам, а как замену самой скучной части их работы. Так и начался эксперимент.

2. Как агент выглядит со стороны

Для обычного разработчика весь процесс выглядит максимально простым. Агент работает в фоне, не требует специальных знаний и интегрирован в стандартный поток работы.

1. Создаёшь задачу в Jira

Не нужно писать какие-то специальные промпты. Просто стандартное описание:

“Нужно обновить зависимость, поправить эндпоинт и добавить логирование”.

Агент сам находит задачу и начинает анализ.

2. Агент уточняет детали

Если информации мало, он пишет комментарий:

• “Не найден файл X, какой модуль имеется в виду?”

• “Какое поведение ^[2] ожидается после изменения?”

Ведёт себя как живой разработчик, только без нытья и без “давайте уточним, созвон”.

3. После ответа агент продолжает работу

Он пересобирает контекст, анализирует проект, запускает тесты и принимает решение, может ли переходить дальше.

4. Пишет, что приступает к кодингу

Создаёт комментарий:

“Анализ завершён. Начинаю вносить изменения в код”.

Поднимает Docker-контейнер, лезет в репозиторий, вызывает API GitLab.

5. После завершения кодинга сообщает об этом

Пишет:

“Кодирование завершено, изменения локально протестированы”.

6. Создаёт Merge Request

В MR он прикладывает diff, описывает изменения, задаёт последние вопросы. Человек делает финальное ревью.

Выглядит всё так: создал задачу → ответил на пару вопросов → получил готовый MR.

Минимум движений, максимум полезности.

3. Архитектура и техническая часть

Снаружи кажется магией, но внутри – чёткая инженерная система.

1. Основная идея: бесконечный цикл

Цикл агента выглядит так:

1. Берёт задачу

2. Создаёт запрос к LLM

3. Получает действия в формате JSON

4. Исполняет их

5. Обновляет состояние

6. Повторяет

По сути – мини-оркестратор, который позволяет LLM управлять реальными инструментами.

2. Общение с моделью только через JSON

Модель не может печатать свободный текст, кроме комментариев в Jira. Основной формат:

{
 "action": "read_file",
 "path": "src/main/java/com/app/Service.java"
}

Или:

{
 "action": "write_file",
 "path": "src/main/java/com/app/Service.java",
 "content": "..."
}

Строгие действия – главный инструмент против хаоса.

3. Доступные действия

Модель может только то, что мы явно разрешили:

• read_file – читает содержимое указанного файла и отдаёт его модели, чтобы она могла анализировать код.

• write_file – перезаписывает или создаёт файл с новым содержимым, сгенерированным моделью.

• run_gradlew_check – запускает сборку проекта и тесты через Gradle внутри Docker, возвращает логи и статус (успех/ошибка).

• docker.exec – выполняет произвольную команду внутри Docker-контейнера (например, ls, grep, утилиты и т.п.).

• jira.comment – публикует комментарий в соответствующей задаче Jira от имени агента.

• finish_stage – сообщает агенту, что модель завершила текущий этап (планирование, кодирование или ревью) и можно переходить к следующему.

И всё. Никакого “а давайте я тут перепишу проект по-своему”.

4. PostgreSQL как память

В БД хранится:

• текущее состояние (planning, coding, review),

• история сообщений (сжатая),

• информация о файлах,

• пройденные действия,

• результаты тестов,

• логи.

Память ^[3] не в модели, а в сервисе – поэтому цикл устойчив к ошибкам.

5. Как решали проблему контекста

История быстро растёт, LLM забывает ^[4], повторяет вопросы, чинит уже работающий код.

Мы внедрили автоматическую компрессию:

агент отправляет истории модели и просит сжать до ключевых моментов. Модель возвращает “скелет” диалога.

6. Docker как песочница

Все сборки и тесты – внутри контейнера. Предсказуемо, безопасно, одинаково.

7. Интеграции

Агент работает с:

• Jira API,

• GitLab API,

• Docker Engine API,

• Файловой системой репозитория.

Модель видит только JSON-команды. Агент исполняет и присылает модельке события:

{
 "event": "build_result",
 "success": false,
 "log": "Compilation error at line 42"
}

8. Почему всё это работает

Потому что:

• действия детерминированы,

• история структурирована,

• модель ограничена инструментами,

• состояние хранится вне LLM,

• человек контролирует финальные шаги.

Модель думает.

Агент работает физически.

Вместе это даёт стабильный результат.

4. Результ��ты

Мы запускали ИИ-агента на реальных задачах из 23 микросервисов.

Среднее время на задачу

После оптимизаций:

≈ 2 часа от постановки до готового MR

Время включает:

• анализ,

• уточнения,

• чтение файлов,

• написание кода,

• сборку,

• исправление ошибок,

• создание MR.

Человек тратит ~1 час, но последовательно.

Агент делает до 5 задач параллельно.

Сравнение

23 задачи.

Если вручную:

≈ 23 часа.

Если агентом:

46 «человеко-часов» задач / 5 потоков = ≈ 9.2 часа.

Агент оказался почти в 2.5 раза быстрее в суммарном времени выполнения пачки.

5. Какие трудности были

1. Контекст

Модель забывает детали, повторяет вопросы, фиксит уже фиксированное.

Компрессия истории стала спасением.

2. Ненужные правки

Иногда модель думала, что она архитектор-самоучка:

• меняла форматирование,

• трогала чужие файлы,

• пыталась “улучшить” код.

Решение: фильтры, ограничения, валидация.

3. GPU

Qwen3 Coder любит VRAM.

3060 хватало, но под нагрузкой агент работал немного медленнее.

4. Повторные вопросы при ошибках

Если сборка падала, модель могла зависнуть в цикле вопросов.

Исправили через отдельные статусы ошибок и события вне контекста.

5. Частичные задачи

Иногда агент забывал:

• миграции,

• тесты,

• Swagger,

• зачистку ненужных файлов.

Добавили чёткие стадии и чеклисты валидации.

6. Какие плюсы мы получили

1. Идеально подходит для однотипных задач

Обновить зависимость?

Поменять поле?

Поправить JSON-схему?

Агент делает это как хороший джун.

2. Работает 24/7

Не ноет, не устает, не просит отпуск, не прокрастинирует.

3. Масштабируется

Поставил ещё одну видеокарту – получил ещё агентов.

4. Параллельность

Агент работает над несколькими задачами сразу:

анализирует одну, пишет код в другой, ждёт сборку в третьей.

5. Если дать чёткое ТЗ – работает почти идеально

Модель не додумывает.

Если задача формализована, агент делает её чисто.

7. Дальнейшее развитие

1. RAG для кода

Храним индекс всех репозиториев, чтобы модель могла спрашивать:

• где используется сервис,

• какие классы зависят от модуля,

• где лежит нужная логика ^[5].

2. Переход на MCP

Вместо кастомного JSON-протокола – формальные инструменты, меньше ошибок, легче масштабировать.

3. TOON/CSV как формат

Меньше кавычек, меньше токенов, удобнее передавать логи.

4. Глубокая интеграция автотестов

Передаём модели логи → она анализирует → вносит фиксы → снова запускает тесты.

5. Автоматический MR-review

Агент сам создаёт MR, сам ревьюит, сам дорабатывает.

6. LoRA-дообучение модели

Под нашу кодовую базу → агент работает как уверенный мидл.

7. Полностью автоматические dependency-updates

Полный цикл обновлений без участия человека.

8. Выводы

1. ИИ не заменяет разработчиков

Он снимает рутину и освобождает время на сложные задачи.

2. Ускорение реальное

2–3× по времени выполнения, плюс параллельность.

3. Качество кода выросло

Меньше ошибок, меньше забытых деталей, более стабильный формат.

4. Стоимость выполнения задач снизилась

Не пришлось нанимать людей, скорость выросла.

5. Это фундамент для дальнейшего развития

Мы двигаемся к полноценной системе автономной разработки.

9. Заключение

Эксперимент с ИИ-агентом показал, что автоматизация разработки – это не фантазия, а рабочий инструмент, который уже сегодня ускоряет команду, снижает стоимость задач и повышает качество результата. Агент не заменяет разработчиков, а убирает монотонную часть их работы, позволяя сосредоточиться на архитектуре, продукте и сложных инженерных задачах.

Этот проект стал фундаментом для системы, которая в будущем сможет выполнять всё больший объём работы самостоятельно – от RAG-контекста до полного автономного цикла разработки.