Can you prove AI ROI in Software Engineering? (Рубрика #AI) Буквально недавно Егор Денисов-Бланш (Yegor Denisov-Blanch) выступил на конференции AI Engineer Code Summit 2025 в Нью-Йорке с таким провокационным докладом:) По-факту, это тизер результатов двухлетнего исследования влияния AI-инструментов на продуктивность разработчиков, охватывающего 120 000+ разработчиков в 600+ компаниях (такой охват как минимум внушает доверие). Кстати, предыдущее выступление Егора "Does AI Actually Boost Developer Productivity?" я уже разбирал и часть тезисов полностью повторяются, а точнее вопросы вида 1. Почему существующие оценки продуктивности ненадёжны? 2. Как выглядела методология ребят из Stanford? 3. Главные численные выводы исследования Но в этом докладе есть и новенькие результаты 1. Медианный прирост продуктивности составляет ~10%, но разброс между лидерами и отстающими постоянно увеличивается. 2. Качество использования AI важнее объёма. Корреляция между количеством потраченных токенов и ростом продуктивности слабая (R² = 0.20). Более того, наблюдается эффект "долины смерти" на уровне 10 млн токенов на инженера в месяц - команды, использующие такой объём, показывают результаты хуже, чем те, кто использует меньше. 3. Чистота кодовой базы критична для AI. Индекс "чистоты окружения" (Environment Cleanliness Index), учитывающий тесты, типы, документацию, модульность и качество кода, показывает корреляцию R² = 0.40 с приростом продуктивности от AI. Чистый код усиливает эффект от AI, а технический долг его нивелирует. 4. AI ускоряет энтропию кодовой базы. Бесконтрольное использование AI ускоряет накопление технического долга, что сдвигает кодовую базу в зону, где AI менее эффективен. Требуется активное управление качеством кода для сохранения преимуществ. 5. Доступ к AI ≠ эффективное использование. В кейсе с двумя бизнес-юнитами одной компании при равном доступе к инструментам использование было сильно разное. Важно измерять не только факт использования, но и как инженеры применяют AI. Ну и собственно автор предлагает свою методологию для измерения ROI из двух частей 1. Измерение использования Access-based (кто получил доступ) vs usage-based (телеметрия API). Usage-based - золотой стандарт, позволяющий ретроспективный анализ через git-историю. 2. Измерение инженерных результатов - Primary metric: Engineering Output - ML-модель, реплицирующая оценку панели из 10-15 независимых экспертов по сложности, времени реализации и поддерживаемости - Guardrail metrics: Rework & Refactoring, Code Quality & Risk, People & DevOps - метрики, которые нужно держать на здоровом уровне, но не максимизировать Забавно, что автор категорически против использования PR counts, lines of code и даже DORA как основных метрик продуктивности. Ну и если анализировать подход автора, то он содержит сильные и слабые стороны (+) Исследовательская методология выглядит солидно. ML-модель, реплицирующая экспертные оценки, проверенная на корреляцию с реальными панельными данными - это правильный подход к измерению сложных качественных аспектов кода. (+) Понимание системных эффектов. Концепция управления энтропией кодовой базы, связь между чистотой кода и эффективностью AI, понимание, что инженеры должны знать, когда не использовать AI (+) Критика DORA как primary metric обоснована. DORA - это индикаторы процесса, а не результата. Их максимизация может вредить (вспомним Goodhart's Law) (+)AI Practices Benchmark с уровнями зрелости (от личного использования до агентной оркестрации) показывает понимание эволюции практик. (-) Background автора не в чистой разработке - у него отсутствует опыт и образование как инженера (-) ML-модель как чёрный ящик. Хотя утверждается, что модель коррелирует с экспертными оценками, детали методологии, датасет для обучения, метрики качества модели не раскрыты в докладе (-) Environment Cleanliness Index экспериментальный. Как именно взвешиваются компоненты индекса? Как он валидирован кроме корреляции с продуктивностью? #Engineering #AI #Metrics #Software #DevEx #Productivity