Давление сверху вниз при внедрении искусственного интеллекта не гарантирует успеха. Как отмечает Лаура Тачо, технический директор DX, интеллектуальной платформы для разработчиков, он зависит от вашей способности измерить отдачу от ИИ-инструментов для разработчиков, сообщает портал The New Stack.

Каждая организация задается вопросом, как ускорить внедрение ИИ.

«Мы сосредоточены на том, как стать быстрее, и многие из нас не задумываются о том, куда мы вообще движемся, — говорит Тачо. При этом существует общеотраслевая проблема разочарования в ИИ, когда ни одна компания в реальности даже близко не подошла к чудесному возврату инвестиций (ROI), обещанному шумихой.

«Если вы прямо сейчас откроете ленту новостей, вам не понадобится много времени, чтобы наткнуться на сенсационный заголовок о том, что 30% кода пишется с помощью ИИ. Или 60% кода. Или, через три-шесть месяцев, это будет 90% кода, — говорит Тачо. — Мы слышим, что ИИ одновременно заменит всех младших инженеров, а также всех старших инженеров и в конечном итоге всех инженеров».

И это при том, что, как показали исследования DX, даже в самых высокоэффективных организациях часто используют инструменты ИИ лишь около 60% команд разработчиков ПО, в среднем экономя 3,75 часа на разработчика в неделю.

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

Как же измерить влияние ИИ-помощников по кодированию и агентов? Как рассчитать окупаемость инвестиций в ИИ?

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

ИИ-метрики против ИИ-хайпа

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

«Старшие ИТ-руководители обязаны рассказать другим сотрудникам своей компании о том, чего стоит ожидать от ИИ и как он на самом деле влияет на производительность организации», — говорит Тачо.

Для этого им необходимо:

  • определить, что означает производительность разработки для вашей организации;
  • определить конкретные метрики для измерения влияния ИИ на производительность.

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

Действительно, данные опросов не соответствуют обещаниям в заголовках о производительности — и уж точно не соответствуют стандартам качества. Так, согласно отчету Harness «State of Software Delivery 2025», 67% разработчиков тратят больше времени на отладку кода, созданного ИИ, а 68% — на устранение уязвимостей в системе безопасности. Большинство разработчиков сталкиваются с проблемами как минимум в половине развертываний кода, созданного ИИ-помощниками. Как говорится в отчете Devographics «2025 State of Web Dev AI», 76% разработчиков считают, что генерируемый ИИ код требует рефакторинга, что способствует возникновению технического долга.

Система измерения ИИ

Система DX AI Measurement Framework основана на разработанном компанией фреймворке повышения производительности труда разработчиков Core 4, который объединяет существующие системы показателей DORA, SPACE и DevEx для определения и измерения изменений по сравнению с базовыми показателями эффективности разработки.

Эта новая система предназначена для измерения влияния помощи в кодировании с помощью ИИ на рабочие процессы разработки ПО, чтобы определить:

  • какие инструменты ИИ работают;
  • какие инструменты ИИ не работают;
  • какие команды нуждаются в дополнительной поддержке при внедрении ИИ;
  • какие инструменты ИИ оказывают наибольшее влияние.

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

Система охватывает три измерения:

  • Использование. Как часто разработчики внедряют и используют инструменты ИИ?
  • Влияние. Как ИИ влияет на производительность труда инженеров?
  • Стоимость. Насколько оптимальны расходы на ИИ и возврат инвестиций?

Нет никаких сомнений в том, что, как говорится в отчете G-P «AI at Work Report», компании «полностью посвятили себя ИИ». Подавляющее большинство руководителей считают ИИ критически важным для успеха своей компании, а 60% утверждают, что их компания активно использует ИИ для внедрения инноваций. 91% руководителей недавно ответили, что их инициативы в области ИИ расширяются.

«Компании могут продолжать бросать деньги на решение проблемы, а могут с умом подойти к оценке ИИ-инструментов и убедиться, что каждый вложенный доллар возвращается к ним в многократном размере. Это практически невозможно сделать без измерений значимых воздействия», — говорит Тачо.

Метрики использования ИИ

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

