Зачем вообще думать про оркестрацию
Когда в проекте один человек и три-пять ИИ-агентов, главная ошибка — относиться к ним как к волшебной команде, которая сама разберётся с приоритетами. Не разберётся. Агент хорош ровно настолько, насколько чётко ему задана граница задачи и способ проверки результата. Без этого вы получаете не ускорение, а бесконечный цикл «сгенерировал — не подошло — переспросил».
Рабочая модель, которая на практике снимает половину боли: у каждого агента есть **одна роль, один контекст и один критерий приёмки**. Не «агент для кода» и «агент для текста», а конкретнее — агент, который пишет миграции базы данных и ничего больше; агент, который правит текст лендинга под тон бренда; агент, который гоняет тесты и репортит регрессии. Чем уже роль, тем меньше галлюцинаций и тем проще проверить результат за 30 секунд, а не за 30 минут.
Как делить задачи между собой и агентами
Практический принцип разделения: **агентам — то, что проверяется быстро и объективно; себе — то, что требует вкуса и контекста, которого у модели нет.**
Что обычно отдаётся агентам без риска: - Черновой код по чёткой спецификации (функция, эндпоинт, компонент с описанным интерфейсом). - Рефакторинг и переименования — механическая работа, которую легко diff'ом сверить. - Первый драфт документации, changelog, коммит-сообщений. - Прогон тестов, линтеров, поиск багов по логам. - Исследование — сравнить три библиотеки, собрать плюсы-минусы, дать таблицу.
Что стоит оставлять за собой: - Финальное решение по архитектуре и по тому, что вообще не делать (агент почти никогда не скажет «эта фича не нужна»). - Тон и позиционирование продукта — здесь у модели нет вашего опыта общения с пользователями. - Приоритизация бэклога — агент оптимизирует под «сделать что просили», а не под «что принесёт деньги». - Ревью перед мержем в прод, особенно там, где ошибка дорога (платежи, авторизация, данные пользователей).
Хороший ориентир: если ошибку агента можно поймать автотестом или беглым чтением диффа — доверяйте. Если для проверки нужно снова включать голову на том же уровне, что и для написания — не выиграли время, выиграли иллюзию.
Где ИИ реально помогает
- **Параллелизация рутины.** Пока один агент гонит миграцию базы, второй пишет тесты к уже готовому модулю, третий обновляет документацию. Соло-фаундер физически не может делать три вещи одновременно — агенты могут, если задачи независимы.
- **Снижение порога входа в незнакомую область.** Нужен минимальный конфиг Nginx или скрипт на Bash, которого вы не писали три года, — агент даёт рабочий черновик за минуту, вы правите под свой случай.
- **Первый проход по объёму.** Обработать полсотни тикетов саппорта, вытащить из них паттерны жалоб — то, что руками займёт день, агент делает за обозримое время с приемлемой точностью, если задать формат ответа.
- **Постоянный ревьюер.** Отдельный агент-критик, который читает дифф перед коммитом и ищет очевидные проблемы, — дешёвая страховка, снижающая число регрессий примерно вдвое по ощущениям тех, кто так работает.
Где ИИ мешает и как это лечится
- **Ложная уверенность в неточных областях.** Агент с одинаковой уверенностью выдаст рабочий SQL-запрос и несуществующий метод API. Лечится жёстким правилом: любое обращение к внешнему API или библиотеке — сверять с актуальной документацией, а не с памятью модели.
- **Раздувание контекста.** Если агент видит весь репозиторий сразу, он начинает «улучшать» то, что его не просили трогать. Ограничивайте контекст конкретными файлами и явно пишите «не трогай остальное».
- **Накопление технического долга без присмотра.** Быстрый код от агента решает задачу, но не всегда учитывает, как она впишется в архитектуру через месяц. Раз в одну-две недели нужен отдельный проход — «ревью долга», а не только ревью фич.
- **Цикличные самоисправления.** Агент, которому дали чинить свой же баг несколько раз подряд, иногда уходит в сторону от исходной задачи, наращивая изменения. Ставьте лимит в две-три попытки, дальше — разбираться самому.
Чек-лист перед тем, как поручить задачу агенту: понятна ли граница задачи? Есть ли объективный критерий готовности? Что случится, если агент ошибётся — это дорого или дешево исправить? Если хотя бы на один вопрос ответа нет, задача пока не для делегирования.
Оркестрация агентов — это не про то, чтобы меньше работать головой. Это про то, чтобы голова тратилась на решения, а не на набор текста.</content>
