Когда использование инструмента грозит потерей качества.

Думаете, что 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 удваивается — процент кода, который выбрасывается менее чем через две недели. 

  

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 здесь не помогает. Более того, мешает — предлагает технически правильные решения, которые не вписываются в архитектуру проекта или дублируют существующую функциональность.

Так кто прав?

Парадокс в том, что эти исследования измеряли разные вещи в разных условиях:

Паттерн очевиден:

• Junior/Middle + незнакомые проекты + простые задачи = AI помогает сильно

• Senior + знакомые проекты + сложные задачи = AI может замедлить

Чем сложнее кодовая база и опытнее разработчик, тем меньше выигрыш от AI. В какой-то момент кривая переходит в отрицательную зону.

Что тогда измерять: скорость vs качество

Если хотите сравнить метркии по написанию кода с AI и без AI у себя, смотрите не только на скорость, но и на качество, процесс и опыт разработчика. Только комплексный подход показывает реальную картину. На что можно ориентироваться:

Скорость (индивидуальная): время до первой компиляции, время до готового пулл-реквеста, среднее время фикса бага средней важности, время на поиск информации (как часто смотрите документацию).

Качество (объективное): процент пулл-реквестов, залитых с первого раза без доработок, процент прохождения CI с первой попытки, плотность дефектов (баги на 1000 строк), индекс поддерживаемости (SonarQube умеет считать), переписывание кода через 7-14 дней.

Процесс (командный): время от коммита до прода (DORA метрика), время цикла, частота деплоев, процент сломанных деплоев, среднее время восстановления.

Опыт разработчика (субъективное, но важное): когнитивная нагрузка (самооценка или через носимые устройства типа измерения вариабельности пульса), частота состояния потока, количество переключений контекста, удовлетворенность работой.

Только глядя на все эти метрики вместе, можно понять: ускорили разработку или просто перераспределили проблемы на другие этапы пайплайна.

А вы измеряли реальное влияние AI на вашу продуктивность? Делитесь в комментариях!