Не нанимайте AI-агентов на человеческие должности
Почему агентную разработку нужно строить вокруг процесса, а не вокруг ролей.
Самая большая ошибка, которую я вижу при внедрении агентной разработки, — попытка заменить каждого человека отдельным агентом.
Был бэкендер — сделаем агента-бэкендера. Был фронтендер — создадим агента-фронтендера. Был бизнес-аналитик — добавим агента-аналитика. Потом посадим над ними агента-тимлида, заставим их передавать друг другу задачи и получим цифровую копию привычной команды.
Выглядит логично. Иногда даже начинает работать. Именно поэтому ошибка так хорошо маскируется.
Но довольно быстро процесс начинает хромать: агенты пересказывают друг другу контекст, плодят документы, спорят о границах ответственности и теряют смысл задачи на переходах. Получается виртуальная компания, которая проводит виртуальные совещания, хотя могла просто довести задачу до проверенного результата.
Проблема в исходной единице проектирования. Мы проектируем агентов, а нужно проектировать процесс.
Копирование команды кажется естественным
Мы привыкли мыслить должностями. Любой рабочий процесс в компании уже разложен между людьми: аналитик собирает требования, архитектор проектирует решение, разработчики пишут разные части системы, тестировщик проверяет результат.
Когда появляется новая технология, проще всего поставить её на место существующего человека. Поэтому первый вопрос звучит так:
Кого из сотрудников может заменить этот агент?
Но человеческая оргструктура возникла из человеческих ограничений. Один специалист не может одинаково глубоко знать всё. Людям нужны зоны ответственности, рабочие часы, встречи, согласования и передача контекста. Разделение на профессии помогает управлять знаниями, доступами и ответственностью.
У AI-агента другой набор ограничений:
- размер и качество доступного контекста;
- набор подключённых инструментов;
- права доступа;
- стоимость и время выполнения;
- вероятность ошибки;
- возможность проверить полученный результат.
Если механически перенести в агентную систему решение, придуманное для ограничений людей, мы унаследуем все старые передачи работы и добавим к ним ограничения языковых моделей.
Один термин «агент» обозначает две разные вещи
Одна из причин этой ошибки — само слово «агент». Им называют две принципиально разные вещи.
Первая — агентская программа. Например, Codex или Claude Code: среда, через которую модель читает репозиторий, запускает команды, работает с Git, открывает страницы, вызывает внешние инструменты и изменяет файлы. Такой агент способен действовать в информационной системе, а не только отвечать текстом.
Вторая — ролевая инструкция. «Ты бизнес-аналитик», «ты архитектор», «ты строгий ревьюер». Это не отдельный работник, а контекст, ограничения и ожидаемый формат результата для конкретного вызова модели.
Когда эти два значения смешиваются, роль превращается в воображаемого сотрудника. Мы начинаем рисовать ему должность, характер и место в виртуальной иерархии.
Но агентная разработка в первую очередь не про ролевую игру. Она про программу, которая способна выполнить действия и пройти управляемый путь от задачи до результата.
Как выглядит ролецентричный процесс
Представим простую задачу: добавить выгрузку счетов в CSV.
При копировании человеческой команды получается такая цепочка:
задача
→ агент-аналитик пишет требования
→ агент-архитектор пишет дизайн
→ агент-бэкендер меняет API
→ агент-фронтендер добавляет кнопку
→ агент-тестировщик составляет отчёт
→ человек пытается понять, можно ли это выпускать
На каждом переходе нужно пересобрать контекст. Каждый агент видит свой участок и старается качественно исполнить свою роль, но никто не отвечает за полный путь пользователя. При этом границы между «отделами» существуют только потому, что мы сами их нарисовали.
В результате система оптимизируется под убедительную имитацию работы команды, а не под доставку результата.
Как выглядит процессоцентричный подход
Начать нужно не с вопроса «какие агенты нам нужны?», а с определения готового результата:
Пользователь с нужными правами нажимает кнопку, получает корректный CSV, а мы можем доказать тестами, что данные, кодировка и ограничения доступа работают правильно.
После этого строится процесс:
зафиксировать результат и критерии приёмки
→ исследовать затронутые части системы
→ выбрать решение и оценить риски
→ изменить бэкенд и фронтенд
→ проверить права, данные и негативные сценарии
→ запустить тесты и собрать подтверждения результата
→ подготовить PR
→ передать человеку только решение, требующее его ответственности
Один агент пройдёт весь путь или понадобится несколько запусков — не принципиально. Важно, что они выполняют работу, а не изображают должности.
Прокрутите таблицу вправо →
| Критерий | Вокруг ролей | Вокруг процесса |
|---|---|---|
| Первый вопрос | Кого заменит агент? | Как задача дойдёт до готового результата? |
| Единица системы | Виртуальный сотрудник | Этап и его проверяемый выход |
| Разделение работы | По человеческим профессиям | По контексту, рискам и возможности проверки |
| Передача работы | Между каждой ролью | Только там, где нужна граница или контроль |
| Контроль качества | Отдельный агент-тестировщик | Проверки и подтверждения результата на всём маршруте |
| Участие человека | Менеджер виртуальной команды | Владелец цели, риска и финального решения |
Роли — лишний слой
Анализ, проектирование, реализация и проверка никуда не исчезают. Но это этапы работы, а не сотрудники.
Можно назвать каждый этап отдельной ролью, придумать для неё имя и посадить в виртуальный отдел. Но система от этого не приобретёт новых возможностей. В ней лишь появятся дополнительные границы, передачи контекста и координация между сущностями, которые мы сами создали.
Агенту не нужна должность, чтобы исследовать задачу, изменить код или проверить результат. Ему нужна сама задача, необходимые инструменты и понятный ожидаемый результат.
Поэтому не нужно сначала придумывать штат AI-сотрудников, а потом распределять между ними работу. Нужно описать работу и дать агенту её выполнить.
Не карета с мотором
Если просто прикрутить мотор к карете, она начнёт двигаться без лошади. Но её конструкция всё ещё будет подчинена старому способу движения.
Так же и с агентами. Можно заменить ими людей в существующей цепочке и получить локальную экономию. Но основной эффект появляется, когда мы убираем ненужные передачи работы, пересобираем контроль и проектируем весь путь с учётом возможностей нового исполнителя.
Для этого перед созданием очередного агента стоит ответить на пять вопросов:
- Какой наблюдаемый результат должен получить пользователь или бизнес?
- Какие данные, инструменты и решения нужны, чтобы к нему прийти?
- Какое состояние задачи необходимо сохранять между шагами?
- Какими проверками и доказательствами подтверждается результат?
- Где действительно требуется решение человека?
И только потом решать, как технически организовать выполнение: одним или несколькими запусками модели.
Главный принцип
Не нужно строить AI-отдел в миниатюре. Нужно построить процесс, рассчитанный на исполнителя, который умеет читать, рассуждать, работать с инструментами и проходить несколько традиционных функциональных границ.
Поэтому правильная единица проектирования в агентной разработке — не агент и не его должность.
Правильная единица проектирования — целостный, управляемый и проверяемый процесс от задачи до результата.
Не спрашивайте: «Какого специалиста мы заменим агентом?»
Спрашивайте: «Как теперь должен выглядеть весь путь до готового результата?»