ИИ-инструменты для разработки захватили IT-индустрию: по данным опроса The Pragmatic Engineer за 2025 год, 85% разработчиков пользуются ими в работе. Вот только токены стоят денег, причем немалых, а бюджеты на ИИ растут. Возникает закономерный вопрос: а оно вообще того стоит?
Чтобы это выяснить, я обратился к Лоре Тачо. DX — компания, где она работает техническим директором — как раз специализируется на измерении эффективности разработки. Несколько лет назад Лора уже выпускала исследование на эту тему.
О чем поговорим в статье:
Как 18 технологических компаний измеряют влияние ИИ? Реальные метрики Google, GitHub, Microsoft, Dropbox, Monzo и других компаний.
Актуальность традиционных метрик. Почему привычные «базовые» способы оценки эффективности разработки продолжают работать в эпоху ИИ, и как их сочетать со специфичными показателями вроде индекса удовлетворенности пользователей (CSAT).
Как работать с метриками по-умному? Разбираем, зачем дробить показатели по уровню использования ИИ, как отслеживать их в динамике и почему к измерениям стоит относиться как к эксперименту.
Контроль качества, поддерживаемости и опыта разработчиков. Какие метрики уравновешивают друг друга и помогают не потерять качество в погоне за скоростью. Почему стоит одновременно смотреть на процент неудачных изменений и пропускную способность по PR.
Необычные метрики и интересные находки. «Плохие дни разработчика» у Microsoft, как Glassdoor оценивает результаты экспериментов с ИИ, и почему скоро все будут отслеживать эффективность автономных ИИ-агентов.
Как измерять влияние ИИ на практике? Обзор фреймворка DX AI и три способа получения данных: системная телеметрия, регулярные опросы и точечные опросы в моменте работы.
Опыт Monzo: что делать, когда вендоры прячут данные. Почему получить нормальные данные так сложно, в каких задачах ИИ работает особенно хорошо, и как качественные ИИ-инструменты помогают в борьбе за таланты.
А теперь передаю слово Лоре.
Откройте LinkedIn — и через 30 секунд вы непременно наткнетесь на пост о том, как ИИ меняет разработку ПО в компаниях. Новостные ленты пестрят заголовками: компании (в основном американские технологические гиганты) якобы выкатывают в продакшен тонны кода, сгенерированного ИИ — 25% кода у Google, 30% у Microsoft. А некоторые основатели стартапов уже вовсю заявляют, что ИИ может заменить junior-разработчиков. С другой стороны, исследования вроде недавней работы METR о влиянии ИИ на задачи в open source проектах показывают: ИИ искажает наше восприятие времени и фактически замедляет работу — даже когда нам кажется, что прогресс пошел значительно быстрее.
Когда речь заходит о влиянии ИИ, заголовки удивительно однобоки. ИИ пишет много кода и экономит время — или не экономит. А между тем мы летим навстречу самой грандиозной куче техдолга в истории человечества.
Меня не перестает удивлять, почему индустрия снова зациклилась на количестве строк кода (lines of code, LOC)? С чего вдруг именно эта метрика попадает во все заголовки? А как же качество, инновации, время выхода на рынок, надежность? Мы давным-давно договорились, что LOC — плохой показатель продуктивности разработчиков. Но его легко измерить, и в отсутствие внятной альтернативы он становится самым очевидным выбором. К тому же из этого выходят отличные заголовки.
Сейчас многие руководители отделов разработки принимают серьезные решения по ИИ-инструментам, толком не понимая, что работает, а что нет. В исследовании LeadDev 2025 AI Impact Report среди 880 руководителей 60% респондентов назвали отсутствие четких метрик главной проблемой при внедрении ИИ.
Мой собственный опыт это подтверждает. Каждую неделю я разговариваю с десятками руководителей, на которых давят ожиданиями результатов как в тех самых заголовках, но при этом боссы и советы директоров уперлись в метрику LOC и не желают смотреть глубже. Существует разрыв между тем, что руководителям нужно знать на самом деле, и тем, что измеряется и обсуждается, — и этот разрыв только растет с появлением новых инструментов и возможностей.
Устранять этот разрыв в измерениях — моя работа. Инструментами для разработчиков я занимаюсь больше десяти лет, а с 2021 года помогаю компаниям разобраться, как повысить продуктивность их команд. Два года назад я присоединилась к DX в качестве CTO — и теперь помогаю компаниям улучшить опыт разработчиков, повысить эффективность инженерных процессов и понять влияние ИИ.
В начале года мы с коллегами выпустили AI Measurement Framework — рекомендованный набор метрик для оценки внедрения и влияния ИИ в командах разработки. В его основе — тщательные полевые исследования и анализ данных от более чем 400 компаний, которые уже внедрили ИИ-инструменты и пытаются измерить их эффективность.
Сегодня заглянем в детали такой работы и поговорим о том, как 18 ведущих игроков рынка измеряют эффект от ИИ на практике. В статье:
Реальные метрики, которые используют Google, GitHub, Microsoft и другие.
Как компании применяют эти метрики для понимания, что работает, а над чем ещё предстоит поработать.
Как вы можете измерить влияние ИИ у себя.
Что вообще представляют из себя метрики влияния ИИ и как их применять.
1. Как 18 ведущих компаний измеряют влияние ИИ
Для начала небольшой обзор реальных метрик, используемых компаниями для измерения влияния ИИ. Среди них GitHub, Google, Dropbox, Microsoft, Monzo, Atlassian, Adyen, Booking.com и Grammarly:
Из этих подходов можно многое почерпнуть — причем интересны и схожие моменты, и различия. Давайте разбираться.
2. Почему традиционные метрики сохраняют актуальность
Использование ИИ для написания кода не меняет фундаментальных принципов того, что делает хорошее ПО хорошим и что важно для бизнеса. Софт по-прежнему должен быть качественным, простым в поддержке и выходить без задержек.
Поэтому многие метрики из списка выше выглядят точно так же, как и в доИИшную эру: процент неудачных изменений, время цикла пулл-реквестов (PR), пропускная способность по PR, опыт разработчиков.
Изобретать велосипед не нужно. Вместо этого сосредоточьтесь на базовых и постоянных приоритетах. Помогает ли ИИ вашей организации улучшить эти конкретные показатели?
Суровая правда в том, что если компания не может четко сформулировать, что важно для эффективности инженерной команды и продуктивности разработчиков, измерить влияние ИИ практически невозможно — дальше поверхностных метрик вроде LOC или acceptance rate дело не продвинется. Все упомянутые выше компании начали именно с этого — выстроили комплексную систему оценки, и только после этого смогли адекватно оценить эффект от ИИ-инструментов.
Но хоть начинать с нуля и не стоит, новые, целевые метрики всё же нужны, чтобы точно понимать, как именно используется ИИ. Где его применяют и в каком объеме — от этого зависят решения по бюджетам, развертыванию инструментов и обучению, а также вопросы SRE, безопасности, управления и комплаенса.
ИИ-метрики показывают:
сколько разработчиков и каких именно специализаций переходят на ИИ-инструменты;
какой объем и характер задач выполняется с использованием ИИ;
сколько это стоит.
Базовые инженерные метрики показывают:
стали ли команды выпускать релизы быстрее;
растут или падают качество и надежность;
не ухудшается ли поддерживаемость кода;
упрощают ли ИИ-инструменты рабочий процесс разработчиков.
Хороший пример комбинации привычных метрик с новыми, специфичными для ИИ — Dropbox. У них 90% разработчиков регулярно (как минимум раз в неделю) пользуются ИИ-инструментами, что очень много по сравнению со средним показателем в районе 50% по индустрии.
Dropbox вышел на такой уровень внедрения не благодаря энтузиазму отдельных специалистов. Они пошли структурным путем на уровне всей организации и с самого начала заложили в процесс качественные метрики.
Что отслеживает Dropbox в отношении ИИ:
число активных пользователей в день/неделю (DAU/WAU);
индекс удовлетворенности ИИ-инструментами (CSAT);
экономию времени в расчете на одного разработчика;
затраты на ИИ.
Эти показатели дают полную картину того, кто именно использует ИИ, как они это делают, действительно ли экономится время и во что всё это обходится. А когда поверх этого накладывается фреймворк Core 4 (который в Dropbox используют для отслеживания ключевых инженерных метрик), становится видно, как внедрение ИИ влияет на разработку в более широком масштабе. В частности, они смотрят на:
процент неудачных изменений (Change Failure Rate);
пропускную способность по PR (PR throughput).
Сами по себе 90% внедрения — просто красивая цифра. Но в Dropbox видят реальную пользу: разработчики, которые регулярно используют ИИ, мержат на 20% больше pull request'ов в неделю, при этом снижая процент неудачных изменений. Смотреть на все эти метрики вместе критически важно — иначе легко зациклиться на чем-то одном вроде процента внедрения и упустить суть.
3. Детализация метрик по уровню использования ИИ
Чтобы лучше понять, как ИИ меняет труд разработчиков, Dropbox и другие компании, с которыми я общалась, анализируют свои метрики несколькими способами, например:
cравнивают тех, кто пользуется ИИ, с теми, кто не пользуется;
cравнивают базовые инженерные метрики до и после внедрения ИИ-инструментов;
cледят за одной и той же группой пользователей по мере того, как они осваивают ИИ, и фиксируют изменения (когортный анализ).
Многие компании крутят данные так и эдак, чтобы разглядеть скрытые закономерности. Смотрят на роль, стаж, регион, основной язык программирования — и получают ответы на более конкретные вопросы. Например, видят интересные паттерны: junior-разработчики затапливают репозиторий PR, а senior-разработчики, напротив, застревают, потому что тратят больше времени на ревью этих самых PR. Такой детальный анализ помогает найти группы разработчиков, которым нужно дополнительное обучение, или, наоборот, обнаружить области, где ИИ работает особенно хорошо, и масштабировать эти сценарии на всю компанию.
Именно так в Webflow смогли вычислить группу, которой ИИ-инструменты экономят больше всего времени — ей оказались разработчики со стажем в компании более трех лет. Webflow использует Cursor и Augment Code и, как и Dropbox, отмечает примерно 20%-ый прирост в пропускной способности по PR у тех, кто пользуется ИИ.
Хотите проводить точные сравнения? Начните с надежной базы
Я уже говорила, что если у компании бардак с метриками продуктивности, то измерить влияние ИИ будет практически нереально. И это не просто слова: во-первых, они не знают, на какие сигналы смотреть, а во-вторых, у них просто нет данных для сравнения.
Если у вас до сих пор нет адекватной базы — сейчас самое время её собрать. Чтобы быстро начать, можно использовать фреймворк Core 4 (его применяют Dropbox, Adyen, Booking.com и другие) — вот шаблон и инструкции. Вдобавок к периодическим опросам можно подключить данные из ваших систем и точечные опросы в моменте — о них поговорим позже.
Не могу также не подчеркнуть, насколько важно относиться к измерениям как к эксперименту. Все компании, с которыми я общалась для этой статьи, объединяет одно: они используют данные, чтобы проверять гипотезы о том, как ИИ влияет на разработку. Часто они начинают с конкретной цели и двигаются от нее — не ждут, что цифры сами волшебным образом откроют какую-то истину об ИИ или подскажут, что делать дальше.
И помните: разовые замеры не дадут вам почти ничего. Тренды и закономерности проявляются только при отслеживании в динамике.
4. Качество, поддерживаемость и опыт разработчиков: держим руку на пульсе
Иногда мне не дает покоя одна мысль: разработка с помощью ИИ — это совсем свежая история. У нас нет данных за годы наблюдений, которые бы четко показали, что в долгосрочной перспективе никаких рисков для поддерживаемости или качества кода нет. И руководители, и разработчики озабочены одним и тем же вопросом: как не обменять краткосрочный прирост скорости на долгосрочные проблемы вроде техдолга.
Во избежание этого рекомендую отслеживать метрики, которые уравновешивают друг друга. Обратите внимание, практически все компании отслеживают процент неудачных изменений (Change Failure Rate) вместе с показателями скорости — например, пропускной способностью по PR. Эти метрики помогают держать баланс: если скорость растет, а качество падает — что-то пошло не так.
Помимо процента неудачных изменений, рекомендую следить и за другими показателями, чтобы не упускать из виду качество и поддерживаемость. Что измеряют некоторые компании:
Уверенность в изменениях (Change confidence) — насколько разработчик уверен, что его изменения не сломают продакшен.
Поддерживаемость кода (Code maintainability) — насколько легко понимать и модифицировать код.
Восприятие качества (Perception of quality) — как сами разработчики оценивают качество кода и принятых в команде практик.
Чтобы картинка была полной, вам нужны и «железные» системные метрики, и субъективные данные от разработчиков. Только так можно охватить и скорость, и качество, и поддерживаемость. Пропускную способность по PR или частоту деплоев легко посчитать, вытащив данные из систем контроля версий и сборки. А вот «уверенность в изменениях» или простоту поддержки кода из логов не достанешь — об этом можно узнать, только спросив самих людей. Это критически важно, если не хотите столкнуться с отложенными последствиями внедрения ИИ.
Если эти темы ещё не всплывают на обсуждениях ИИ в команде — внесите их в повестку. Пусть даже это будет неформальный фидбэк, он даст бесценное понимание того, что волнует людей. На основе этого можно вместе обсуждать варианты решений и смотреть, как ситуация меняется со временем.
Но чтобы отследить четкую связь между использованием ИИ и изменениями в качестве и поддерживаемости, нужны более структурированные данные. Регулярные опросы об опыте разработчиков — отличный инструмент для этого.
Вот пример пары вопросов, которые помогут оценить уверенность в изменениях и поддерживаемость кода:
В целом, опыт разработчиков (DevEx) — ещё одна важная метрика, которая не дает перегнуть палку в погоне за скоростью в ущерб качеству. Правда, у самого понятия DevEx есть небольшая проблема в позиционировании: его легко принять за «корпоративные плюшки», тогда как на самом деле речь об устранении препятствий в процессе разработки — от планирования и написания кода до тестирования, релиза и поддержки в продакшене.
С ИИ-инструментами есть риск в том, что, упрощая жизнь на одном этапе (например, написание кода), мы рискуем усложнить её на другом — скажем, на этапе код-ревью, разбора инцидентов или дальнейшей поддержки.
Шелли Стюарт, директор по разработке в CircleCI, рассказывает, почему опыт разработчиков и их удовлетворенность так важны в контексте ИИ:
«Опыт разработчиков — это про субъективные впечатления, которые стоят за сухими цифрами. Метрики вроде пропускной способности по PR показывают, что происходит, а вот удовлетворенность разработчиков — можно ли так работать вдолгую.
Мы знаем, что внедрение ИИ-инструментов поначалу может бесить людей. Но отслеживая опыт разработчиков параллельно с бизнес-показателями, мы можем отличить временные неудобства от долгосрочной пользы. Если не будем измерять удовлетворенность, упустим из виду ключевой момент: наши инвестиции в ИИ улучшают культуру разработки или, наоборот, порождают новые проблемы, с которыми придется бороться?».
Если разработчикам не нравится инструмент, грош цена его выдающимся техническим возможностям. Три четверти компаний, упомянутых в статье, измеряют удовлетворенность разработчиков или CSAT. И это верный знак того, что фокус смещается с голой скорости на выстраивание здоровых и долгосрочных инженерных практик, которые упрощают ежедневную работу, а не усложняют её.
5. Необычные метрики и интересные находки
На самом деле, все эти метрики таят немало интересного. Хотя в целом индустрия сошлась на том, чтобы измерять экономию времени, качество и скорость, но я люблю разбирать исключения — тех, кто идет своим путем — через них видно, чем компании отличаются друг от друга и что упускают стандартные метрики.
В Microsoft, например, для оценки влияния ИИ используют концепцию «плохого дня разработчика» (Bad Developer Day, BDD). Это взгляд на всю ежедневную рутину и тягомотину в работе в режиме реального времени — в отличие от опросов, которые показывают картину с опозданием. Идея в том, что ИИ должен уменьшать количество «плохих дней» и делать их проще. Если это так, значит, он действительно убирает препятствия, а не создает новые.
Итак, что может испортить день разработчику?
Время на разбор инцидентов и решение срочных вопросов с комплаенсом.
Бесконечные совещания и почта с постоянным переключением между разными темами.
Возня с тасками в трекере.
В Microsoft берут эти «негативные» факторы и взвешивают их на одних весах с «позитивными» — активностью по PR, которая косвенно говорит о времени, потраченном на написание кода. Логика простая: день может включать выматывающие или малоценные задачи, но если разработчику всё же удалось нормально написать код и запушить изменения, чаша весов склоняется в сторону хорошего дня.
А вот в Glassdoor пошли другим путем и измеряют, как ИИ влияет на эксперименты. Они отслеживают количество A/B-тестов в месяц, чтобы понять, помогает ли ИИ разработчикам быстрее пробовать новое. ИИ — мощнейший инструмент для прототипирования, поэтому очень интересно видеть такую метрику в качестве ключевого показателя. Кроме того, в Glassdoor отлично работают с комьюнити, превращая самых активных пользователей в «амбассадоров» ИИ внутри компании.
Они также используют редкую метрику — «процент отработанной мощности» (percentage capacity worked). Она сравнивает общий потенциал инструмента с его фактическим использованием. Это помогает вовремя заметить, когда инструмент или его внедрение уперлись в потолок — верный сигнал, что пора перераспределить бюджет на что-то помощнее.
Acceptance rate в наши дни измеряют редко. Когда-то процент принятых подсказок от ИИ был главной метрикой, сейчас же она стремительно теряет популярность из-за своей однобокости. Всё дело в том, что она смотрит только на момент, когда подсказка принята, и совершенно упускает из виду:
А легко ли будет поддерживать этот код?
А не откатили ли это изменение через пару коммитов?
А не притащила ли эта подсказка с собой баги?
И, наконец, стал ли разработчик в целом продуктивнее?
Так что многие компании уже не считают acceptance rate ключевым показателем. Но есть исключения:
GitHub создает свой собственный ИИ-инструмент (Copilot), и эта метрика помогает им понимать, как люди им пользуются, и принимать продуктовые решения.
T-Mobile используют её как индикатор того, сколько ИИ-кода добирается до продакшена — а это для многих задачка со звездочкой.
Atlassian и некоторые другие компании смотрят на нее как на косвенный показатель того, насколько разработчики довольны инструментом, и действительно ли он предлагает вменяемый код.
Расходы на ИИ-инструменты пока мало кто измеряет, но это, скорее всего, вопрос времени. Сегодня большинство организаций не хотят отпугивать разработчиков от использования ИИ явным подсчетом трат. Но есть и те, кто идет от обратного, как Shopify. Они завели «доску почета» по ИИ, чтобы видеть, кто тратит больше всего токенов, и открыто поощряют такие эксперименты.
Тем не менее, компаниям нужно быть уверенными, что их инвестиции в ИИ окупаются, а бюджеты тратятся не зря. Согласно отчету ICONIQ «Состояние ИИ в 2025 году», бюджеты на повышение внутренней продуктивности с помощью ИИ в этом году, по прогнозам, удвоятся по сравнению с 2024-м. Львиная доля этих денег идет из бюджетов на R&D, но некоторые компании уже перераспределяют бюджеты, заложенные на наем. Проще говоря, некоторые компании планируют нанимать меньше, чтобы больше тратить на ИИ-инструменты.
Цены уже поползли вверх (про $20 в месяц можно забыть), и компании пытаются спрогнозировать свои расходы на следующий год с учетом потребления токенов и появления новых инструментов. Всё это ведет к тому, что на цены смотрят всё внимательнее, а значит, и к измерениям подходят строже.
Телеметрию ИИ-агентов пока что не измеряют — но, вероятно, это изменится в ближайший год. Специфических метрик для агентов тоже пока нет. Сейчас команды просто не готовы к такому уровню детализации, да и самих данных для анализа пока мало. Но автономные агенты будут набирать популярность в ближайшие 12–18 месяцев. Так что это как раз та область, где метрики точно изменятся, чтобы отражать реальное положение дел.
За пределами написания кода, в целом, почти ничего не измеряется. Сейчас смотрят в основном на то, как ИИ помогает кодить, и всё. По прогнозам, 2026-й станет годом ИИ во всем жизненном цикле разработки ПО (SDLC), и метрикам придется догонять реальность. Понятно, что конкретные задачи, вроде код-ревью или сканирования уязвимостей, легко охватить телеметрией. А вот там, где результат более абстрактный, всё сложнее — не всегда можно провести прямую линию от действия к эффекту.
Даже сейчас многие компании измеряют только работу ИИ-ассистентов в IDE или терминале. А то, что разработчик провел мозговой штурм с ChatGPT или разобрал с помощью ИИ тысячи тикетов в Jira, в графу «сэкономленное время» часто не попадает. Думаю, что в части опросов (из серии «сколько времени вы сэкономили на этой неделе благодаря ИИ?») область измерений будет только расширяться, чтобы угнаться за всем разнообразием новых инструментов.
6. Так как же измерять влияние ИИ?
Какие выводы можно сделать из всего этого и что перенять к себе в компанию?
Пару месяцев назад мы с Аби Нодой (соавтором DevEx Framework) выпустили AI Measurement Framework. Мы плотно работали с некоторыми из компаний, упомянутых в этой статье, и с головой погрузились в их проблемы с измерениями. Можно сказать, наблюдали за всем из первого ряда: видели, какие решения им приходилось принимать на основе данных, и отмечали, что работает, а что нет. Мы также привлекли других исследователей, чтобы учесть в наших рекомендациях опыт последних десяти лет в изучении продуктивности разработчиков.
Данный фреймворк — это коктейль из специфических ИИ-метрик и ключевых инженерных показателей. Он показывает, где и как в вашей компании используется ИИ, а главное — какое влияние это оказывает на общую производительность и опыт разработчиков. Здесь есть все: и скорость, и качество, и поддерживаемость. Как и в любом фреймворке, все метрики нужно смотреть в связке — ни одна сама по себе не даст полной картины. Особенно пресловутый процент сгенерированного ИИ кода.
Фреймворк отвечает на вопрос «что измерять», остается разобраться с «как?».
Чтобы картинка была полной, вам нужны и цифры, и «живые» данные от людей. С продуктивностью разработчиков так делают давно, с ИИ всё точно так же. Посмотрите на компании из этой статьи: все они комбинируют системные метрики (пропускная способность по PR, DAU/WAU) с данными из опросов (CSAT, сэкономленное время).
Собрать эти данные можно несколькими способами:
Системные данные (количественные). У большинства ИИ-инструментов есть админские API для отслеживания использования, расходов, потребления токенов и процента принятых подсказок. К ним можно подтянуть и системные метрики из вашего стека разработки — GitHub, Jira, CI/CD-пайплайнов, систем сборки и управления инцидентами.
Регулярные опросы (качественные). Регулярные (например, ежеквартальные) опросы помогают отследить долгосрочные тренды в опыте разработчиков, которые никогда не увидишь в сухих системных данных. Опросы — это не только про субъективщину вроде удовлетворенности, уверенности в изменениях или поддерживаемости кода, которые невозможно вытащить из системных логов. Через опросы можно собирать и количественные данные: пропускную способность по PR, процент сбоев и долю PR, сделанных с помощью ИИ. Это отличный способ получить данные там, где телеметрия недоступна или её сбор нецелесообразен.
Точечные опросы в моменте (качественные). Этот метод про сбор фидбэка прямо в процессе работы — короткие вопросы в ключевых точках. Например, после отправки PR можно быстро спросить, использовался ли ИИ при написании кода, и показался ли сгенерированный код проще или сложнее для понимания.
Проще всего начать с регулярных опросов. Они быстро дадут вам микс из данных и о рабочем процессе, и о его восприятии, что никогда не достанешь просто из системных логов. Запустить опрос и получить первые данные можно за неделю-две, и их детальности обычно хватает для принятия большинства решений. Помните: чем точнее измерение, тем оно дороже. Когда вешаешь шторы, погрешность в миллиметр не страшна. Совсем другое дело — когда строишь ракету. Большинство наших решений как руководителей — это как раз про «повесить шторы», а не «построить ракету». Нам достаточно разумной степени точности для движения в верном направлении.
Со временем можно подключать и другие источники данных. Комбинируя разные методы, вы сможете перепроверять выводы из нескольких источников. Например, можно спрашивать разработчиков, как они оценивают качество, и одновременно следить за процентом сбоев и количеством инцидентов.
Определения и методы расчета для распространенных ИИ-метрик
Чтобы применить эти идеи у себя, пользуйтесь этим глоссарием распространенных ИИ-метрик — он поможет понять, как определить и собрать данные. Полный глоссарий по метрикам ИИ и продуктивности разработчиков ниже:
Как применить эти идеи у себя
У компаний, с которыми я общалась для этой статьи, нет универсальных рецептов по стратегии внедрения ИИ. Но у них выстроена система, которая дает достаточно данных, чтобы вовремя заметить, что что-то пошло не так.
И помните: мы не гонимся за высоким процентом внедрения и какой-то одной красивой цифрой. Наша цель — понять, помогает ли ИИ делать качественный софт, который решает проблемы клиентов, и делать его быстрее. Метрики нужны, чтобы понять, где, как и почему ИИ помогает (или не помогает) достичь этих целей. И на основе этого либо дальше давить на газ, либо менять курс.
Задумайтесь о своей стратегии измерений. Можете ли вы ответить на вопрос:
«Помогает ли ИИ нам стать лучше в том, что и так всегда было важно: качество, скорость выхода на рынок и беспроблемный опыт разработчиков?»
Если ответ «пока нет», вот несколько тем, которые стоит поднять на следующей встрече с руководством:
У нас вообще есть четкое определение, что такое «эффективная работа отдела разработки»?
Есть ли у нас данные о том, как мы работали до ИИ? Если нет, как нам быстро получить исходные показатели?
Мы не путаем активность вокруг ИИ с его реальным влиянием?
Сбалансированы ли наши метрики? Учитывают ли они и скорость, и качество, и поддерживаемость?
Видим ли мы, как ИИ-инструменты влияют на опыт разработчиков?
Комплексный ли у нас подход к измерениям? Мы смотрим и на системные данные, и на данные от самих разработчиков?
7. Опыт Monzo: как они измеряют влияние ИИ
Чтобы перейти от общих рассуждений к практике, мы с Лорой поговорили с командой инновационного банка Monzo Bank — одного из заметных игроков с развитой инженерной средой и прагматичным подходом к внедрению ИИ.
Сухаил Патель, руководитель платформенных команд в Monzo, рассказал, как в их компании оценивают пользу ИИ-инструментов для разработчиков.
— С каких ИИ-инструментов вы начинали?
— Первым был GitHub Copilot. Уверен, что так у большинства компаний, и всё благодаря гениальному ходу GitHub: Copilot не продавали как отдельный продукт, он просто незаметно появился в VS Code. С нами связался их менеджер и просто проинформировал, что Copilot теперь часть нашей корпоративной лицензии. Посоветовали попробовать и подключить всех разработчиков.
Это был первый раз, когда наши разработчики смогли по-настоящему погонять технологию в боевых условиях: попробовать режим агента, пообщаться с чатами, оценить умный автокомплит. Именно тогда пришло первое понимание, какой у этих инструментов потенциал.
С тех пор мы попробовали и Cursor, и Windsurf, и Claude Code, но по-прежнему вкладываемся и в Copilot.
— Какой совет дадите руководителям разработки по оценке ИИ-инструментов?
— Мы считаем так: не быть в курсе этого стремительно меняющегося ландшафта инструментов — значит играть вслепую. Можно было бы сидеть на одном Copilot, но новинки появляются постоянно! И пока не попробуешь сам, все твои представления о них — не более чем догадки.
Мой главный совет — получайте собственный, практический опыт. Пусть ваши инженеры каждый день работают с этими инструментами, пишут с ними свой код, создают свои файлы agents.md. Только в реальной работе станет ясно, на что способен инструмент. Ему нужно дать максимум контекста, чтобы он раскрыл свой потенциал.
И ещё важный момент: объективно оценить эти инструменты сложно. Нужно быть готовым к тому, что часть оценки всегда будет субъективной. Цифры, которые мы измеряем «объективно» — это статистика использования и локальные тесты производительности. А далее мы уже проводим кучу DX-опросов, чтобы понять реальное мнение разработчиков касательно всех используемых инструментов».
— Как понять, что ИИ-инструменты реально работают и окупаются?
— Вопрос на миллион долларов. Соврал бы, если бы сказал, что у нас есть единственно верный ответ. Сейчас многое завязано на субъективных ощущениях. Если разработчики чувствуют, что инструмент приносит им пользу — на данном этапе этого уже достаточно!
Ведь ИИ помогает не только писать код. Наши разработчики говорят, что инструменты здорово выручают, когда нужно:
быстро и просто найти нужную документацию;
сделать короткую выжимку из текста;
лучше разобраться в коде.
... и в целом, просто снижают когнитивную нагрузку, если подобрать правильный инструмент.
Мы работаем на очень конкурентном рынке, и наши разработчики должны иметь доступ к лучшим инструментам. Если мы не дадим им то, чем пользуются в других стартапах, они просто разочаруются в компании и уйдут.
— Почему так сложно измерить реальную пользу от ИИ? Какие метрики вы используете?
— Честно говоря, измерить, насколько эти инструменты помогают бизнесу — адски сложно. Например, как нам понять, что мы стали на 30% эффективнее именно благодаря коду, который сгенерировал ИИ? Если на то, чтобы «допилить» и исправить этот код, уходит столько же времени, сколько на написание с нуля, то мы не продвинулись ни на шаг!
Проблема в том, что вендоры — будь то Microsoft, Google или кто-то ещё — измеряют то, что могут, и выдают вам эти цифры. А измерять они могут только косвенные показатели вроде acceptance rate. Большинство компаний, и мы в их числе, пока просто не готовы к тому, чтобы точно измерить влияние ИИ на бизнес.
Конечно, в теории можно было бы провести A/B тест: одна команда с ИИ, другая — без. Но давайте будем честны, это нереально. Не думаю, что эту область вообще можно A/B-тестить, по крайней мере, для большинства команд.
Чтобы получить реальную картину, нужно забирать телеметрию у вендоров, которые совсем не горят желанием делиться настоящими цифрами. Если бы мы захотели получить точную статистику использования, нам пришлось бы собирать её из кучи инструментов: GitHub Copilot, Gemini, Google Workspaces, Slack, Notion... У всех есть ИИ-фичи, но собрать всё воедино — практически невозможно! Вендоры намеренно делают телеметрию непрозрачной — так они сохраняют конкурентное преимущество и удерживают клиентов. В результате получить действительно нужные данные об использовании очень и очень трудно, даже самые базовые вещи вроде «как часто использовались ИИ-функции в этом инструменте и какую пользу из этого извлекли пользователи».
К сожалению, сегодня единственный способ получить эти данные довольно агрессивный: установить на ноутбуки разработчиков специальные агенты, которые будут отслеживать их действия. Чтобы было ясно — я не сторонник такого подхода, и мы так не делаем. Но если этот вариант отпадает, у вас на руках остаются лишь субъективные ощущения о том, что работает, а что — нет.
— В каких областях эти инструменты работают особенно хорошо?
— Где ИИ реально приносит существенную пользу, так это в миграциях. Когда нам нужно переехать на новую технологию или внедрить свежие библиотеки и зависимости, эти инструменты творят магию. Они сами могут связать модификации кода и накидывают черновик большей части миграции. Человек подключается, только когда задача становится слишком уж заковыристой. По ощущениям, на миграциях мы экономим 40–60% сил по сравнению с тем, как это было раньше.
Вот вам пример: у нас сейчас большой проект по аннотированию нашего инструментария для работы с данными. Разработчикам нужно вручную определить ряд сущностей и связей для нескольких существующих моделей. Это очень монотонная и кропотливая работа.
А теперь мы можем натравить на это LLM. Модель делает первый проход, а разработчики потом просто просматривают изменения и правят то, в чем она ошиблась. LLM-ки берут на себя львиную долю самой нудной работы в таких четко очерченных задачах, а людям остается разобраться с нюансами. Пока что это ощущается как огромный прорыв. И это как раз тот случай, когда разработчики сами говорят, что видят реальную пользу.
— С какими подводными камнями пришлось столкнуться, когда вы начали применять ИИ-инструменты в разработке?
— Мне кажется, разработчики не до конца понимают, в какую копеечку на самом деле влетают эти LLM. Если бы люди получали от компании счета за свое реальное потребление токенов, вопрос оптимизации расходов стоял бы куда острее.
Приведу аналогию. Когда вы в Google Cloud пишете SQL-запрос в BigQuery, он прикидывает, сколько данных придется просканировать, и вы сразу видите цену вопроса во времени и ресурсах. Например, система говорит: «этот запрос просканирует 10 ГБ». Вы, скорее всего, подумаете: «Ерунда, поехали». А в другой раз она скажет: «Этот запрос просканирует 500 ТБ». И тут вы уже задумаетесь: «Ого, столько мне точно не нужно, надо переписать».
У нас была похожая история с код-ревью от Copilot: выхлопа было мало, а токенов улетала куча. Мы включили автоматическое ревью от GitHub Copilot. Инструмент сжигал уйму токенов, предлагая нам правки. Но вскоре мы поняли, что эти подсказки были бесполезны! В итоге мы просто тратили деньги и тормозили разработчиков, которым приходилось отвлекаться на бессмысленные рекомендации.
Так что мы отключили эту функцию по умолчанию. Разработчики по-прежнему могут запросить ревью от Copilot, но теперь это опция из разряда «по желанию».
— В каких областях вы решили не использовать ИИ вообще?
— Мы решили не использовать ИИ в самых чувствительных для бизнеса областях. Например, мы жестко пресекаем любые попытки его применения везде, где хранятся любые клиентские данные, даже обезличенные. Это касается и нашего хранилища данных — несмотря на то что информация о клиентах там полностью анонимизирована и доступна разработчикам только по запросу.
Пока у нас не будет стопроцентной уверенности в безопасности, мы не хотим, чтобы люди играли с огнем в отношении персональных данных.
Бывают ситуации, когда я прошу Cursor написать shell-скрипт, а он подкидывает какие-то случайные лицензионные или API-ключи — те самые, которые кто-то оставил в своем окружении и которые агент успел проиндексировать. Не хотелось бы, чтобы подобное случилось с более «чувствительными» данными.
— Как вы в целом смотрите на ИИ-инструменты в контексте разработки?
— Мой подход простой. Мы как платформенная команда должны:
Выстраивать границы. Обеспечивать безопасное использование ИИ-инструментов, чтобы разработчикам не приходилось беспокоиться об утечках данных.
Делиться примерами. Рассказывать как об успешных кейсах, так и о провалах (где инструменты сработали, а где нет).
Быть максимально открытыми. Рассказывать, какие промпты не сработали, или когда кто-то убил полдня, пытаясь заставить промпт работать, хотя мог бы за это время просто решить проблему руками.
Видеть обе стороны медали. Важно подмечать и плюсы, и минусы. Речь не о том, чтобы сказать «скептики правы!» или «сторонники ИИ победили!». Мы за взвешенный подход.
Помнить об ограничениях. Мы постоянно говорим людям, чтобы они не забывали о пределах возможностей ИИ. Ограничения есть у всего: и у людей, и у LLM.
Выводы
Огромное спасибо Лоре за её исследование и данные о том, как компании измеряют эффективность ИИ и, конечно, Сухаилю — за откровенный рассказ о подходе Monzo к ИИ-инструментам и их практическом опыте.
Измерение влияния ИИ — область довольно новая, и единственно верного способа тут нет. Даже гиганты вроде Microsoft и Google, работающие на одном поле, подходят к измерениям по-разному. Таблицы выше отлично показывают: у каждой компании свой «почерк» в этом деле.
Измерять противоречивые, на первый взгляд, метрики абсолютно нормально. Так делают почти все. Самый частый пример: отслеживать процент неудачных изменений (или похожие метрики — частоту или долю багов в проде) и одновременно — частоту pull request'ов. Первая метрика — про надежность, вторая — про скорость. Гнать быстрее есть смысл, только если не страдает надежность. Поэтому и измерять нужно обе!
Измерить влияние ИИ-инструментов на команды так же сложно, как и измерить продуктивность самих разработчиков. А над последней задачкой индустрия бьется уже больше десяти лет. Мы давно поняли, что не существует одной-единственной метрики, которая покажет, насколько продуктивна команда. Любой показатель можно «накрутить», не став при этом эффективнее. В 2023 году консалтинговый гигант McKinsey уверенно заявил, что они раскрыли секрет измерения продуктивности. Но мы с Кентом Беком, создателем экстремального программирования, отнеслись к этому заявлению скептически и опубликовали свой ответ в статье «Измеряем продуктивность разработчиков? Ответ McKinsey».
Пока мы не разберемся, как адекватно измерять продуктивность разработчиков, мы вряд ли до конца поймем, как измерять и влияние ИИ на эту продуктивность. Да, готового решения нет, но это не значит, что нужно сидеть сложа руки. Нам нужно продолжать экспериментировать и искать ответ на вопрос: «Как все эти ИИ-инструменты меняют ежедневную и ежемесячную эффективность — и отдельного человека, и команды, и компании в целом?».