10+ ИИ-агентов на Claude Code и Kaiten: опыт директор ИТ-компании
Как собрать ИИ-команду и передать ей рутину — на примере эксперимента участника сообщества Kaiten
«А что если заменить целую команду ИИ-агентами?» — этим вопросом в конце декабря прошлого года задался Игорь Кузнецов, директор компании «Эрегион» и давний пользователь Kaiten. Вместо отдельных экспериментов с нейросетью он решил собрать полноценную систему, где агенты будут сами назначать задачи, распределять работу и проверять результат.
Дальше покажем, как Игорю удалось превратить обычные чаты с ИИ в управляемый конвейер из агентов и таск-трекера.
От обычного чата с LLM — к команде агентов
Команда «Эрегиона» начала активно использовать LLM почти год назад. Сначала все работало привычно: задача в чате → результат → проверка ошибок → правки → новый результат. И дальше по кругу. Так появились первые экспериментальные продукты — LMS-система, сервис транскрибации и другие небольшие проекты.
Но даже когда основную работу выполнял ИИ, управление все равно оставалось на человеке. Нужно было проверить результат, сформулировать следующий шаг, передать новый промпт и снова проконтролировать выполнение.
Так появилась идея собрать ИИ-процессы в таск-трекере.
Первым инструментом стал Linear
На старте агентов подключили к Linear через MCP — там они могли напрямую обращаться к трекеру через API, читать карточки, создавать новые и менять их статусы.
Однако со временем проявились два ограничения:
- Стало не хватать карточек. На бесплатном тарифе Linear доступно до 250 задач. Агенты быстро расходовали лимит, потому что подробно разбивали одну функцию на несколько отдельных карточек.
- Гибкости процессов тоже было недостаточно. Статусы в Linear привязаны к системным категориям Backlog, Unstarted, Started, Completed и Canceled. Команде же нужно было по-разному выстраивать этапы для разных проектов.
Для небольшого эксперимента Linear подходил, но для дальнейшей работы требовался более гибкий трекер.
Почему перенесли агентов в Kaiten
К тому моменту команда уже больше 2 лет работала в Kaiten: сначала вела там IT-проекты, а затем перенесла и часть бизнес-процессов.
Готового MCP-сервера для Kaiten тогда еще не было, поэтому команда написала собственный и подключила его к Claude Code.
Теперь Игорь отправляет агенту ссылку на карточку, а дальше тот работает самостоятельно: читает описание, выполняет задачу и фиксирует ход работы и результат в комментариях.
Так весь контекст остается в Kaiten. А если команда возвращается к задаче, например, через месяц, агент может открыть карточку и быстро восстановить, что уже сделано и на каком этапе остановилась работа.
Как агентам объяснили правила работы
Пока агентов было немного, инструкции можно было добавлять прямо в задачу. Но со временем появились разные проекты, роли и сценарии, а одни и те же правила приходилось повторять снова.
Чтобы этого избежать, команда собрала стандарты — общие инструкции для AI-агентов. Они описывают:
- как создавать новых агентов;
- как работать с карточками;
- как запускать проекты;
- как обсуждать задачу до начала работы;
- как вести бизнес-проекты.
Есть даже отдельный стандарт для создания новых стандартов.
При этом стандарты не определяют каждое действие заранее. Агент по-прежнему анализирует ситуацию и принимает решения самостоятельно. Но если случай выходит за установленные рамки, он должен запросить уточнение или создать отдельную задачу для человека.
Без таких ограничений, по опыту команды, автономность быстро превращается в непредсказуемость.
Для каждой задачи собирается своя ИИ-команда
Чтобы не использовать один и тот же набор агентов для всех проектов, команда создала реестр ролей. Сейчас в нем 13 специализаций: аналитик, бэкенд-разработчик, фронтендер, тестировщик, DevOps, маркетолог, прототайпер и другие. Под каждую задачу агент сам подбирает нужные роли из реестра. Например, для создания MVP это могут быть аналитик, бэкендер, фронтендер, тестировщик и DevOps.
При этом в каждом проекте у лида есть «противовес» — агент-критик. Он не выполняет задачу сам, а проверяет решения команды: ищет слабые места, неподтвержденные предположения и выводы, которые выглядят убедительно, но требуют дополнительной проверки.
Например, раньше нейросеть могла предложить название продукта, которое хорошо звучало, но уже было зарегистрировано как товарный знак. Теперь после такого предложения критик может потребовать проверить название в базе ФИПС.
Похожая ситуация возникла при подготовке маркетинговой стратегии. Агенты должны были разработать план продвижения по методологии Александра Бындю. Они определили аудиторию, каналы и метрики, а критик заметил, что у продукта еще нет понятной ценовой политики и полноценного лендинга.
Вместо того чтобы сразу переходить к контент-плану, команда сначала зафиксировала эти пробелы. По словам Игоря, в обычном диалоге с ИИ такой этап легко было бы пропустить и сразу перейти к генерации идей.
Как запускается новый проект
Все начинается с основной карточки в Kaiten.
Шаг 1. Игорь ставит задачу.В карточке он описывает ожидаемый результат, добавляет требования и ссылки на нужные стандарты.
Шаг 2. Агент изучает вводные.Игорь передает ему ссылку на карточку. Дальше агент работает в автомоде: сам разбирается в задаче и обращается к человеку только по критическим вопросам.
Шаг 3. Собирается команда.Агент определяет, какие специалисты нужны для проекта, и выбирает подходящие роли из реестра.
Шаг 4. Команда проверяет план.Лид предлагает решение, а критик ищет слабые места, спорные допущения и недостающие данные. Если нужно, план отправляется на доработку. Итоги обсуждения сохраняются в Kaiten.
Шаг 5. Проект раскладывается на отдельные задачи.Например, одна функция может превратиться в карточки для бэкенда, фронтенда и тестирования. Агенты сами создают дочерние задачи, берут их в работу, двигают по этапам и фиксируют результат в комментариях.
А для продуктовых проектов команда добавила отдельный этап проверки, чтобы не тратить время на дорогие переделки.
Сначала продуктовый агент и маркетолог готовят каркас и техническое задание, затем прототайпер собирает HTML-прототип. Человек проверяет его и фиксирует правки, и только после этого подключаются бэкендер, фронтендер и DevOps.
Так основные ошибки можно поймать еще на прототипе — до того, как команда начнет собирать полноценный MVP.
Что показали первые результаты
С 1 по 10 июля 2026 года ИИ-агенты:
- провели через процесс 12 проектов — 3 ИТ- и 9 бизнес-проектов;
- создали около 218 карточек, из них примерно 207 закрыла;
- завершили 23 из 24 функций;
- закрыли 106 из 107 задач разработки и все 23 задачи тестирования;
- выполнили 50 из 52 бизнес-задач.
Обычная задача разработки проходит путь от «В работе» до «Готово» примерно за 6–20 минут. На полноценную функцию с декомпозицией, разработкой и тестированием уходит от 1 до 3 часов.
Один из самых быстрых результатов команда получила на MVP «ЧМ-Прогнозы»: за один рабочий день агенты реализовали 9 функций, закрыли 17 задач разработки и провели приемочное тестирование. Бизнес-прототип той же игры подготовили примерно за полтора дня — все 10 задач прошли дополнительную проверку критика.
Где все еще нужен человек
Полностью выйти из операционки пока не получилось — человек по-прежнему подключается в нескольких ключевых точках:
- на старте, чтобы проверить постановку задачи и направление;
- при приемке прототипа, чтобы оценить результат и дать правки;
- перед запуском, чтобы принять финальное решение.
В остальное время проект может двигаться без постоянного контроля, а роль руководителя постепенно смещается от проверки каждого шага к разбору действительно важных вопросов.
Что пока работает неидеально
Эксперимент продолжается, и у системы остается несколько заметных ограничений:
Агенты плохо оценивают сроки. Если модель говорит, что работа займет 4 часа, задача в реальности может завершиться через 5 минут или, наоборот, потребовать несколько дополнительных часов. Поэтому такие оценки пока нельзя использовать для нормального планирования.
Много токенов уходит на взаимные проверки. Работа команды с критиком расходует примерно вдвое больше токенов, чем обычный чат. Несколько циклов проверки могут увеличить расход примерно втрое. Недельный лимит иногда заканчивается за 2–3 дня, поэтому команда перешла на более дорогой тариф Claude Code x20.
Один из следующих этапов эксперимента — создание мультимодельной схемы. Например, ресерч можно отдавать ChatGPT, разработку оставлять Claude Code, а обмен организовать через OpenRouter и n8n. Так не все задачи будут расходовать лимит одной модели.
Автомод требует доверия. Чем больше самостоятельности получает агент, тем выше вероятность неожиданного решения.
Поэтому автомод работает только вместе со зрелыми стандартами и пониманием возможных рисков.
Нет единой системы тегов. Агенты используют теги по-разному, поэтому фильтрация пока получается не всегда последовательной.
Бэклог растет слишком быстро. Если агент не может закрыть задачу сам, по текущим правилам он отправляет ее в очередь. В результате незавершенных карточек постепенно становится все больше.
Чтобы решить эту проблему, в «Эрегионе» хотят добавить еще одну метрику — предполагаемый расход токенов на задачу. Его можно записывать в поле «Размер» карточки Kaiten, чтобы при планировании сразу видеть, какие задачи запускать сейчас, а какие оставить в очереди.
Что показал эксперимент
Главный результат эксперимента не в том, что человек полностью исчез из процесса. Система пока далека от решения, которое можно включить одной кнопкой. Для ее сборки нужны технические навыки, время на настройку стандартов и готовность постоянно проверять новые сценарии.
Но опыт «Эрегиона» показывает другой важный момент: ИИ-агенты могут работать не только внутри отдельного диалога с моделью.
Если дать им роли, правила, общий контекст и трекер, они могут самостоятельно вести заметную часть проекта — создавать задачи, передавать работу друг другу, проверять результаты и оставлять человеку только те точки, где действительно требуется его решение.
В этой схеме Kaiten стал не только доской для наблюдения за агентами, но еще и местом, где хранится память всей системы: задачи, стандарты, результаты и история принятых решений.
