Ещё одна статья которая опубликована в канале EXANTE Technology, хочу поделиться с вами переводом.

Меня зовут Алина, я Head направления веб-приложений в EXANTE. Я отвечаю за техническую стратегию веб-проектов, эффективность delivery и развитие инженерных процессов в командах, а также веду ряд инициатив, включая AI-трансформацию.

Когда мы начали работать с AI, нам было важно не ограничиваться отдельными инструментами для разработчиков. Мы хотели выстроить автономный пайплайн, который мог бы брать на себя часть задач целиком, и оценить, насколько такой подход повышает производительность команд и сокращает время от постановки задачи до готового результата. Так появилась Codey — система AI-агентов, которая самостоятельно проходит значительную часть пути от задачи в Jira до работающей фичи.

Полгода назад мы начали ее внедрять, и за это время получили такие цифры:

• 250 задач прошло через систему;

• 75% из них были выполнены успешно;

• 7% от общего количества задач Codey берет на себя в командах, где её внедрили;

• Обычно от начала написания кода до развёртывания feature environment проходит около 30 минут.

Чтобы AI стал частью реального процесса разработки, одной сильной модели недостаточно. Нужны качественные требования, подготовленные проекты, измеримые проверки и понятные правила работы системы.

От отдельных автоматизаций к AI-разработчику

Мы начинали с небольших инструментов автоматизации: AI review и анализа affected modules по изменённому diff. Они ускоряли отдельные этапы после написания кода, но не могли самостоятельно пройти весь цикл — от разбора Jira-задачи и исследования кодовой базы до реализации и проверок. Об этом этапе я рассказывала в предыдущей статье.

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

Сейчас Codey хорошо работает с проектами на Node.js, React и Python. Мы начинали с локальных frontend- и UI-задач, а затем перешли к full-stack-изменениям, затрагивающим frontend и backend.

Сегодня мы применяем систему во всех проектах моего направления: от внутренних CRM- и back-office-систем до клиентских сервисов, включая личный кабинет пользователя, торговый web-терминал и desktop-приложение.

Как работает Codey

Архитектурно Codey — разработанный нами слой оркестрации AI-агентов. Под AI-агентом мы понимаем модель, которая работает в подключённой среде исполнения, получает определённую роль и доступ к необходимым инструментам. Среды — Claude Agent SDK, Codex и OpenCode — позволяют агентам работать с репозиториями, файлами и терминалом. Codey связывает их в единый процесс: распределяет роли и этапы, запускает проверки, возвращает работу на доработку и синхронизирует результат с Jira, GitLab и CI.

Как в Codey попадают задачи

Первый сценарий встроен в планирование спринта и зависит от этапа внедрения Codey. На старте команда вручную выбирает хорошо описанные задачи и помечает их для передачи системе. В командах, где процесс уже выстроен, Codey и разработчики работают с общим бэклогом: система по умолчанию забирает подходящие задачи, а команда ставит метку AI skip на те, которые по определённым причинам должен выполнить человек. Постепенно мы хотим распространить этот подход на все подключённые команды и проекты.

Второй сценарий начинается в Slack. Заказчик описывает запрос, а Codey помогает сориентироваться в системе, уточняет детали и формирует Jira-задачу. Затем система выполняет её, создаёт merge request и возвращается в тот же чат: отмечает заказчика, приглашает проверить результат и присылает ссылку на feature environment.

Когда Codey получает задачу из Jira, он определяет связанные с ней GitLab-репозитории. Для каждого проекта заранее настроено:

• в какие репозитории направлять задачу;

• какие автоматические проверки запускать;

• кого назначать ревьюером;

• как разворачивать feature environment и связывать нужные версии frontend и backend.

Благодаря этим настройкам Codey знает, как провести задачу по процессу конкретного проекта и подготовить результат к проверке команды.

Какие роли есть в системе AI-агентов

Над задачей работают шесть основных ролей:

• Researcher исследует требования и кодовую базу;

• Planner составляет план;

• Developer пишет код и тесты;

• Reviewer проверяет качество и корректность изменений;

• QA запускает тесты и технические проверки;

• Verifier сопоставляет результат с обязательными требованиями плана.

Для разных ролей система использует разные модели. Если Reviewer или автоматические проверки находят проблему, Developer получает задачу на доработку.

После передачи результата команда проводит ревью. Codey учитывает замечания к коду и бизнес-логике из merge request и Jira-задачи, вносит изменения и повторно запускает проверки.

Чтобы задача не застревала в цикле доработок, Codey делает не более трёх итераций. Если замечания не устранены, задача получает статус AI failed; результат попадает в статистику и в контур самоулучшения системы. При необходимости выполнение можно перезапустить вручную.

Проверки и обработка ошибок

После создания merge request Codey запускает quality gates проекта: тесты, линтеры, security-проверки и AI review. Если проблему можно исправить, задача возвращается на доработку. Если проверку нельзя запустить из-за настроек проекта, Codey создаёт Draft merge request и указывает, какие проверки не выполнены.

Чаще всего статус AI failed связан с нехваткой контекста, изменениями в нескольких взаимозависимых репозиториях или первыми задачами в новом проекте либо технологическом стеке.

