Дашборд вам врет: как измерить реальное влияние ИИ на разработку?

Больше токенов — больше влияния? Отнюдь. Недавно одна крупная софтверная компания была уверена, что наконец-то решила один из самых острых вопросов последнего года: каково реальное влияние инструментов ИИ на производительность ее R&D. Дашборды выглядели отлично, графики росли, показатели внедрения повышались, и один показатель постоянно повторялся в презентациях для руководства: AI Code Percentage — метрика, призванная показать, какая часть кода, попадающего в систему, была написана с помощью искусственного интеллекта. На первый взгляд это звучит как отличный KPI: если число растет, значит, внедрение идет успешно. Но что это использование изменило на самом деле?

Здесь начинается проблема. Менеджеры по разработке, вице-президенты и технические директора (CTO) на самом деле не хотят знать только то, сколько кода было написано с помощью ИИ. Им нужно понимать, стала ли разработка быстрее, сохраняется ли качество кода, изменилась ли нагрузка на тестирование и создает ли инвестиция в новые инструменты ценность для организации. Показатель AI Code Percentage отражает степень использования, но он не может ответить на вопрос о влиянии в одиночку.

Идеальное решение может вам врать

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

Эти дашборды могут быть очень точными в описании активности внутри инструмента, но эта информация ограничена вопросом о том, сколько использовали ИИ. Она не обязательно объясняет, что произошло со скоростью поставки, нагрузкой на ревью, качеством кода или общей стоимостью работы. AI Code Percentage — полезный показатель для понимания масштабов внедрения, но он не может делать выводы о продуктивности, качестве и бизнес-ценности.

Как измерять атрибуцию кода на практике?

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

Когда система измерения пытается оценить эффективность без прямой связи между мирами, она вынуждена делать грубые оценки. Она видит, что определенный разработчик использовал в тот день Cursor или Claude Code, и видит, что он загрузил три Pull Request. Без возможности прямой сверки система может приписать влияние ИИ всей деятельности, выполненной за этот период времени. Так создается Attribution Gap (разрыв организационной атрибуции), при котором мы знаем, что было использование ИИ, и мы знаем, что получили результат, но ошибочно основываем связь между ними на косвенном выводе вместо надежной атрибуции к конечному продукту.

Так как же измерять правильно? Переход от измерения использования (Usage) к атрибуции кода (Attribution) — это не теоретическая идея, и она требует совершенно другой инженерии данных. Практическое решение требует создания инфраструктуры, которая напрямую соединяет корпоративное озеро данных GenAI (GenAI Data Lake) с реальной Git-активностью разработчиков и анализирует изменения в коде в режиме реального времени.

Вместо того чтобы смотреть на продолжительность активности в инструменте, система анализирует продукт на уровне отдельной строки кода. Например, когда разработчик завершает сложную задачу, источником которой является конкретный тикет в Jira, система распознает, что из 120 новых строк кода, созданных в том же Pull Request, источником около 50 строк являются прямые предложения кода агента, а остальные строки — результат человеческой архитектуры.

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

Метрика Code Survival: система проверяет, сколько кода, созданного с помощью ИИ, выживает внутри кодовой базы (Codebase) спустя две недели или месяц. Если высокий процент его удаляется или переписывается снова и снова человеческими разработчиками в последующие дни, это признак того, что быстрое внедрение создает технический долг, а не реальную продуктивность.
Метрика Review Friction: вместо того чтобы предполагать, что разработка сократилась, измеряют время, которое требуется Pull Request для получения одобрения, и количество циклов правок, которые он требует. Так можно выявить случаи, когда код, созданный быстро с помощью ИИ, сокращает этап написания, но увеличивает нагрузку на проверку и верификацию других разработчиков.
Метрика Escaped Bugs: сопоставление данных ИИ с отчетами о неисправностях позволяет сравнить уровень ошибок, регрессий и повторного открытия тикетов в работе, на которую повлиял ИИ, с аналогичной работой, на которую он не повлиял.

Уроки и практические рекомендации

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

Не измеряйте активность, а измеряйте результаты: отслеживание количества активных лицензий или объема токенов в организации дает индикацию об объеме финансовых расходов, но не о продуктивности. Начните связывать сигналы ИИ напрямую с кодом, который был написан на самом деле на уровне Commit.
Выявляйте новые «узкие места»: инструменты ИИ действительно сокращают время написания первичного кода, но могут перенести нагрузку на этап Code Review. Если даже небольшие Pull Request, которые должны быть относительно простыми для проверки, ожидают дольше ревью или требуют больше циклов правок, когда они включают вклад ИИ — возможно, команда перенесла «узкое место» с этапа написания на этап верификации.
Примите компромисс прозрачности против удобства: переход к точному измерению требует более сложной инфраструктуры данных и может обнаружить, что дорогие инструменты, которые вы приобрели, не обеспечивают желаемого эффекта. Менеджеры по разработке должны быть готовы отказаться от «зеленых» и успокаивающих дашбордов в пользу данных правды, которые могут полностью изменить бюджетные решения и планы внедрения организации.

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