Когда использование инструмента грозит потерей качества.
Думаете, что AI ускорил работу с кодом? А вы измеряли?
Мы разобрали восемь крупных исследований на тему использования AI в разработке — и везде разные цифры. Одни показывают ускорение, другие замедление, третьи — проблемы с качеством.
Нюанс в том, что сравнивать нужно не только скорость, но и качество кода, время на дебаггинг и код-ревью. Потому что функция может генерироваться за десять минут, но если ревьювер возвращает ее три раза, а баг всплывает через месяц — где ускорение?
Разбираемся, что на самом деле измеряли в исследованиях Google, MIT и других — и почему контекст решает все.
Почему скорость ≠ продуктивность
Когда обсуждают «ускорение разработки с помощью AI», чаще всего имеют в виду time-to-complete — сколько минут заняло написание кода. В реальных командах производительность строится не по принципу «кто быстрее написал фичу», а насколько быстро фича дошла до прода. Без отката и в 3 часа ночи. Это принципиально разные вещи.
Три уровня метрик
Скорость написания — сколько времени от постановки задачи до компиляции кода. Можно нагенерить функцию за 10 минут вместо 30 — AI отлично справляется с шаблонным кодом. Но это только первый этап.
Пропускная способность команды — сколько пулл-реквестов закрывается, какое время от коммита до мерджа, как быстро задачи проходят через пайплайн. Один разработчик завершил задачу на 30% быстрее, но если его пулл-реквест висит в ревью три дня или возвращается на доработку 2-3 раза — общее время до прода только растет.
Delivery performance — как часто деплоим, сколько деплоев ломается, как быстро восстанавливаемся. Здесь начинаются сюрпризы.
Три ловушки восприятия
Код без контекста не живет. AI не знает вашего легаси, архитектурных ограничений и того, что функция для этого уже есть в соседнем модуле. Модели обучали на открытых данных, поэтому они чаще генерируют «правильный, но чужой» код.
Когнитивная иллюзия. Исследование METR: разработчики предсказывали ускорение с помощью AI на 24%, после эксперимента оценивали +20%. Но реальность показала замедление на 19%. Разрыв восприятия — 39 процентных пунктов.
Проблема качества кода. Код пишется быстро, но качество проседает. Об этом ниже — с цифрами.
Данные исследований: скорость vs качество
Теперь, когда мы договорились о метриках, давайте посмотрим на данные. За последние полтора года вышло несколько крупных исследований с прямо противоположными результатами. Разброс — от +55% до -19%. Кто-то явно ошибается, или мы чего-то не понимаем?
Лагерь оптимистов: AI реально ускоряет
Microsoft/GitHub (2023): контролируемый эксперимент
Исследование, которое запустило хайп. Разработчикам дали задачу написать HTTP-сервер на JavaScript — с использованием GitHub Copilot выполнили на 55,8% быстрее. Но это была синтетическая задача в лабораторных условиях: чистый лист, стандартный паттерн, без легаси и код-ревью. Идеальный кейс для AI, но насколько переносится на реальный прод?
MIT/Princeton/Penn: большая выборка, реальные компании
Исследователи из MIT, Princeton и Penn провели эксперимент с 4 867 разработчиками в Microsoft, Accenture и еще одной компанией из Fortune 100. Результат: разработчики, использовавшие GitHub Copilot, в среднем завершили на 26% больше задач. Это уже серьезнее — большая выборка, реальные компании, повседневная работа. Плюс интересный паттерн: наибольший выигрыш получили джуниоры и мидлы.
Google (лето 2024): enterprise-задачи
Google провели исследование с 96 инженерами на сложных enterprise-задачах. Результат: примерно 21% сокращение времени при использовании LLM-моделей.
GitHub × Accenture (2024): метрики процесса
Исследование с фокусом на командные показатели: +8,7% пулл-реквестов на разработчика, +15% merge rate (залито с первого раза), +84% успешных сборок, высокая субъективная удовлетворенность. Здесь смотрели не только на скорость, но и на индикаторы качества.
Лагерь реалистов: все сложнее, чем кажется
GitClear (2024): скорость есть, а качество?
Пока все спорят, кто быстрее пишет, GitClear проанализировали 211 млн измененных строк кода (2020-2024) из репозиториев Google, Microsoft, Meta и 25 крупнейших open-source проектов — и обнаружили тревожные тренды.
8-кратный рост дублирования кода — блоки из пяти и более повторяющихся строк встречаются в десять раз чаще, чем два года назад. В 2024 году впервые copy/paste превысил moved/refactored код. В здоровых проектах разработчики рефакторят и переиспользуют логику. С AI они чаще копируют готовые куски.
46% изменений — полностью новые строки вместо модификации существующих. AI не знает, что нужная функция уже есть в соседнем модуле, поэтому генерирует дубликат.
Code churn удваивается — процент кода, который выбрасывается менее чем через две недели.
Как меняется качество кода с ростом использования AI (2020-2025) | GitClear
DORA 2024: расщепление метрик
DORA Report 2024 (39 000+ респондентов) показывает парадокс: рост использования AI коррелирует с +3,4% к качеству кода и +3,1% к скорости ревью, но одновременно с -1,5% к пропускной способности и -7,2% к стабильности поставки при отсутствии дисциплины процессов.
AI помогает на микроуровне (быстрее писать, быстрее ревьюить), но без правильных процессов вредит на макроуровне. Больше кода → больше потенциальных багов → больше нестабильности. Ускорение одной стадии без оптимизации всего потока в перспективе создает проблемы.
Google (внутренние метрики, 2024): избирательность разработчиков
Google поделились статистикой реального использования: примерно 37% acceptance rate AI-подсказок, до 50% символов кода в IDE идут с AI-автодополнением. Масштаб впечатляет — половина кода пишется с помощью AI. Но acceptance rate 37% показывает, что разработчики избирательны: две трети предложений отклоняются.
Лагерь пессимистов: подождите, все не так просто
METR (июль 2025): главный сюрприз года
Некоммерческая организация METR провела исследование с 16 опытными open-source разработчиками на 246 реальных задачах в mature проектах (22k+ звезд, 1M+ строк кода). Половина задач — с AI (Cursor Pro + Claude 3.5/3.7), половина — без AI.
Результат шокировал: с AI разработчики работали на 19% медленнее. Почему такая разница?
Perception gap: иллюзия ускорения
Самое интересное — разрыв восприятия. До начала разработчики предсказывали ускорение на 24%. После завершения оценивали +20%. Реальность: замедление на 19%. Разрыв между ощущениями и реальностью — почти 40 процентных пунктов. Это системная проблема восприятия.
Почему замедлились? Время уходило на промптинг AI, ожидание генерации (10-30 секунд), проверку сгенерированного кода, отладку неочевидных багов. Экономия на написании оказалась меньше затрат на взаимодействие с AI и валидацию результата.
Ключевое отличие: кто участвовал
Это были senior-разработчики с 5+ годами опыта в конкретных проектах. Они отлично знали кодовую базу, архитектуру, конвенции. Для них написание кода — не узкое место. Узкое место — понимание контекста задачи, дизайн решения, интеграция с существующим кодом.
AI здесь не помогает. Более того, мешает — предлагает технически правильные решения, которые не вписываются в архитектуру проекта или дублируют существующую функциональность.
Так кто прав?
Парадокс в том, что эти исследования измеряли разные вещи в разных условиях:
Исследование | Результат | Участники | Условия | Что измеряли |
GitHub/Microsoft | +55.8% | Разные уровни | HTTP-сервер (синтетика) | Скорость написания |
MIT/Princeton | +26% | 4 867 разработчиков разных уровней | Реальная работа в компаниях | Кол-во завершенных задач |
Google RCT | +21% | 96 инженеров Google | Enterprise-задачи | Скорость написания |
METR | -19% | 16 синьор-разработчиков | Реальные mature проекты | Скорость написания |
GitClear | Падение качества | 211 млн строк кода | Анализ 2020-2024 (Google/MS/Meta) | Дублирование, code churn, дефекты |
Паттерн очевиден:
Junior/Middle + незнакомые проекты + простые задачи = AI помогает сильно
Senior + знакомые проекты + сложные задачи = AI может замедлить
Чем сложнее кодовая база и опытнее разработчик, тем меньше выигрыш от AI. В какой-то момент кривая переходит в отрицательную зону.
Что тогда измерять: скорость vs качество
Если хотите сравнить метркии по написанию кода с AI и без AI у себя, смотрите не только на скорость, но и на качество, процесс и опыт разработчика. Только комплексный подход показывает реальную картину. На что можно ориентироваться:
Скорость (индивидуальная): время до первой компиляции, время до готового пулл-реквеста, среднее время фикса бага средней важности, время на поиск информации (как часто смотрите документацию).
Качество (объективное): процент пулл-реквестов, залитых с первого раза без доработок, процент прохождения CI с первой попытки, плотность дефектов (баги на 1000 строк), индекс поддерживаемости (SonarQube умеет считать), переписывание кода через 7-14 дней.
Процесс (командный): время от коммита до прода (DORA метрика), время цикла, частота деплоев, процент сломанных деплоев, среднее время восстановления.
Опыт разработчика (субъективное, но важное): когнитивная нагрузка (самооценка или через носимые устройства типа измерения вариабельности пульса), частота состояния потока, количество переключений контекста, удовлетворенность работой.
Только глядя на все эти метрики вместе, можно понять: ускорили разработку или просто перераспределили проблемы на другие этапы пайплайна.
А вы измеряли реальное влияние AI на вашу продуктивность? Делитесь в комментариях!
