Агенты пишут код: как измерить эффект для команды

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

Теперь Владимир строит DevOptify и использует его в собственной команде. Его рабочий набор включает Cursor, Codex и Claude; Александр добавляет опыт сочетания разных моделей и переносимых инструкций. Здесь важен выбор инструмента под работу. Экономика подписки для отдельного инженера отличается от экономики продукта, который обращается к моделям через API. Удобство личного набора ещё не доказывает жизнеспособность такого же коммерческого решения.

Владимир описывает несколько попыток измерить результат внедрения AI в Сбере. Сначала команда считала долю сгенерированного кода. Руководство спросило, позволяет ли этот показатель уменьшить штат. Ответ оказался отрицательным: генерация текста программы объясняла только один участок работы. Затем перешли к числу PR на инженера и сравнению групп, использующих инструменты и работающих без них. Рост показателя тоже не сделал пользу очевидной для бизнеса.

Следующим предметом договорённости стало количество выполненных задач. Владимир не объявляет его универсальной мерой: смысл имеет результат, который бизнес готов признать полезным. На разных уровнях управления нужны разные показатели и проверки. Больше кода следует сопоставлять с ошибками и возвратами, больше задач — с их объёмом. Иначе команда может улучшить отчёт простым дроблением работы, не изменив того, что получает пользователь.

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

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

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

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

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

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

Платформа связывает события из IDE, браузера и командной строки с задачами и собирает их в рабочие сессии. Это другая величина, чем время нахождения карточки в статусе «в работе»: несколько открытых задач не означают одновременную работу над каждой. Правила объединения событий и остановки счёта при паузах определяют, какое время попадёт в аналитику.

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

Расход токенов полезен для разбора выбора инструмента. Владимир приводит случай, когда для массовой замены идентификаторов использовали большую модель, хотя подходила обычная команда IDE. Однако само по себе большое потребление не означает плохой работы: сложные задачи могут требовать более сильных моделей. Рейтинг по сожжённым токенам тем более не показывает пользу — ресурсы можно потратить на действия, не связанные с задачами компании.

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

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

Александр в финале возвращается к последовательности оценки AI: распространение инструментов, изменения конкретной работы и затем экономика. Данные об использовании помогают начать разбор, но руководителю ещё предстоит связать их с эффектом и стоимостью. Общий вывод разговора — аналитика полезна настолько, насколько помогает выбрать действие, объяснить его команде и проверить, что после него действительно изменилось.