Как измерять AI-ассистентов и coding agents

Александр открывает выпуск разбором свежей статьи платформы DX — по его собственной оговорке, не white paper, а именно статьи, вышедшей буквально на этой или на прошлой неделе. DX он описывает как крупную платформу для измерения продуктивности разработки, среди авторов которой есть соавторы DORA, SPACE и DevEx, объединившие эти подходы в DX Core 4. DX соединяет исследования и методики с накопленными данными для отраслевых сравнений в своей коммерческой платформе.

Евгений Сергеев, Engineering Director в Flo Health, делает внутренние продукты, которые помогают быстрее создавать, проверять и выпускать контент. Разработка, объясняет Александр, удобный полигон отчасти потому, что хорошо оцифрована: есть метрики, инструменты и проверки результатов работы ассистентов. Поэтому пробовать сценарии и собирать обратную связь относительно просто.

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

Отраслевые сравнения помогают интерпретировать цифры. Условные «80% внедрения» сами по себе не показывают, насколько компания продвинулась относительно других; в DORA для такого сравнения использовали группы, включая элитную.

Александр рассказывает, что внутри договорились за лето подготовить свой опрос по рекомендациям последней части Accelerate — формулировки конструкций, шкала Лайкерта, кросс-валидация вопросов — и, если всё получится, ближе к концу лета запустить его как бенчмарк российской индустрии: хайпа и цифр вокруг много, а как их мерили и что из них следует — обычно непонятно. Евгений доверяет опыту авторов DX в методологии: возможно, их подход станет отраслевым стандартом, который можно будет применять на других языках.

Евгений передаёт наблюдение с круглого стола: максимальный уровень внедрения, который видели авторы, — около 60%. Участники не знают, предел ли это; Евгений связывает препятствия прежде всего с сопротивлением организаций и людей, а не с возможностями технологии.

Ещё один тезис оттуда: больше всего от агентов выигрывают компании, выбравшие boring technology. Если стек — Python, TypeScript и JavaScript или Java со Spring, готовых примеров, на которых учились модели, огромное количество, и ассистент хорошо генерирует бойлерплейт, делает рефакторинги и помогает понять структуру проекта.

На более экзотических языках всё скромнее: во Flo Health основной стек — Scala, плюс Python и JavaScript, и в адопшене Copilot первым идёт Python, затем JavaScript и совсем немного Scala. Александр подтверждает: недовольны моделями обычно те, кто пишет на редких языках, где качество заметно хуже, — и ему хочется ответить, что стоит начать писать на достаточно популярной и простой технологии, тогда всё полетит.

Первая ступень зрелости — adoption и утилизация: кто пользуется и насколько плотно. Считаются DAU, WAU и MAU, сколько людей пользуется подсказками в IDE, в скольких пул-реквестах инструмент участвовал, как он проявил себя в код-ревью.

Александр приводит пример из внутреннего подкаста, записанного накануне, — ассистента для SRE, который собирает информацию об инциденте и пишет таймлайн для постанализа. Метрикой там стало не «понравилось или не понравилось», а доля сгенерированного текста, дожившая до финального отчёта: в описанном сценарии около 50%. Агент даёт заготовку и список событий, а связный рассказ и пропущенные пункты дописывает человек.

Во Flo Health к этому добавляют тег на пул-реквесте о том, что он сделан с помощью агента, число замечаний и правок после и постпродакшен-метрики: не вызвал ли этот мёрж инцидент.

Дальше идёт импакт — уже в разрезе метрик DX Core 4, — и только потом cost-benefit: что я за это получаю, сколько это стоит, насколько всё сходится. Соблазн перескочить велик: утилизация кажется слишком лобовой, косты считать умеют, а импакт оценивают пальцем в потолок. Ловушка в том, что нерелевантные или нечестные метрики раздувают ожидания и стоят доверия; честнее сказать, что сейчас команда измеряет использование, затем оценит влияние на работу, а эффект в деньгах покажет позже.

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

Отдельный сюжет — шкала времени на схеме: Евгению понравилось, что нарисовано направление движения, а Александр признался, что стрелку дорисовал сам, потому что из таблички не читалось, что это ступени; в ответ прозвучало сравнение со шкалой из Team Topologies и совет предложить дополнение авторам.

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

Для сравнения с рынком Александр вспоминает тест Хогана, где отдают не ответы, а перцентили, а Евгений — Jellyfish с перцентилями по командам, где sprint predictability в 80% относительно рынка уже высоко.

Сама DX, напоминает Александр, выросла над собой: начинала с опросов, а потом сделала адаптеры к системам и стала считать метрики по коду, таскам и релизам; опросы помогают быстро начать измерение и оценить восприятие работы, а данные об активности показывают реальные процессы. Евгений добавляет, что вопросы у них сформулированы настолько аккуратно, что их можно брать в engagement-опросы как есть. Следующий выпуск обещан про DX Core 4 с его Speed, эффективностью, Quality и Impact.