Метрики использования, рекомендуемые DX, следующие:

  • Использование инструментов ИИ на уровне ежедневных и еженедельных активных пользователей, на уровне команд и различных должностных ролей.
  • Процент запросов на исправление, в которых используется ИИ.
  • Процент зафиксированного кода, сгенерированного ИИ.
  • Задачи, назначенные агентам ИИ.

До сих пор код, созданный ИИ, в основном остается вещью в себе. На данный момент Windsurf является единственным основным ИИ-помощником по кодированию, который предоставляет метрику процента написанного кода (PCW) для зафиксированного кода, который можно отнести к результатам работы ИИ.

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

Метрики влияния ИИ

Рост использования — важный сигнал, но это только начало.

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

Если вы для начала выберете одну ИИ-метрику, то экономия времени за счет ИИ (измеряемая как сэкономленные часы разработчика в неделю) — отличный способ измерить воздействие, которое, в свою очередь, влияет на стоимость. Сравните это с человеко-эквивалентными часами работы, выполненной агентами ИИ.

Система измерения ИИ позволяет понять, как любое изменение кода, созданное человеком или ИИ, влияет на жизненный цикл доставки ПО и опыт разработчиков. К таким показателям производительности разработчиков относятся:

  • пропускная способность запросов на изменения;
  • воспринимаемая скорость доставки;
  • сопровождаемость кода;
  • уверенность в изменениях;
  • частота отказов при внесении изменений.

Отчет DORA за 2024 г. показал, что 25%-ный рост внедрения ИИ фактически спровоцировал:

  • снижение стабильности доставки на 7,2%;
  • снижение пропускной способности доставки на 1,5%.

Если вы не используете передовые методы проектирования, то большее количество кода не приведет к хорошему или стабильному коду.

Удовлетворенность разработчиков — еще один важный фактор при оценке влияния инструментов ИИ для разработчиков. Воспринимаемое разработчиками повышение их производительности может положительно повлиять на фактическое повышение производительности.

Вы должны измерить влияние ИИ на весь опыт разработчиков, поскольку разработчики теряют один день в неделю из-за трудозатрат, которых в основном можно избежать. Наложение чата и другие возможности, поддерживаемые ИИ, могут помочь сократить эти прерывания потока.

Исследование DX также показало, что инструменты ИИ позволяют разработчикам уверенно работать с незнакомым или сложным кодом, к которому в противном случае они могли бы не прикоснуться. В конце концов, ИИ отлично справляется с объяснением сложностей. По словам Тачо, ИИ позволяет выполнять более Т-образную разработку ПО, когда широта знаний становится больше, но при этом сохраняется глубина специальных знаний.

Метрики затрат на ИИ

Стоимость ИИ, скорее всего, будет расти, но инвестиции без стратегии являются расточительными.

К показателям затрат относятся:

  • расходы на ИИ, как в целом, так и в расчете на одного разработчика;
  • чистый выигрыш времени на одного разработчика, или экономия времени минус затраты на ИИ.
  • почасовая ставка ИИ, или расходы на ИИ, деленные на человеко-эквивалентные часы.

Стоимостной аспект системы измерения ИИ можно также адаптировать для общеорганизационной ИИ-стратегии.

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

В конечном счете, наиболее весомым показателем стоимости ИИ является ответ на вопрос: сможете ли вы масштабировать технологию с тем же количеством людей?

Лучшие практики измерения ИИ

Поскольку невозможно улучшить то, что не измеряется, разработка системы измерения ИИ в DX началась с анализа инженерных разработок с помощью ИИ в 180 компаниях, за ходом которых они следили в течение года.

Booking.com, развернувшая инструменты ИИ для более чем 3500 разработчиков, активно использует эти ИИ-метрики. Благодаря стратегическим, взвешенным инвестициям в ИИ, включая обучение, агентство смогло увеличить пропускную способность пользователей ИИ на 16%. Это означает экономию 150 тыс. часов работы разработчиков благодаря 65%-ному уровню внедрения инструментов ИИ в первый год.

Удвоив использование ИИ-помощников по кодированию, Workhuman добилась увеличения экономии времени разработчиков на 21%. Компания, специализирующаяся на SaaS для работы с персоналом, использовала метрики использования, воздействия и затрат, а также опросы разработчиков, задавая им следующие вопросы:

  • Насколько полезным вы считаете данный инструмент генеративного ИИ (GenAI)?
  • Каков уровень сложности его внедрения?
  • Как он влияет на вашу способность выполнять свою работу?
  • Облегчил ли этот инструмент вашу жизнь или нет?

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

