GitHub Copilot стал одним из первых массовых AI-инструментов для программистов, по которым появились не только опросы и маркетинговые кейсы, но и контролируемые эксперименты с рандомизацией доступа. Самые обсуждаемые цифры пришли из двух разных миров: коротких стандартизированных задач и полевых rollout-ов внутри больших компаний. Ниже — обзор именно этого корпуса доказательств в историческом срезе 2023–2024 годов, потому что ваш бриф фиксирует 2024 год как опорную точку. Главный вывод простой: эффект есть, но его размер и смысл резко меняются в зависимости от того, измеряете ли вы прохождение одной задачи, выпуск pull request или качество кода после ревью.
Коротко
- Самая известная цифра по Copilot — 55,8% быстрее — взята из контролируемого эксперимента Peng et al. и подтверждена официальным разбором GitHub; это не «средний эффект для всей разработки», а результат на одной изолированной задаче.
- Полевые эксперименты в Microsoft и Accenture, опубликованные в 2024 году, показывали более умеренный эффект в реальных рабочих процессах: в Accenture GitHub сообщал о 8,69% роста числа pull request и 84% роста successful builds; в Microsoft черновик MIT давал более широкий, но менее точный диапазон оценок.
- К концу 2024 года данные не подтверждали обязательный обмен «скорость в обмен на качество». По данным GitHub, в отдельном RCT 2024 года код с Copilot чаще проходил тесты и чуть чаще одобрялся; в open-source исследовании 2024 года рост продуктивности не сопровождался изменением code quality, но выросло время интеграции.
- На практике важнее не абстрактный «эффект ИИ», а соответствие задач, фактическое использование, обучение, поддержка менеджеров и выбранная метрика. Изолированная задача почти всегда даст более крупный сигнал, чем реальная организация.
- Этот текст сознательно ограничен срезом 2023–2024. Переносить те цифры на инструменты и агентные режимы 2026 года напрямую нельзя: продукт, модели и сценарии использования уже другие.
Контекст
С производительностью разработчиков есть старая проблема: её трудно измерять честно. Время на задачу, число строк кода, число commit, число pull request, merge rate, build success и субъективное ощущение «я работаю быстрее» — всё это разные вещи. Именно поэтому вокруг Copilot быстро возникли два конкурирующих нарратива: «разработчики стали кодить в разы быстрее» и «это просто очередной инструмент с шумными метриками».
Для экономического разговора о влиянии ИИ на труд важны не опросы сами по себе, а исследования, где есть хоть какая-то причинная идентификация. В случае Copilot это либо контролируемые эксперименты с случайным распределением доступа, либо полевые rollout-ы, где лицензии раздаются случайной подвыборке сотрудников, а затем измеряется реальная рабочая телеметрия.
Но даже здесь есть методологическая тонкость. В полевых исследованиях разработчиков обычно не заставляли пользоваться Copilot: им случайно давали доступ, а дальше смотрели, кто действительно начал использовать инструмент. Поэтому часть корпоративных работ оценивает не «эффект кнопки Copilot как таковой», а эффект через так называемый encouragement design: случайно выдали доступ, а фактическое использование потом оценили через инструментальные переменные.
Метод
В этот обзор включены исследования, которые к концу 2024 года давали наиболее полезную причинную или близкую к причинной картину по GitHub Copilot и похожим coding assistants. Я сознательно разделяю их на три слоя.
- Контролируемая задача: один и тот же programming task, случайное распределение доступа, почти лабораторная среда.
- Полевой rollout: разработчики работают над обычным продакшен-кодом, а исследователи измеряют pull request, commits, builds и другие рабочие сигналы.
- Внешняя проверка: исследования не обязательно про Copilot, но про близкий класс coding assistants, чтобы понять, насколько эффект зависит от одного конкретного вендора.
Основные источники здесь: Peng et al. (февраль 2023), The Productivity Effects of Generative AI: Evidence from a Field Experiment with GitHub Copilot из MIT Exploration of Generative AI (март 2024), официальный разбор GitHub по Accenture от 13 мая 2024, GitHub RCT по качеству кода от 18 ноября 2024, а также внешний полевой эксперимент BIS по CodeFuse от сентября 2024.
Отдельно я использую open-source исследование Song, Agarwal и Wen как проверку внешней валидности. Это не RCT, а generalized synthetic control, поэтому по силе причинного вывода оно слабее рандомизированных дизайнов, но полезно для разговора о коллективной разработке.
Результаты
| Исследование | Дизайн | Что измеряли | Что получилось | Что ограничивает вывод |
|---|---|---|---|---|
| Peng et al., февраль 2023 | Контролируемый эксперимент; по статье — 95 профессиональных разработчиков рандомизированы, задача: HTTP server на JavaScript | Время до прохождения тестового набора и доля завершивших задачу | 55,8% быстрее; GitHub также приводил среднее время 1 ч 11 мин против 2 ч 41 мин без Copilot | Одна короткая задача, среда далека от реальной организации; Copilot той эпохи был продуктом на базе Codex, а не сегодняшних агентных режимов |
| Cui et al. / MIT, март 2024, Microsoft | Полевой experiment / encouragement design; по тексту черновика — 1 749 разработчиков, сентябрь 2022 — март 2023 | Pull requests, successful builds, lines of code changed | В предварительном MIT-тексте — 12,92–21,83% больше pull requests в зависимости от спецификации; SLATE-оценка давала рост примерно до 22% | Низкий uptake в начале, затем контрольная группа тоже получила доступ; оценки шумные и сами авторы называют их предварительными |
| Cui et al. / MIT + GitHub, март–май 2024, Accenture | Полевой experiment; по MIT-тексту — 311 разработчиков после исключений | Pull requests, builds, adoption telemetry | GitHub сообщал о 8,69% роста pull requests и 84% роста successful builds; MIT-черновик показывал близкие оценки для PR и ещё более широкий диапазон по builds | Метрики зависят от организационных практик; authors сами отмечали, что pull request в Accenture не всегда идеально отражает индивидуальную продуктивность |
| GitHub code quality RCT, ноябрь 2024 | Рандомизированное исследование; по данным GitHub — 202 валидные работы опытных разработчиков | Прохождение 10 unit tests, blind review, approval | По данным GitHub, код с Copilot имел 53,2% более высокую вероятность пройти все 10 тестов, 13,6% больше строк на один readability error и 5% более высокий approval rate | Источник вендорский; независимой академической репликации именно этих цифр на конец 2024 года не было |
| BIS / Ant Group CodeFuse, сентябрь 2024 | Полевой experiment на близком инструменте, не Copilot; по paper — 1 219 программистов | Объём output code, использование подсказок | По working paper BIS — 55% рост code output в среднем; примерно треть прироста объяснялась непосредственно сгенерированным кодом; у junior-сотрудников эффект достигал 67% | Это не GitHub Copilot, а другая корпоративная система; ключевая метрика — lines of code, а не продуктовая ценность или поддерживаемость |
1. На изолированной задаче эффект действительно крупный
Если брать самый цитируемый результат, то это работа Peng et al., опубликованная на arXiv 13 февраля 2023 года и затем пересказанная GitHub в исследовательском посте Research: quantifying GitHub Copilot’s impact on developer productivity and happiness. В этой постановке разработчики с Copilot в среднем завершали задачу на 55,8% быстрее. Это сильный результат, но важно не потерять контекст: речь шла об одной стандартизированной задаче на написание HTTP-сервера, а не о длинном цикле командной разработки.
2. В реальной организации эффект заметно скромнее, но не исчезает
В марте 2024 года MIT опубликовал полевой разбор rollout-ов Copilot в Microsoft и Accenture. Самый важный сдвиг здесь не в размере цифр, а в дизайне: исследователи уже смотрят не на одиночную учебную задачу, а на обычный производственный поток. В Microsoft, по тексту черновика, оценки для pull requests находились в диапазоне 12,92–21,83% в зависимости от спецификации, но precision страдала из-за слабого uptake в treatment-группе и последующего доступа control-группы к инструменту.
В Accenture сигнал выглядел чище. В официальном посте GitHub от 13 мая 2024 года и в MIT-тексте фигурирует рост на 8,69% по pull requests и на 84% по successful builds. То есть картина становится более прагматичной: да, ускорение есть, но оно уже не похоже на лозунг «все стали вполовину быстрее». Скорее речь о том, что часть команд стала чаще доводить изменения до состояния, совместимого с основным пайплайном.
3. Данные 2024 года не подтверждали автоматический провал качества
Сам по себе рост throughput мало что значит, если качество падает и работа просто перекладывается вниз по конвейеру. Поэтому важен GitHub RCT по качеству, опубликованный 18 ноября 2024 года. По данным GitHub, участники с Copilot чаще проходили все 10 unit tests, писали код с меньшим числом readability problems на строку и немного чаще получали approval в blind review. Это не доказывает, что Copilot «улучшает качество кода вообще», но по крайней мере не подтверждает неизбежный trade-off «быстрее = хуже».
Внешняя проверка даёт более сдержанную картину. В open-source paper The Impact of Generative AI on Collaborative Open-Source Software Development: Evidence from GitHub Copilot, выложенном на arXiv 2 октября 2024 года, авторы оценивали проектный уровень и получили 6,5% роста project-level productivity, 5,5% роста individual productivity и 5,4% роста participation, но одновременно 41,6% роста integration time. При этом авторы не обнаружили изменений в code quality. Для практики это важное предупреждение: даже если индивидуальный вклад ускоряется, координационные издержки команды никуда не деваются.
4. Эффект сильно неоднороден
Почти все работы намекают на одну и ту же вещь: «средний эффект» скрывает очень разные режимы использования. В Peng et al. больше выигрывали менее опытные разработчики, более возрастные участники в рамках выборки и те, кто и так много времени проводил за кодом. В BIS working paper по CodeFuse значимый эффект в основном наблюдался у junior-сотрудников; senior-разработчики пользовались подсказками реже, хотя acceptance rate у принятых подсказок был близким.
Дополнительную подсказку даёт технический отчёт Microsoft Generative AI in Real-World Workplaces. В описанном там малом лабораторном исследовании по знакомой задаче Copilot дал 36% time-savings, а по незнакомой задаче существенной разницы не нашли. Это хорошо согласуется с общей логикой: Copilot лучше всего монетизирует знакомый, локальный и хорошо специфицированный фрагмент работы.
Интерпретация
Если собрать корпус 2023–2024 годов воедино, получается не сенсация, а довольно земная картина. Copilot и близкие инструменты действительно могут повышать производительность программистов, но эффект надо читать через единицу анализа.
- На узкой задаче измеряется почти верхняя граница краткосрочного выигрыша от code completion и сужения поискового пространства.
- В продакшене измеряется смесь из полезности модели, трения внедрения, качества онбординга, культуры review и того, насколько выбранная метрика вообще отражает полезную работу.
- На командном уровне добавляется ещё один слой: coordination cost. Быстрее написать код — не то же самое, что быстрее и дешевле встроить его в общий кодовый базис.
Наш комментарий
На наш взгляд, главная практическая ошибка — превращать число 55,8% в универсальный ROI для закупки лицензий. Эта цифра описывает очень конкретный режим: короткая задача, высокая управляемость эксперимента, почти полное внимание к coding task и продукт версии 2022–2023 годов. Для engineering-руководителя куда полезнее ориентироваться на более «скучные» показатели: adoption, review latency, build success, rework, merge rate, incident rate и распределение эффекта по типам задач.
На наш взгляд, в корпоративной среде Copilot стоит рассматривать не как «ускоритель набора текста», а как изменение процесса. Если rollout не сопровождается обучением, правилами использования и пересмотром того, какие задачи действительно стоит отдавать ассистенту, полевой эффект почти наверняка окажется ниже лабораторного. В этом смысле полевые эксперименты 2024 года важнее красивых демо: они показывают не только потенциал инструмента, но и цену внедрения.
Ограничения и критика
Во-первых, исторический горизонт. Этот обзор специально ограничен публикациями и данными, доступными к концу 2024 года. Более поздние оценки уже существуют, но включать их сюда без смены рамки темы было бы неверно.
Во-вторых, версия продукта. В работе Peng et al. прямо указано, что GitHub Copilot был системой на базе Codex. Нынешние Copilot-режимы, чаты, multi-file editing и агентные сценарии — это уже другой класс инструмента. Поэтому перенос старых коэффициентов в сегодняшние закупочные модели ненадёжен.
В-третьих, метрики несовершенны. Pull request, commits, lines of code и builds — это прокси. Они могут хорошо ловить локальный сдвиг в throughput, но не обязаны совпадать с бизнес-ценностью, поддерживаемостью кода через шесть месяцев или снижением числа инцидентов.
В-четвёртых, часть ключевых данных идёт от вендора или от исследований в партнёрстве с вендором. Это не делает результаты автоматически неверными, но повышает планку к независимой репликации. На конец 2024 года именно по Copilot такой репликации было ещё немного.
В-пятых, полевые дизайны страдают от неполного использования инструмента. В Microsoft uptake был медленным, а позже control-группа тоже получила доступ. Это не ломает причинную логику полностью, но делает оценки шумнее и смещает фокус с «эффекта использования» на «эффект доступа при реальном внедрении».
В-шестых, качество и безопасность закрыты не полностью. GitHub к концу 2024 года показал положительный сигнал по quality, а open-source paper не нашёл ухудшения качества, но это не то же самое, что долгосрочная проверка на техдолг, архитектурную деградацию и security defects в больших кодовых базах.
Заключение
Если ограничиться доказательствами 2023–2024 годов, то самый осторожный вывод такой: AI-assisted coding действительно способен повысить продуктивность разработчиков, но размер выигрыша зависит от постановки задачи и зрелости внедрения. Число 55,8% полезно помнить как лабораторный ориентир, но для реальной организации более правдоподобны умеренные эффекты на throughput и mixed outcomes на уровне команды.
Для практики это означает простое правило: не покупайте нарратив, покупайте измерение. Лучший способ понять ценность Copilot для вашей команды — собственный пилот с рандомизацией доступа или ступенчатым rollout-ом и заранее выбранным набором метрик качества, скорости и доработок.
Источники
- Peng, Sida; Kalliamvakou, Eirini; Cihon, Peter; Demirer, Mert. The Impact of AI on Developer Productivity: Evidence from GitHub Copilot
- Microsoft Research. The Impact of AI on Developer Productivity: Evidence from GitHub Copilot
- GitHub Blog. Research: quantifying GitHub Copilot’s impact on developer productivity and happiness
- Cui, Zheyuan (Kevin) et al. The Productivity Effects of Generative AI: Evidence from a Field Experiment with GitHub Copilot
- GitHub Blog. Research: Quantifying GitHub Copilot’s impact in the enterprise with Accenture
- GitHub Blog. Does GitHub Copilot improve code quality? Here’s what the data says
- Gambacorta, Leonardo; Qiu, Han; Shan, Shuo; Rees, Daniel M. Generative AI and labour productivity: a field experiment on coding
- Song, Fangchen; Agarwal, Ashish; Wen, Wen. The Impact of Generative AI on Collaborative Open-Source Software Development: Evidence from GitHub Copilot
- Microsoft Research. Generative AI in Real-World Workplaces
FAQ
Можно ли говорить, что Copilot делает программистов на 55,8% продуктивнее?
Нет. Корректнее говорить, что в одном контролируемом эксперименте на короткой стандартизированной задаче группа с Copilot завершала работу на 55,8% быстрее. В полевых исследованиях в реальных организациях эффект был заметно скромнее.
Почему полевые эксперименты дают меньший эффект, чем лабораторные?
Потому что реальная разработка включает review, координацию, ожидание, знакомство с кодовой базой и неполное использование инструмента. Лаборатория измеряет почти чистый эффект на coding task, а поле — эффект инструмента внутри всей рабочей системы.
Ухудшается ли качество кода?
На конец 2024 года однозначного подтверждения ухудшения не было. Вендорский RCT GitHub показывал положительный сигнал по functional quality и approval, а open-source исследование не находило изменения code quality, хотя фиксировало рост integration time.
Что стоит измерять в собственном пилоте?
Минимальный набор — adoption, review latency, merge rate, successful builds, rework после merge, incident rate и разбивка по типам задач. Если вы хотите честный вывод, измеряйте не только скорость написания, но и downstream-эффекты.