Агентская разработка и выручка: где бизнес получает эффект

Раньше слово «прорыв» обычно сопровождало новости из медицины или науки. Теперь его примеряют к будням диджитал-команд. Агентская разработка обещает ускорить путь от идеи до работающего продукта. ИИ-агент пишет код, запускает проверки и помогает собрать прототип. Для одних это игрушка, другие рассчитывают брать больше проектов и повышать выручку.

Вот только кто уже успел на этом заработать? Мы задали вопрос Михаилу Сарычеву, генеральному директору IT-компании DBI, чья команда внедрила агентов в работу. Он не стал выдавать быстрый прототип за доказанную прибавку к выручке. Зато объяснил, где компания уже видит эффект и какие цифры ещё предстоит собрать.

Что меняется, когда идею можно показать

Обычное техническое задание описывает будущий продукт словами. Оно необходимо для договорённостей, но не всегда передаёт ощущения пользователя. Формулировка «удобная форма заявки» ничего не говорит о том, какие поля человек увидит первыми, как исправит ошибку и когда получит подтверждение. Разработчики выполнят написанное, а заказчик при приёмке обнаружит, что имел в виду другое.

Быстрый прототип превращает часть этого разговора в проверку. Например, команда собирает один путь от открытия формы до отправки заявки. Заказчик проходит его как пользователь и замечает, что для ответа менеджеру не хватает номера заказа, а обязательное поле требует данных, которых у клиента ещё нет. Эти замечания меняют требования до того, как они разойдутся по интерфейсу, серверной логике и интеграциям. Прототип может быть временным и не обязан становиться основой продукта; его задача — обнаружить расхождение в ожиданиях.

Такую пользу описывает Михаил Сарычев, генеральный директор IT-компании DBI. Его команда пока не заявляет, что внедрение агентов увеличило выручку: проектов недостаточно для такого вывода. Зато в работе с заказчиками она видит эффект от раннего прототипирования.

Михаил Сарычев

Генеральный директор IT-компании DBI

Честный ответ на вопрос «удалось ли повысить выручку» на сегодня такой: измерить влияние агентской разработки на стоимость проектов мы пока не можем.Читать весь комментарий →

Выборка ещё мала, а методики учёта для таких проектов только формируются. Зато ценность мы видим уже сейчас, и она не в скорости написания кода.

Главный эффект — прототипирование до начала основной разработки. Классическая проблема любого ИТ-проекта: заказчик описывает задачу словами и держит в голове одну картинку, команда инженеров читает ТЗ и собирает другую. Два набора фантазий, изложенных разными словами, неизбежно расходятся, и это выясняется на приёмке, когда исправления стоят дороже всего. Агентская разработка позволяет за считаные дни показать заказчику работающий прототип вместо документа. Спорить о формулировках больше не нужно: можно посмотреть, потрогать и сказать «вот здесь не так». Заказчик и исполнитель сближаются ещё до старта дорогой фазы, и затраты на переделки заметно снижаются. Это реальный, а не маркетинговый эффект.

Второй вывод, который мы для себя сделали: ИИ — зеркало того, кто им пользуется. Агент усиливает компетенцию инженера, а не заменяет её. Сильный специалист ставит корректную задачу, задаёт архитектурные рамки, видит ошибки в сгенерированном коде и понимает, что уйдёт в продуктив. Слабый получает большой объём правдоподобного кода, за качество которого никто не отвечает. Поэтому результат определяется не выбором инструмента, а уровнем инженера, который с ним работает. Это, на мой взгляд, главная причина, по которой одни компании получают эффект, а другие разочаровываются.
Что не получилось: ожидание, что агент сам сократит команду и сразу даст экономию. На практике время перераспределяется. Меньше уходит на рутинное кодирование, больше на постановку задач, ревью и верификацию. Экономия появляется там, где процесс выстроен, а не там, где инструмент просто выдали.
Вывод: агентская разработка сегодня даёт сближение заказчика и исполнителя, ранний feedback и снижение стоимости ошибок. Прямую выручку от неё пока считать рано, но выигрывают те, у кого сильные инженеры и выстроенный процесс.

В ответе Михаила Сарычева есть полезное для договора с подрядчиком различие. Демонстрация прототипа позволяет согласовать поведение продукта. Оценка денежного результата требует отдельного измерения: раннее согласование само по себе не доказывает, что компания получила больше заказов или продала их дороже.

Как посчитать эффект без красивой, но бесполезной цифры

Самый соблазнительный показатель — сколько времени агент сэкономил на написании кода. Для бюджета проекта он слишком узкий. Инженер мог закончить экран раньше, но затем потратить освободившиеся часы на проверку сценариев, исправление ошибок, согласование данных и развёртывание. Итог зависит от всего пути до принятого результата, а не от одного этапа.

