Does AI Actually Boost Developer Productivity? (100k Devs Study) (Рубрика #AI)

Посмотрел интересное 20 минутное выступление Yegor Denisov-Blanch из Stanford University про измерение продуктивности инженеров. Егор представил результаты трёхлетнего исследования Стэнфорда по производительности 100k разработчиков из 600 компаний. Результаты исследования такие: AI повышает продуктивность в среднем лишь на 15-20%, причём эффект резко варьируется в зависимости от контекста задачи, зрелости кода, популярности языка и размера репозитория. Ниже представлены основные мысли из этого выступления + странички исследования

1. Почему существующие оценки продуктивности ненадёжны?
- Большинство опубликованных работ финансируются поставщиками инструментов (GitHub Copilot, Sourcegraph Cody), что искажает выборку и метрики.
- Фокус на счётчике коммитов/PR без учёта размера и качества задач приводит к ложному росту "output" (условно у нас больше выход кода, но вот насколько он полезен?)
- Оценки greenfield и игрушечных проектов завышают выгоду ИИ: LLM легко сгенерирует boilerplate, но реальный корпоративный код редко стартует с нуля
- У опросов насчет продуктивности есть проблемы - самооценка продуктивности редко бывает точной, хотя другие факторы типа satisfaction или well-being опросами можно собрать хорошо

2. Как выглядела методология ребят из Stanford?
- Подключение git-репозиториев, среди которых были преимущественно частные репо, это позволяло замкнуть контекст команды
- Оценка кода группой экспертов, где 10-15 архитекторов ставят баллы за качество, поддерживаемость, сложности (кстати, их оценки хорошо кореллировали между собой) - по-факту, это создание разметки для дальнейшего supervised learning
- Обучение модели для воспроизведения экспертной оценки с высокой корреляцией для оцененой экспертами выборки проектов - это позволяет дальше масштабировать эту модель без дорогостоящего ревью
- Классификация изменений - авторы хотели классифицировать изменения на группы "добавление функционала", "удаление", "рефакторинг", "rework" (переделка свежего кода)
- Дальше эту модель применять ретроспективно с 2019 по 2025 год для того, чтобы отследить влияние COVID, LLM-внедрения и т.д

3. Главные численные выводы исследования
- Сырой прирост кода после внедрения ИИ +30-40% - это включает полезный и «rework»-объём
- Уточнённый прирост продуктивности +15-20% - это с поправкой на баг-фиксы
- На сложных задачах прирост чуть больше 0% с большой дисперсией (иногда вместо прироста убыль)
- Если это представлять в виде матрицы 2x2, как любят консультанты, то получим "сложность задачи× зрелость проекта"

Complexity/Type. Greenfield Brownfield
Low-complexity 30-40% выгод 15-20% выгод
High-complexity 10-15% выгод 0-10% выгод, иногда убыток

- На эффективность влияет язык - для популярных языков LLM работают лучше, а для эзотерических хуже.
- На эффективность влияет размер кодовой базы, причем выгода падает логарифмически с ростом объема. Гипотеза в том, что на это влияет ограничения контекстного окна LLM, рост шума и большого количества зависимостей внутри кода (coupling)

Если попробовать вынести практические советы, то они кажутся такими
- Оцените типовую сложность и зрелость своего проекта перед масштабным внедрением LLM-ассистентов
- Старайтесь использовать популярные технологии - по ним обучены лучшие модели и качество подсказок выше
- Для legacy-монолитов проведите пилот на небольших модулях - продуктивность может не повышаться при использовании ассистентов из коробки (аля базовый Cursor)
- Мониторьте "rework"-долю: резкий рост количества кода может создавать иллюзию продуктивности
- Комбинируйте количественный git-анализ с качественным ревью, а не ссылайтесь только на "опрос удовлетворённости команды"

P.S.
Yegor Denisov-Blanch является автором исследования про "ghost" разработчиков, что нашумело в прошлом году. Правда, самого исследования мне найти не удалось, зато есть посты о нем в большом количестве мест.

P.P.S.
Сравните с дизайном эксперимента от METR:)

#Engineering #AI #Metrics #Software #DevEx #Productivity