Игорь Кузнецов из компании Kaiten собрал систему из тринадцати ИИ-агентов и поручил ей продуктовые и айтишные задачи. Не одного помощника, а команду с ролями: аналитик, бэкенд-разработчик, фронтенд, тестировщик, критик, прототипировщик, маркетолог, DevOps.
Агенты распределяли работу между собой, проверяли результаты друг друга и вели всё это в обычном таск-трекере — том же, где работают живые сотрудники.
За десять дней через эту команду прошло двенадцать проектов: три технических и девять деловых. Создано около 218 задач, закрыто примерно 207. Реализовано 24 функции, из них 23 доведены до конца. Типичная функция — от одного до трёх часов от постановки до готовности.
Цифры впечатляют, поэтому сразу разберём и вторую часть — во что это обошлось и где сломалось.
Чем команда ИИ-агентов отличается от одного помощника
Один ИИ-помощник — история понятная: вы формулируете задачу, получаете результат, проверяете. Команда агентов устроена иначе, и разница не в количестве.
Во-первых, они распределяют работу между собой. Аналитик разбирает задачу, прототипировщик собирает черновик, разработчик доводит, тестировщик проверяет. Человек не расписывает каждый шаг — он ставит задачу целиком.
Во-вторых, и это интереснее, они проверяют друг друга. В составе есть отдельная роль критика, чья работа — искать проблемы в том, что сделали остальные. Механика, которая заметно повышает качество: одна модель редко замечает собственные ошибки, но неплохо находит чужие.
В-третьих, всё происходит внутри рабочей системы компании, а не в переписке. Задача создана, назначена, выполнена, задокументирована — как если бы это делали люди. Руководитель видит происходящее там же, где видит работу живой команды.
Чего это стоило
Теперь честная часть, за которую автору отдельное уважение — он её не спрятал.
Расход вырос в два-три раза по сравнению с обычной работой в чате. Логично: агенты переписываются между собой, перепроверяют друг друга, уточняют. Каждое такое действие оплачивается. Считать бюджет по цене диалога с помощником в этой схеме нельзя — умножайте минимум втрое.
Агенты не умеют оценивать сроки. Спросить, сколько времени займёт задача, и получить достоверный ответ не выйдет. Для планирования это существенно: система работает быстро, но непредсказуемо.
В автономном режиме принимают решения сами. Без согласования, без вопроса «а точно так?». Ровно та проблема, которую я разбирал в статье про то, где ломаются агентные проекты: если граница записана словами, а не механикой, рано или поздно её перейдут.
Бэклог растёт быстрее, чем разгребается. Неожиданный эффект: когда задачи создаются легко и быстро, их становится очень много. Часть остаётся незакрытой, и куча нерешённого копится с той же скоростью, с какой раньше копилась медленно.
Где остался человек
Самое ценное наблюдение из всего разбора — автор не ушёл из процесса. Он остался в трёх точках.
Постановка задачи. Ревью прототипа. Одобрение выкладки.
То есть человек участвует там, где решается, что делать и можно ли это выпускать. Всё операционное между этими точками делают агенты.
Формулировка, которой автор описывает результат, мне нравится больше всего: это не полная автоматизация, а переход от ежедневного хаоса к управляемости. Не «меня заменили», а «я перестал тонуть в мелочах и занялся решениями».
Разница принципиальная, и её стоит держать в голове всем, кто мечтает о команде агентов вместо отдела. Тринадцать агентов не заменили руководителя — они заменили ту часть работы, где он был передаточным звеном.
Что из этого применимо в обычной компании
Кейс технический, но три вывода переносятся куда угодно.
Разделение ролей работает лучше универсального помощника. Один агент, который умеет всё, справляется хуже, чем несколько узких. Причина простая: у каждого своя инструкция, свой контекст, своя зона ответственности — и меньше шансов, что задачи перепутаются. В обычной компании это выглядит так: один агент разбирает входящие письма, другой готовит документы, третий проверяет их на ошибки.
Проверяющий агент — дешёвый способ поднять качество. Отдельная роль, которая только ищет проблемы в чужой работе. Стоит копейки по сравнению с ущербом от ошибки, дошедшей до клиента.
Всё должно жить в вашей рабочей системе. Не в чате, не в отдельном интерфейсе, а там, где вы и так смотрите за работой. Иначе через месяц никто туда не заглянет.
Кому подойдёт команда агентов, а кому рано
Скажу прямо: описанный кейс — про компанию, где технические люди уже есть и умеют такое собирать. Малому бизнесу без ИТ-команды воспроизвести это самостоятельно не выйдет.
Разумный порядок для остальных — обратный. Не собирать команду из тринадцати агентов, а взять один процесс, где задача повторяется десятки раз в месяц, и довести его до конца. Когда он заработает и вы увидите цифру, добавить второй. Многоагентные схемы имеют смысл там, где отдельные процессы уже работают и их нужно связать.
Если же вы хотите именно такую систему — считайте не только разработку, но и расход на работу агентов между собой, с поправкой в два-три раза. И сразу закладывайте те самые три человеческие точки: постановка, приёмка, разрешение на выпуск. Без них вы получите не управляемость, а быстро растущую кучу задач, которые никто не проверял.