Как агентная разработка меняет организацию команды
Статья рассматривает условный сценарий: AI-контур воспроизводимо ускоряет реализацию без ухудшения качества, и команде приходится заново искать ограничение потока и распределять ответственность.
Вместо вопроса «каких людей теперь заменить?» полезнее сначала измерить, как изменился поток работы. Если на сопоставимых задачах AI-контур сокращает время реализации и части проверок, а качество и стоимость принятого изменения остаются приемлемыми, очередь может переместиться к исследованию проблемы, выбору решения и формированию требований.
Одновременно команда начинает обслуживать сам способ производства изменений: поддерживать актуальный контекст, доступы, правила, критерии приёмки, оценочные прогоны и границы автономии. В этой статье такой управляемый способ работы называется AI-контуром.
Три схемы показывают исходный процесс, ограниченный пилот и возможное зрелое состояние. Из них выводятся изменения в работе аналитика, разработчика, специалиста по качеству (QA), владельца продукта и руководителя разработки.
В начале: один контур создания ПО
На слайде есть два разных уровня. Зелёный блок — целевая система, то есть разрабатываемое приложение. Пунктирная рамка — система создания и изменения ПО: люди, правила и инструменты, с помощью которых команда меняет приложение.
В упрощённом исходном состоянии весь процесс находится в одном человеческом контуре. Аналитик формирует требования, разработчики реализуют изменение, QA проверяет результат. Схема не утверждает, что именно разработка ограничивает поток в каждой команде.
В рассматриваемом сценарии очередь стоит перед разработкой: идеи и требования уже подготовлены, а инженеры и QA заняты предыдущими задачами. Это исходное допущение модели, которое перед изменением процесса нужно проверить по данным конкретной команды.
Первое изменение: появляется AI-контур
Первое изменение можно проверить на одном повторяемом классе задач, не перестраивая отдел. Один разработчик использует кодового агента — AI-инструмент, который читает проект, изменяет файлы, запускает команды и проверки. Агент работает на основе большой языковой модели (LLM) и вместе с разработчиком образует ограниченный AI-контур. Контур выполняет часть реализации, а разработчик уточняет его правила, инструменты и проверки по результатам каждого прогона.
AI-контур шире отдельного агента или набора промптов. В него входят:
- контекст продукта, архитектуры и принятых решений;
- маршрутизация задач и права агента;
- спецификации, примеры и критерии приёмки;
- инструменты, проверки, оценочные прогоны (
eval) и цикл проверки; - точки, где решение должен принять человек;
- наблюдаемость качества, стоимости и повторяющихся сбоев.
Если знания о процессе остаются только у одного энтузиаста, возникает риск потерять результат вместе с его личными приёмами. Документация сама по себе воспроизводимость не гарантирует: её нужно проверять на сопоставимых задачах с одинаковыми критериями приёмки и фиксировать причины ручного вмешательства.
Возможное зрелое состояние: ограничение может переехать
На слайдах между пилотом и зрелым состоянием намеренно опущены промежуточные варианты. Переход к третьей схеме оправдан, только если измерения показывают повторяемое сокращение времени технического исполнения. Когда исследование и выбор решения не ускоряются в той же мере, очередь может сместиться к началу потока. В другой команде новым ограничением могут оказаться ревью, безопасность, эксплуатация, выпуск или доступ к пользователям.
Сокращение времени реализации может снизить техническую стоимость прототипа, но не обязательно полную стоимость проверки гипотезы. Ограничением могут остаться трафик, данные, поддержка, согласования или время наблюдения. При этом более быстрый выпуск позволяет так же быстро производить ненужные функции, поэтому скорость потока нужно сопоставлять с продуктовым результатом.
В этом сценарии фокус аналитика смещается к уменьшению неопределённости до реализации. Наблюдаемый результат его работы — понятная проблема, зафиксированные правила и ограничения, проверяемые примеры и связь решения с ожидаемым эффектом.
Что меняется у ролей
Слайды показывают только часть ролей. Таблица ниже — авторская экстраполяция модели на типичную продуктовую команду, а не буквальная расшифровка рисунков.
Прокрутите таблицу вправо →
| Роль | За что отвечает в этой модели | Какой результат можно проверить |
|---|---|---|
| Владелец продукта | Выбор проблемы, приоритета, ожидаемого эффекта и условия остановки гипотезы. | У задачи есть продуктовая метрика и заранее определённое решение для плохого исхода. |
| Аналитик | Исследование проблемы, моделирование правил и устранение неоднозначности до реализации. | Правила, ограничения и примеры согласованы и допускают однозначную проверку. |
| QA | Модель рисков, критерии приёмки, пограничные случаи и независимые проверки. | Доказательства покрывают ключевые риски, а непроверяемые решения переданы человеку. |
| Разработчик | Техническое решение, архитектурные границы, контекст и инструменты AI-контура. | Изменение проходит проверки, а повторяющийся сбой превращается в правило, инструмент или тест. |
| Руководитель разработки | Границы автономии и показатели производственного процесса. | Отслеживаются время прохождения задачи, дефекты, стоимость и причины ручного вмешательства. |
Это карта ответственности для проверки модели, а не новая должностная инструкция. Роли не становятся взаимозаменяемыми: QA не превращается автоматически в аналитика, а разработчик по-прежнему отвечает за понимание технического решения.
Как это выглядит в одной задаче
Ниже — целевой сценарий, а не доказательство эффективности модели. Представим изменение в личном кабинете: клиент должен выгружать отчёт в CSV. В исходной схеме бизнес приносит просьбу, аналитик пишет описание, разработчик меняет код, а QA проверяет результат перед релизом. Знание о формате выгрузки, правах доступа и пограничных случаях при этом может остаться распределённым по переписке и головам участников.
В целевой агентной схеме аналитик сначала уточняет, кто выгружает данные, какие поля разрешены, как обрабатываются пустые значения и каким наблюдением подтвердится польза. QA превращает риски в примеры и критерии приёмки. Разработчик определяет затронутые контракты и передаёт агенту необходимый контекст. Если задача подходит для выбранного уровня автономии, агент реализует изменение, запускает проверки и собирает доказательства. Разработчик и QA сосредотачиваются на решениях и рисках, которые процесс не может надёжно подтвердить автоматически.
После выпуска команда проверяет пользу выгрузки для пользователя и отдельно разбирает ручную помощь агентному процессу: не хватило правила доступа, примера формата, тестовых данных или инструмента. Повторяющийся сбой становится кандидатом на изменение контекста, проверки или оценочного прогона AI-контура. Команда принимает такое изменение только после проверки, что оно устраняет причину, а не маскирует единичный симптом.
При успешной проверке одна задача может улучшить и продукт, и производственный процесс. Продукт получает функцию, а AI-контур — проверенное изменение, полезное для следующей сопоставимой задачи.
Что не стоит делать
Из модели следуют три риска. Если сделать из каждого сотрудника универсального «оператора AI», может размыться ответственность за продуктовый выбор, риск и архитектурное решение. Если изолировать платформенную команду от продуктовых задач, у неё появляется риск улучшать внутренний инструментарий без связи с реальными сбоями и результатом продукта. Если измерять внедрение только числом запусков модели или строк кода, команда увидит активность, но не узнает, стало ли изменение полезным и надёжным.
Для пилота достаточно выбрать один повторяемый тип задачи, описать входы и критерии, зафиксировать исходные показатели, определить границы автономии и заранее назвать плохой результат, при котором эксперимент будет остановлен. После каждого прогона команда разбирает ручное вмешательство и дефекты. Несколько повторений — не отраслевой порог, а минимальная возможность увидеть, повторяется ли эффект; нужный объём пилота команда определяет до начала проверки.
Два связанных цикла улучшений
В терминологии этой статьи продукт остаётся единственной целевой системой: именно его состояние команда меняет ради пользовательского или бизнес-результата. AI-контур — производственная система, с помощью которой создаются изменения продукта. Поэтому команда управляет двумя связанными циклами, но не смешивает их результаты.
Продуктовый цикл отвечает на вопрос: решаем ли мы важную проблему и получили ли полезный результат?
сигнал → исследование → выбор → спецификация → релиз → проверка эффекта
Цикл развития AI-контура отвечает на другой вопрос: можем ли мы повторяемо и безопасно производить такие изменения?
сбой или лишняя ручная работа → причина → изменение контекста, инструмента или проверки
→ оценочный прогон → выпуск улучшенного процесса → наблюдение
Для продуктового цикла команда измеряет эффект изменения, для производственного — повторяемость, качество и стоимость его выпуска. Высокая скорость второго цикла не подтверждает ценность продукта, а сильная продуктовая гипотеза не подтверждает надёжность AI-контура.
Как не перепутать сдвиг с демонстрацией
Не меняйте оргструктуру после одного удачного запуска. Сначала задайте класс сопоставимых задач и проверьте, сохраняются ли время прохождения, качество, стоимость и уровень ручного вмешательства в нескольких прогонах. Актуальный контекст, понятные критерии и независимые проверки являются условиями пилота, но их наличие само по себе не доказывает воспроизводимость.
Смотрите на две группы сигналов:
- продукт: использование, конверсия, выручка, время операции, обращения в поддержку — тот показатель, ради которого затевалось изменение;
- поток и AI-контур: полное время прохождения задачи (
lead time), возраст очереди, дефекты после релиза, время ревью, стоимость принятого изменения, причины повторяющегося вмешательства человека.
Число сгенерированных строк или pull request (PR) само по себе не доказывает ни производительность, ни ценность. Оно может отражать более мелкую декомпозицию задач.
Есть и границы переноса. В регулируемых системах, системах с высокой ценой ошибки и плохо документированных старых продуктах независимой проверки может стать больше. Без доступа к пользователям и данным дополнительное время на исследование не создаст продуктового знания. Регулярное ручное спасение агента требует диагностики: причиной могут быть контекст, права и проверки, неподходящий класс задач, ограничения модели или архитектура продукта. Решение о развитии отдельного AI-контура принимается после этой диагностики, а не автоматически.
Главный вывод
После пилота главный вопрос звучит не «какая роль больше не нужна?», а так:
Где теперь ограничение потока — и кто отвечает за продукт и за развитие AI-контура?
Ответ помогает различить два результата: ценность изменения для продукта и измеренную повторяемость процесса, который это изменение выпускает.
Связанная авторская позиция: «Не нанимайте AI-агентов на человеческие должности» — о том, почему агентный процесс нужно проектировать вокруг проверяемого результата, а не вокруг виртуальных должностей.
Хотите внедрить это у себя?
Помогаю командам перейти на агентную разработку: как советник, через обучение команды или внедрение изменений с проверкой эффекта по данным. Короткие заметки между статьями выходят в Telegram-канале.