[2/2] Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (Рубрика AI)
Продолжая пост про исследование, расскажу про полученные результаты
- Было получено статистически значимое замедление на 19% при использовании AI-инструментов с 95% доверительным интервалом
- Авторы отдельно указали на ограничения обобщаемости этих выводов -- Опыт разработчиков. Результаты специфичны для опытных разработчиков (5+ лет опыта с репозиториями). Для менее опытных разработчиков результаты могут быть противоположными. -- Размер и сложность кодовых баз. Исследование проводилось на крупных, зрелых проектах (1M+ строк кода). На меньших или новых проектах AI может показать положительный эффект. -- Знакомство с проектом. Разработчики работали в знакомых им репозиториях. -- Тип задач. Задачи уже были декомпозированы до размера не больше 2х часов, что может не отражать весь спектр разработческих задач. -- Внешняя валидность. Результаты не означают, что AI-инструменты бесполезны во всех контекстах разработки.
По результатам авторы сдели следующие выводы
- AI-инструменты замедляют опытных разработчиков на 19% при работе в знакомых кодовых базах, что противоречит ожиданиям как разработчиков (предсказывали ускорение на 24%), так и экспертов (предсказывали ускорение на 38-39%).
- Также они поразмышляли насчет факторов замедления, выделив 5 основных, хотя и сделали такую ремарку
However, we strongly caution against over-indexing on the basis of any individual pieces of evidence, as we are not powered for statistically significant multiple comparisons when subsetting our data. This analysis is intended to provide speculative, suggestive evidence about the mechanisms behind slowdown. Вот эти факторы
- Чрезмерный оптимизм относительно полезности AI
- Высокая знакомость разработчиков с репозиториями
- Большие и сложные кодовые базы
- Низкая надежность AI (принимается <44% предложений)
- Неявный контекст репозиториев, недоступный AI
В итоге, авторы подчеркивают, что результаты не означают, что AI-инструменты бесполезны.
А теперь поговорим про проблемы исследования и почему его результаты надо воспринимать с осторожностью 1. Малый размер выборки Только 16 разработчиков, что ограничивает статистическую мощность, а также ставит под вопрос репрезентативность выборки относительно генеральной совокупности. Сетап эксперимента не позволил ответить на вопросы, какие факторы повлияли на результаты 2. Краткосрочность Исследование не учитывает долгосрочные эффекты обучения использованию AI-инструментов. 3. Специфичность контекста Были выбраны крупные open source репозитории, что говорит о том, что результаты могут не обобщаться на другие типы проектов по размеру или специфике (web, мобильная разработка) 4. Эффект Хоторна Участники знали о том, что участвуют в исследовании, что могло влиять на их поведение. 5. Субъективность измерений Время выполнения задач измерялось самими разработчиками, что могло вносить систематические ошибки. 6. Определение продуктивности Исследование фокусировалось только на времени выполнения, не учитывая другие аспекты продуктивности: качество кода (главное было пройти code review), удовлетворенность работой
Итого, мне кажется сам эксперимент интересным, но я больше верю в измерения практических эффектов в организациях, где есть измерение developer productivity и AI там добавляется в экосистему разработчиков постепенно и через a/b эксперименты на большом масштабе, которые позволяют отследить эффекты. Конкретно, про такие подходы можно почиитать в постах
- Про Google и их подходы из серии статей "Developer Productivity for Humans" (подробнее в постах: 1 и 2)
- Про подход запрещенной в России компании Meta, который они описали в статье "What's DAT? Three Case Studies of Measuring Software Development Productivity at Meta With Diff Authoring Time" (подробнее в постах: 1, 2 и 3)
- Ну или на крайний случай можно глянуть мое выступление "Зачем заниматься темой developer productivity в большой компании"
#AI #ML #Management #Leadership #Software #SoftwareDevelopment #Architecture #Metrics #Devops #Processes