AI-команда = офлайн-команда?
Как я собрал команду ИИ-агентов для разработки: роли, тимлид-оркестратор, обучение на ошибках и ревьюер на другой модели.
Если вы слышали про «Claude Code», «AI-агентов» и прочие модные штуки — скорее всего, вы уже пробовали хотя бы базово встроить их в свою работу. Кто-то пошёл дальше и начал строить целые AI-команды, которые проходят полный цикл от задачи до результата. А кто-то пока только присматривается — и это нормально. Эта статья будет полезна всем.
Сегодня не существует единого «правильного» способа выстроить агентную систему. Всё зависит от вашей задачи, инструментов и готовности экспериментировать. Именно поэтому в процессе неизбежно возникают нетривиальные ситуации, которые непонятно как решать.
В этой статье я провожу параллель между AI-командой и реальной командой разработки: расскажу, с какими проблемами сталкиваюсь сам и как их решаю.
Глава 1. Теперь ты HR
Итак, ты стоишь у порога создания своей AI dream team. Первый и самый важный вопрос: кто именно тебе нужен?
Это так же критично, как и при найме живых людей. Если создать 20 агентов без чёткого распределения ролей, ты утонешь в хаосе: кто что делает, кто за что отвечает, почему вот этот агент залез в чужую область — непонятно. Создать 20 агентов технически ничего не стоит, но мы за осознанный подход.
Я строю команду для разработки, поэтому мой состав выглядит так:
- Backend-разработчик — пишет серверный код
- Frontend-разработчик — пишет клиентский код
- Ревьюер — даёт альтернативный взгляд на решения. Без него разработчик убеждён, что всё делает правильно, а кодовая база потихоньку деградирует
- QA — «глаза проекта»: проверяет, что всё работает хотя бы в пределах нормы
- Дизайнер — проводит ресёрч, предлагает цветовые решения, составляет дизайн-спецификации для разработчиков
Команда собрана. Все расселись по местам. Казалось бы, можно работать — но это только начало...
Глава 2. Теперь ты CEO
Спустя время, а иногда с первых же запусков, обнаруживаешь одну неприятную вещь: ты очень много делаешь руками.
Нужно вызвать одного агента, потом второго, объяснить каждому контекст, разобраться, почему один агент залез в зону ответственности другого, хотя казалось бы, всё настроено верно...
Решение очевидное: нужен тимлид.
Как Owner, ты должен формулировать требования и получать результат — не бегать по агентам с раздаточными материалами. Тимлид берёт на себя оркестрацию: знает, кого вызвать, в каком порядке и что им передать.
Для этого тимлиду прописывается чёткий пайплайн. В моём случае он выглядит так:
- 1.Тимлид получает абстрактное пожелание от меня
- 2.Структурирует его: формулирует понятное описание задачи, разбивает на таски
- 3.Передаёт задачу дизайнеру: ресёрч + дизайн-спека для фронтенда
- 4.Backend и frontend разработчики работают параллельно по своим задачам
- 5.Ревьюер проверяет код и формирует список замечаний
- 6.QA проверяет, что ничего не сломалось и не уехало
- 7.Тимлид собирает итоги и отчитывается о проделанной работе
Полный цикл замкнулся. Бинго. (или как говорят зумеры Vamos!)
Глава 3. Эволюция
Пайплайн работает, задачи выполняются — но ты начинаешь замечать паттерн: одни и те же ошибки повторяются от задачи к задаче.
Ты правишь настройки агента вручную, он перестаёт ошибаться... и через несколько задач возвращается к старому. Потому что он не научился — он просто один раз получил другую инструкцию.
Как заставить агентов учиться на своих ошибках без твоего постоянного вмешательства?
Самое простое и рабочее решение — black list: список запрещённых действий. Что-то вроде «если захочешь сделать ТАК — не делай. Делай вот так».
Механика: ревьюер, обнаружив системную ошибку, сам вносит запрет в «мозги» нужного агента. Без твоего участия. Агент делает ошибку → ревьюер фиксирует её в black list → агент больше её не повторяет.
После каждого ревью агент становится немного умнее. Это и есть эволюция агента.
Black list — примитивный, но эффективный механизм саморазвития команды. Особенно ценен тем, что работает автономно.
Глава 4. Чекист в здании
Представь: живая команда работает слаженно, атмосфера тёплая, все друг друга понимают с полуслова. Звучит хорошо — но это и есть корень проблем.
Когда команда долго работает вместе, взгляд замыливается. Люди привыкают к недостаткам друг друга и перестают их замечать. «Ну, это же Миша, он всегда так делает» — и ошибка проходит мимо ревью.
Решение из реального мира: пригласить специалиста со стороны. Он не знает ваших негласных договорённостей, не вписан в командную химию и смотрит на код свежим взглядом.
В AI-команде можно сделать то же самое — подселить ревьюера на другой модели.
Например, если основная команда работает на Claude, создай второго ревьюера на базе Gemini. Результат: количество резонных замечаний по коду заметно вырастет.
Почему это работает? Модели, обученные на разных данных и с разными архитектурными решениями, по-разному оценивают качество кода. То, что кажется нормальным одной модели, может быть явной проблемой для другой. Два взгляда с разных «углов обучения» дают более полное покрытие.
Глава 5. Первые конфликты
Оба ревьюера обучаются, делают перекрёстное ревью и подсвечивают друг другу слепые зоны. Звучит идеально — пока не начинается спор.
Один ревьюер считает, что правильно так. Второй — что по-другому. Оба аргументируют. Оба правы по-своему. И это может длиться бесконечно — ведь каждая модель обучена отвечать и аргументировать свой ответ, чего бы ей это ни стоило.
Нужен арбитр.
У меня эту роль играет тимлид. Когда он фиксирует, что ревьюеры зашли в петлю разногласий, он запускает исследование: вертикальный и горизонтальный ресёрч по спорному вопросу, анализ аргументов обеих сторон — и выносит решение, кто прав.
Итог
Вот что получается в результате:
- Команда работает по чёткому пайплайну
- Тимлид оркестрирует процесс и держит тебя в курсе
- Агенты учатся на ошибках через black list
- Разнородные ревьюеры дают более качественную обратную связь
- Конфликты разрешаются через тимлида, а не зависают в вечном споре
В этом процессе много чего есть, что можно улучшать. Но именно такой каркас позволяет AI-команде работать автономно, без постоянного вмешательства.
А это, собственно, и есть цель.
Частые вопросы
- Сколько агентов нужно в команде?
- Столько, сколько ролей вы реально можете описать и развести по зонам ответственности. Двадцать агентов без распределения ролей превращаются в хаос: непонятно, кто что делает и почему залез в чужую область.
- Зачем агентной команде тимлид?
- Чтобы не вызывать каждого агента руками и не объяснять контекст по кругу. Тимлид получает задачу от вас, разбивает её на таски, вызывает нужных агентов в нужном порядке и собирает итог.
- Как заставить агента не повторять одну и ту же ошибку?
- Завести black list — список запрещённых действий в настройках агента. Ревьюер сам вносит туда системную ошибку, когда её обнаружит, и агент перестаёт её повторять без вашего участия.
- Зачем второй ревьюер на другой модели?
- Модели обучены на разных данных и по-разному оценивают качество кода. То, что одна считает нормой, другая подсветит как проблему — покрытие замечаний заметно растёт.