Не забывайте следить за соблюдением нормативных требований и безопасностью на всех этапах внедрения ИИ. «Управление, безусловно, важно на начальном этапе, но, по моему опыту, оно приходит позже, когда инструмент уже готов к „масштабированию“», — уточняет Тачо. Однако в свете того, что только 60% компаний имеют какую-либо политику в области ИИ, она подчеркивает, что «такие вещи, как политика допустимого использования, на 100% должны появляться на ранних этапах».

Разработка на основе спецификаций с помощью агентов ИИ — один из способов обеспечить управление при ИИ-разработке под руководством человека. «Вы говорите: „Я проанализировал этот тикет. Пожалуйста, сделайте все что нужно за меня“, — поясняет Тачо, — как будто вы тимлид команды автономных агентов».

Очень важно помнить, что все эксперименты с ИИ должны проводиться с учетом психологической безопасности. Показатели должны собираться анонимно. «Они никогда не должны проверяться на индивидуальном уровне, — предупреждает Тачо, — потому что это не очень полезно, а также порождает страх, неуверенность и сомнения среди разработчиков, потому что никто не хочет, чтобы за ним шпионили».

Например, метрику использования ИИ следует рассматривать как среднее значение для разработчиков, которые являются ежедневными активными пользователями (DAU) и еженедельными активными пользователями (WAUs), на уровне команды и подразделения.

Рассмотрите и другие способы разделения когорт, например, по стажу работы в компании и особенно в отрасли. Как известно, более опытные разработчики быстрее извлекают пользу из инструментов ИИ.

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

Не ограничивайтесь написанием кода

Если на что-то и указывают все метрики ИИ, так это на то, что кодирование с помощью ИИ является наименее интересным сценарием использования ИИ. И сосредоточение на нем говорит о том, что компании не понимают всего жизненного цикла разработки ПО.

Для Тачо важным преимуществом сейчас является снижение стоимости экспериментов с помощью быстрого создания прототипов на основе ИИ.

«Любой, кто работал в команде разработчиков ПО, знает, что есть много работы, которая происходит до и после написания самого кода. При работе над продуктом мы исследуем и тестируем идеи, проверяем наши предположения и неизбежно сокращаем объем работы, чтобы уложиться в наши возможности по разработке», — отмечает Ханна Фоксвелл, консультант Leapter, корпоративного инструмента для ИИ-кодирования.

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

Настоящим толчком к внедрению ИИ должны стать измерение и оптимизация процесса движения продукта от подсказки ИИ до производства, — говорит Фоксвелл: «Дело не в том, чтобы быстрее написать больше кода».

Потому что больше кода не означает лучший код.

Число строк кода — важная метрика, но ее увеличение может быть как положительным показателем, так и свидетельствовать о том, что кодовая база становится все сложнее. На данный момент наиболее экономящим время разработчиков сценарием использования ИИ, выявленным в ходе исследования DX, является интерпретация и объяснение трассировки стека. Хотя в коде, сгенерированном ИИ, зачастую больше ошибок, которые сложнее найти, инструменты ИИ в настоящее время эффективно справляются с отладкой методом «утенка» — парным программированием человека с ИИ, когда вы обсуждаете проблему на естественном языке.

По словам Тачо, оптимизация производительности разработчиков «на самом деле заключается в снижении когнитивной нагрузки, поиске и соединении людей с нужной информацией, когда она им нужна».

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

«Код — это средство, которое мы используем для создания программ, но отличное ПО — это гораздо больше, чем просто код! Романы также пишутся с помощью слов, и все же для создания достойного прочтения романа требуется мастерство, выходящее далеко за рамки умения написать тысячи грамматически правильных предложений», — приводит аналогию Орос.

Необходим более целостный взгляд на качество и мастерство разработки ПО, особенно в эпоху ИИ. По словам Ороса, на фоне способности больших языковых моделей (LLM) молниеносно генерировать код растет необходимость гораздо лучше понимать и оценивать «скрытые» части программной инженерии, которые не связаны с написанием кода. И по мере того как будет писаться все больше кода, потребуется перефокусировка на создание и поддержку качественного ПО.