Проверка результата командой

Для каждого merge request Codey определяет affected modules и указывает в Jira, какие части продукта нужно учесть при регрессе. После успешных проверок frontend и backend разворачиваются в отдельном feature environment, где заказчик может проверить всю фичу целиком.

Если результат соответствует ожиданиям, заказчик нажимает Confirm. Затем задача проходит ревью команды и попадает в релизную сборку. Продуктовая приёмка, финальное решение и ответственность за выпуск остаются за людьми.

Бизнес-вызовы

Качество постановки задач. Codey, как и любой участник разработки, не может качественно выполнить задачу без чётких требований. Поэтому мы ввели шаблоны Jira-задач с обязательным описанием acceptance flow и ожидаемых проверок, включая требования к unit- и integration-тестам.

Доверие команды к Codey. На старте мы предлагаем начинать с рутинных задач или рефакторинга, которые в любом случае проходят ревью специалистов. По мере накопления успешных результатов команды переходят от ручного отбора к общему бэклогу для Codey и разработчиков, отмечая исключения как AI skip. Это позволяет постепенно укреплять доверие и давать системе больше контекста.

Смещение нагрузки на ревью и проработку. На старте внедрения часть нагрузки перемещается на эти этапы: разработчику нужно разобраться не только в задаче, но и в том, как Codey её интерпретировал и реализовал. Мы снижаем эту нагрузку более точными описаниями задач, подробными правилами для каждого проекта и многоуровневым автоматическим и человеческим ревью.

Инфраструктурные расходы. Отдельные backend feature environments увеличивают стоимость инфраструктуры. Чтобы контролировать расходы, мы ограничиваем срок жизни окружений и используем урезанные тестовые базы.

Технические сложности

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

Поэтому для каждого проекта мы поддерживаем profile с описанием архитектуры, структуры кодовой базы, команд сборки и тестирования и локальных правил разработки. Для повторяющихся задач в Codey предусмотрены skills на трёх уровнях: глобальном, для конкретного языка и для конкретного проекта. Система формирует новые варианты skills на основе накопленных паттернов, но сначала они проходят проверку и только затем подключаются к пайплайну. Это позволяет адаптировать поведение Codey к контексту конкретного проекта.

Качество изменений. Для этого проектам был нужен простой и воспроизводимый сетап, понятные команды проверок и зрелые quality gates. Тесты, линтеры, security-проверки и AI review в CI останавливают проблемные изменения до того, как они создадут дополнительную нагрузку на команду или попадут в прод.

Подбор AI-моделей для разных ролей. Мы подбираем AI-модели на основании регулярных бенчмарков. Для этого мы смотрим, как разные комбинации моделей, ролей и инструментов выполняют один набор универсальных задач. Затем сравниваем solve rate — долю решений, которые прошли обязательные проверки и получили оценку, сопоставимую с результатом человеческой проверки, а также скорость и стоимость выполнения. Для независимой оценки результат не передаётся на ревью модели того же семейства.

Бенчмарки показали, что использование одной наиболее мощной модели на всех этапах не всегда даёт лучший результат. Для некоторых ролей более простая модель может оказаться эффективнее сложной: точнее следовать плану, реже переусложнять решение и быстрее завершать задачу. Поэтому мы регулярно пересматриваем распределение моделей между ролями по результатам тестов. По результатам последних тестов часть ролей мы уже перевели на модели Codex.

Постоянное улучшение системы. Для системного улучшения Codey мы используем Learning loop: он анализирует логи и проблемные сессии, находит повторяющиеся ошибки и формирует гипотезы. Каждое изменение проверяется на том же benchmark и попадает в production только после измеримого улучшения.

В одном из таких циклов мы проверили 20 гипотез и оставили девять. Дополнительно мы учитываем обратную связь разработчиков и тестировщиков. Параллельно оптимизируем работу с кодом и контекстом: RTK сокращает объём вывода команд, а AST-индекс ускоряет поиск нужных модулей.

Что дальше

В ближайшее время мы продолжим развивать Codey в нескольких направлениях:

• автоматический анализ общего бэклога: система будет сама предлагать подходящие задачи, а команда — исключать те, которые нельзя передать AI;

• развитие Learning loop: постоянный анализ комментариев людей в merge request и использование этой обратной связи для автоматического улучшения движка;

• расширение охвата: подключение к Codey новых заказчиков и подразделений, проектов, технологических стеков и систем;

• подключение дополнительных источников контекста — документации, Jira и рабочих коммуникаций — и развитие Codey как основы не только для разработки, но и для аналитической и продуктовой проработки задач;

• переход к delivery по фичам, чтобы изменения от Codey быстрее попадали в production после обязательных проверок.

Вывод

За полгода мы убедились, что AI-разработчик может быть частью рабочего процесса. Для этого недостаточно просто подключить к разработке сильную модель: нужны качественные требования, подготовленные проекты, измеримые проверки и понятные правила работы системы.

Следующий шаг — передать Codey полный цикл работы с частью задач: от их постановки до выхода в production, сохраняя заданные правила и контроль рисков.