Для начала зафиксируйте границы пилота. Возьмите повторяемый тип задачи, например внутренний отчёт или небольшой интерфейс, и сравнивайте сопоставимые задания. Считайте время от постановки до принятия заказчиком, часы инженеров по ролям, число возвратов на доработку и причины этих возвратов. Отдельно записывайте расходы на инструмент, инфраструктуру и проверку безопасности. Тогда сокращение времени на кодирование не спрячется за выросшим временем ревью.

При оценке переделок полезно отмечать, когда обнаружилась проблема. Ошибка, найденная на прототипе, и та же ошибка после интеграции с рабочими системами требуют разного объёма работы. Но разницу не нужно подменять универсальным коэффициентом. У каждой команды свои зависимости, процессы согласования и цена простоя. Лучше собрать журнал изменений по собственным проектам, чем умножить часы на эффектную цифру из чужой презентации.

Выручка — ещё более дальняя метрика. Если продукт вышел раньше, компания могла быстрее начать продажи или получить обратную связь от клиентов. Чтобы приписать изменение выручки агентской разработке, понадобится отделить этот вклад от рекламы, сезонности, цены и изменений самого предложения. На небольшом числе проектов это часто невозможно. Отчёт в таком случае показывает сокращение цикла согласования и стоимость переделок, а рост продаж оставляет открытым вопросом.

Исследование DORA о разработке с ИИ описывает технологию как усилитель уже существующих достоинств и слабостей организации. Это созвучно наблюдению Михаила Сарычева: если правила постановки задачи и проверки результата размыты, ускоренная генерация кода ускорит и накопление неопределённости. Исследование не позволяет переносить готовый процент экономии на конкретный проект DBI или любого другого подрядчика.

Почему готовый код ещё не готовый продукт

Представьте агента, которому поручили добавить кнопку выгрузки отчёта. Он может быстро создать интерфейс, обработчик и файл. Но у кнопки остаются вопросы, которые не помещаются в короткую команду: кто имеет право скачивать данные, как долго хранится выгрузка, что происходит при пустом результате и какую нагрузку выдержит сервер. Код может выглядеть убедительно, даже если ответы на эти вопросы неверны.

Поэтому инженер задаёт рамки до запуска агента и проверяет работу после него. Рамки включают доступные файлы, ожидаемый сценарий, ограничения по данным и критерии готовности. Проверка включает просмотр изменений, тесты, поведение на ошибочных входных данных и согласование с архитектурой проекта. Разработчик остаётся человеком, который отвечает за решение и понимает, куда оно попадёт после релиза.

Документация GitHub по агентам Copilot прямо предупреждает, что сгенерированный код может быть некорректным или небезопасным и требует человеческой проверки. Время на ревью здесь не досадная помеха экономии. Оно часть работы, без которой быстрый черновик может обернуться дорогим исправлением в рабочем сервисе.

Проверять стоит и границы доступа самого инструмента. Если агенту для маленькой задачи открыли весь репозиторий, продуктивную базу и ключи от внешних сервисов, цена ошибки растёт. Для пилота достаточно минимального набора данных и разрешений, которые действительно нужны для выбранного сценария. Так проще понять результат и найти причину отклонения, если он появится.

С чего начать заказчику

Попросите подрядчика показать до основной разработки полный путь пользователя от действия до результата. Запишите, какие решения прототип должен помочь принять: состав полей, порядок шагов, права доступа или способ передачи данных. Сразу договоритесь, что будет переделано после проверки, а что останется экспериментом.

Затем спросите, кто принимает технические решения и проверяет работу агента. Название инструмента в этом разговоре менее полезно, чем фамилия ответственного инженера и записанные критерии приёмки. Если подрядчик обещает экономию, попросите показать базовый сценарий сравнения и полный состав затрат. Скидка на часы кодирования мало говорит о проекте, если не названы часы постановки задачи, проверки и исправлений.

На первой встрече удобно согласовать три контрольные точки: прототип, решение о дальнейшей разработке и приёмку готовой функции. После каждой фиксируйте, что изменилось в требованиях и сколько времени заняло изменение. Так у команды появятся собственные данные, а не спор о том, насколько умным оказался агент.

Быстрый код ценен, когда помогает раньше увидеть неверное предположение. Если прототип вовремя показал, что заказчик и разработчик представляют разные продукты, он сберёг время переделки. А вопрос о выручке стоит задавать позже — когда появятся сравнимые проекты, заранее записанная методика учёта и результаты продаж.

Ранее Brokerlist разбирал, из чего складывается стоимость внедрения ИИ в компании. Эти расходы стоит включить и в расчёт агентской разработки.