В Jira у автора этого кейса зарегистрированы три виртуальных исполнителя: AI Front-dev, AI Back-dev и AI-аналитик. Они стоят в поле Assignee рядом с людьми, и задача назначается им привычным способом: выбрать исполнителя в списке, перевести тикет в «В работе». После этого в бэкенде harness автоматически появляется задание, и агент начинает работу.
Граница проходит по ревью. Людей агенты не заменяют: ответы на уточняющие вопросы, проверка merge request и последнее слово остаются за человеком. Автор кейса описывает это прямо, и эту рамку стоит держать в голове до конца текста.
Дальше разберём техническую цепочку целиком: как устроен серверный harness, что происходит после смены статуса, как выглядят два контрастных сценария (кнопка копирования реквизитов и остановка аналитика на вопросах), какие нужны учётные записи и PAT, зачем в схеме PostgreSQL и Redis, из чего складывается стоимость и почему ревью превращается в узкое место.
Что значит «назначить задачу AI-агенту» в Jira
AI-агент в этой схеме выступает обычным исполнителем. У него есть учётная запись, он виден в списке Assignee, получает задачу и отчитывается артефактами в том же тикете. Отдельного чата, команды в комментариях или панели с ботом не нужно: вся коммуникация идёт через штатный workflow.
Три роли виртуальных исполнителей: фронт, бэк и аналитик
Разделение на роли решает две задачи. Первая: у разных типов работ разный контекст. Фронтенду нужны компоненты и дизайн-система, бэкенду модели данных и API, аналитику шаблоны User Story и документация в Confluence. Вторая: разные инструкции в harness. Один универсальный агент тянул бы в контекст всё сразу и размывал приоритеты.
По функциям это выглядит так: AI-аналитик готовит черновики требований и User Story, AI Front-dev и AI Back-dev пишут код и открывают merge request. Продуктовые решения за команду агенты не принимают, и это не техническое ограничение на текущем этапе, а сознательная граница ответственности.
Чем это отличается от бота и внешнего скрипта
Бот реагирует на команду в чате, скрипт запускается по вебхуку или расписанию. Здесь агент живёт в штатном процессе: поле Assignee, статус «В работе» как триггер, результат в виде ссылок на merge request и статуса «На ревью» прямо в задаче. Менеджеру не нужно помнить про отдельный интерфейс, всё видно в тикете.
Ключевой элемент схемы - harness. Автор определяет его как рабочую среду вокруг модели: контекст проекта, инструкции, доступы и проверки. Локальная версия harness давно стала рабочим контуром команды, серверная появилась именно ради постановки задач в Jira.
Как устроен серверный harness: от статуса «В работе» до merge request
Цепочка выглядит так: тикет перешёл в «В работе», в бэкенде harness создано задание, собран контекст, работа выполнена в изолированном окружении, результат опубликован в GitLab. В карточке задачи при этом видны промежуточные артефакты: загрузка инструкций проекта, изучение репозиториев, логи тестов и результаты проверок.
Сбор контекста из Jira, Confluence и репозиториев
Источников три: описание задачи в Jira, документация в Confluence, код в репозиториях. Агент просматривает репозитории, выбирает нужные и по ходу работы может решить обновить документацию, это решение видно в логах задачи. Такая автономия полезна, но добавляет работу: в описанном кейсе она вылилась в отдельный merge request.
Качество контекста напрямую определяет результат. Одна строка без макета даёт кнопку, которая работает, но выглядит скучно. Чем точнее описание, критерии приёмки и ссылки на макеты, тем меньше итераций и тем выше шанс, что MR уйдёт в работу с первого раза.
Отдельная проблема - длинные задачи с большой кодовой базой: контекстное окно переполняется, и агенту нужен механизм переноса состояния между сессиями. Подходы к такому переносу разобраны в материале про harness для длительных задач и работу с контекстом.
Изолированное окружение и проверки
Работа идёт в изолированном окружении, результат не попадает в основную ветку напрямую. Код приходит через merge request, где его можно проверить, а проверки для репозиториев работают дополнительным барьером перед созданием MR. Агент не коммитит в защищённую ветку и не обходит ревью.
В доступном фрагменте источника не раскрыто, какие именно инструменты изоляции используются, поэтому конкретные названия приводить не будем. На уровне архитектуры важно другое: у агента есть ограниченная площадка для работы, а не прямой доступ к продакшен-ветке.
Публикация результата: MR и черновик User Story
Форм артефакта две. Для разработки это merge request в GitLab: код, тесты, документация. Для аналитики черновик User Story, который человек дорабатывает и принимает. В демонстрационной задаче итог выглядел как две ссылки на merge request и статус «На ревью»: первый MR с проектной документацией и описанием новой кнопки, второй с самим кодом кнопки в стиле проекта, тестом и логикой копирования.
Сценарий 1: oneshot-задача на кнопку копирования реквизитов
Oneshot-задача - достаточно понятная и ограниченная, чтобы решить её за один проход без долгой переписки. Примеры: добавить кнопку, поправить форму, подготовить черновик требований. Именно на таких задачах схема показывает себя лучше всего.
Что было в задаче и что сделал агент
Формулировка в Jira состояла из одной строки: добавить кнопку копирования реквизитов поставщика на карточку поставщика. Ни описания, ни макета, ни требований к оформлению. Исполнитель - AI Front-dev, дальше перевод в «В работе» и автоматический запуск задания.
Агент изучил репозитории, выбрал нужные, решил заодно обновить проектную документацию, написал код в стиле проекта, добавил тест и логику копирования в буфер обмена. Итог: два MR и статус «На ревью». Кнопка появилась и копирует реквизиты, то есть функционально задача закрыта.
Почему результат вышел «скучным» и как это исправить
Визуально кнопка получилась скучной. Причина не в агенте: в задаче не было ни макета, ни требований к оформлению, и он сделал минимально достаточный вариант. Чтобы попасть в дизайн проекта, ему нужны макеты в Figma или хотя бы подробное текстовое описание.
Практический вывод: oneshot не отменяет постановки. Критерии приёмки стоит писать проверяемо: где расположена кнопка, какой компонент дизайн-системы использовать, что происходит после нажатия, какие состояния показывать. Логика явных ограничений и списка исключений в задаче подробно разобрана в кейсе про постановку задачи и список того, чего в системе не будет.
Сценарий 2: задача аналитика, где агент останавливается и задаёт вопросы
Второй сценарий сложнее. Задача на подготовку требований, контекста не хватает, и AI-аналитик останавливается, чтобы задать уточняющие вопросы человеку, вместо того чтобы додумать детали самостоятельно.
Почему остановка на вопросы - это правильное поведение
Додуманное требование - самый дорогой дефект: его находят на ревью или позже, когда код уже написан. Остановка стоит одного ответа человека. Догадка стоит переделок в коде, документации и тестах.
Сравнение с oneshot показательное. В задаче про кнопку контекста хватало, и агент дошёл до merge request. В аналитической задаче контекста не хватило, и агент это распознал. Для черновиков User Story такая пауза штатна: аналитик приносит вопросы, человек отвечает, работа продолжается.
Похожий эффект зафиксирован в кейсе, где ИИ-агент стал главным помощником аналитиков и закрывал больше половины исследовательских запросов: ценность оказалась в ответах на вопросы о системе, а не в автономной работе.
Оговорка по источнику: полный диалог и точные формулировки вопросов в доступном фрагменте не приведены, поэтому детали этого сценария не воспроизводим и не додумываем.
Настройка доступов: учётные записи и PAT для Jira, Confluence и GitLab
Первый шаг настройки - отдельная учётная запись на каждого агента. Это даёт аудит действий в истории задач, ограничивает область поражения при ошибке и позволяет развести инструкции по ролям. Личные аккаунты разработчиков для агентов использовать не стоит.
Какие токены нужны и как ограничить права
Базовая рамка такая: PAT (personal access token) для Jira с правом читать задачи, менять статусы и оставлять комментарии; PAT для Confluence с правом читать документацию; PAT для GitLab с правом создавать ветки и merge request. Принцип один: выдавать только те права, без которых роль не работает.
Проверки для репозиториев добавляют второй барьер. До появления merge request код проходит линтеры, тесты и другие проверки проекта, и агент видит результат в логах. Если проверка падает, это видно в задаче, а не выясняется на ревью.
Оговорка: точные названия scope и порядок выдачи PAT в доступном фрагменте источника не раскрыты. Перечисленные права - рамка для настройки, сверять конкретные области доступа нужно с документацией Jira, Confluence и GitLab.
Очередь заданий: зачем PostgreSQL и Redis
Задания из Jira попадают в очередь. PostgreSQL хранит состояние заданий, Redis используется для очереди. Роли разделены просто: база отвечает за то, чтобы задание не потерялось и его статус можно было показать, Redis за быструю передачу заданий воркерам.
Зачем это нужно на практике: несколько агентов и задач работают одновременно, процесс может перезапуститься, статусы должны оставаться прозрачными, а упавшее задание нужно повторить. Без очереди задание, пришедшее в момент падения процесса, просто исчезло бы вместе с контекстом.
Детали схемы таблиц, формат заданий и настройки Redis в доступном фрагменте источника не раскрыты, поэтому описываем роль компонентов на уровне архитектуры. Конкретную реализацию придётся проектировать под свой контур и нагрузку.
Смежная задача - хранить состояние между запусками и разными агентами. Как это устроено в открытом проекте Later Bender с задачами, runbook'ами и временными средами, разобрано отдельно.
Токеномика: из чего складывается стоимость задачи
Честная рамка: автор кейса пока не измерял полную стоимость одной принятой задачи. Цифру «столько-то за merge request» из этого разбора взять нельзя, и притворяться, что она есть, смысла нет.
Что формирует расход токенов: объём собранного контекста (Jira, Confluence, репозитории), длина и детализация описания, число итераций, прогоны тестов и проверок, повторные запуски после замечаний на ревью. Отдельная строка - работа сверх задачи. В демо агент сам решил обновить документацию и открыл второй merge request, это тоже токены.
Стоимость ревью в токенах не измеряется вообще. Час инженера на разбор MR часто дороже генерации, и именно он определяет экономику схемы. Считать нужно время до принятого и поддерживаемого изменения, а не цену одного прогона модели.
Ревью как узкое место: что остаётся человеку
После работы агента за человеком остаётся ревью merge request. Агенты открывают MR быстрее, чем команда успевает их разбирать, и узким местом становится ревью, а не разработка. Очередь растёт, контекст задачи выветривается, качество проверки падает.
Что с этим делать: ограничить поток задач и держать один-два параллельных MR на агента, отдавать oneshot с критериями приёмки, требовать макеты и ссылки на документацию, фиксировать целевое время ревью и не копить merge request до конца недели.
Агент не мержит сам. Такую границу выбрали осознанно: последнее слово в MR остаётся за человеком, и это условие стоит сохранять при любом масштабировании схемы.
Про то, где ИИ в разработке реально ускоряет, а где создаёт иллюзию продуктивности, есть отдельный разбор AI в цикле разработки и границ применимости.
Кому подходит и с чего начать: практические выводы
Схема подходит для ограниченных oneshot-задач и подготовки требований: кнопки, формы, правки, черновики User Story. Для задач с открытыми продуктовыми решениями агент упрётся в нехватку контекста и остановится на вопросах, и это нормальный сценарий, а не сбой.
Чек-лист старта:
- Завести отдельные учётные записи для фронтенд-разработчика, бэкенд-разработчика и аналитика.
- Выдать минимальные PAT для Jira, Confluence и GitLab, личные токены не использовать.
- Настроить проверки для репозиториев и запрет прямых коммитов в защищённые ветки.
- Поднять очередь заданий на PostgreSQL и Redis, чтобы задания не терялись при перезапусках.
- Начать с одной-двух oneshot-задач с подробным описанием, критериями приёмки и макетами в Figma.
- Договориться о времени ревью и лимите одновременных merge request.
Ограничения стоит проговорить до запуска: без макетов в Figma или детального описания результат будет технически рабочим, но не в дизайне; полная стоимость принятой задачи не измерена; ревью остаётся за человеком и может стать узким местом всей схемы.
Первый шаг простой: возьмите одну небольшую задачу с готовым макетом, заведите под неё отдельного исполнителя и сравните время до принятого MR с ручным выполнением. Это даст вашу собственную цифру стоимости, которой в описанном кейсе пока нет.