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