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