AI-агенты как исполнители в Jira — серверный harness вместо локального
Саммари
Автор описывает рабочую систему, в которой три AI-агента (фронтенд, бэкенд, аналитик) числятся обычными исполнителями в Jira: задача ставится через Assignee, серверный harness собирает контекст, запускает агента, готовит merge request'ы и возвращает задачу в статус «На ревью». Людей система не заменяет — ревью, ответы на вопросы и финальное слово остаются за человеком, а агентам достаются oneshot-задачи и подготовка требований. Материал ценен тем, что показывает готовую схему встраивания агентов в уже существующий трекер и документацию без замены процессов и инструментов команды.
Из этого следует, что интеграция агентов в бизнес-процесс делается не новым трекером и не отдельным чат-ботом, а адаптером поверх существующих систем: поле Assignee работает как универсальный API постановки задачи, знакомый любой команде.
На практике: сохранение версий источников (требования, инструкции, коммиты) вместе с заданием — переносимый приём для любых агентных пайплайнов, включая Revit-автоматизацию, где вопрос «на чём основан результат» решает доверие к автоматизации.
Важный нюанс: остановка «Ожидает ответа» с рекомендованным вариантом ответа — дешёвый human-in-the-loop: агент не додумывает за человека, но и не возвращает пустой запрос на уточнение.
Ограничение подхода: автор не измерил полную стоимость принятой задачи (токеномика считает только инференс, серверная инфраструктура, поддержка harness и время ревью не учтены), а узким местом легко становится поток MR — раньше один MR в день, теперь тридцать.