Измерение продуктивности при написании кода с ИИ

Повышают ли ИИ-инструменты для написания кода продуктивность разработчиков - вопрос эмпирический, и почти каждый опубликованный ответ скомпрометирован тем, как именно его измеряли. Ошибки здесь не экзотические - это стандартные проблемы, давно каталогизированные в гуманитарных и естественных науках. Они возникают потому, что программная инженерия обычно выстраивает дизайн исследований сама, не заимствуя эту дисциплину. В twelve-ways-wrong-ai-coding (Грег Уилсон) собран наиболее полный их перечень; на этой странице повторяющиеся типы ошибок сведены воедино и к каждому привязаны самые весомые свидетельства.

В компьютерных науках эта дисциплина существует с 1991 года: книга Раджа Джейна art-of-computer-systems-performance-analysis разбирает планирование экспериментов, выбор рабочей нагрузки и статистическую обработку результатов измерений. Литература по написанию кода с ИИ по большей части заново переоткрывает её главы на собственном горьком опыте.

Типы ошибок

Суррогатные метрики и закон Гудхарта. Количество строк кода, число коммитов, закрытые PR и процент принятых подсказок легко подсчитать, но все они измеряют активность, а не ценность. Рост числа строк на 40% на одного разработчика измеряет лишь многословие; удаление запутанного кода и замена его более компактным - это прогресс, который в такой метрике выглядит как провал. Как только любой из этих показателей становится целью, он перестаёт отражать то, что вас волновало: разработчики делают больше мелких коммитов или дробят тикеты. Процент принятия подсказок - самый наглядный пример: корпоративное исследование с участием 400 разработчиков показало уровень принятия 33% при высокой удовлетворённости и полном отсутствии оценки того, был ли принятый код корректным или безопасным.

Отсутствие контрольной группы и контрфактуала. Сравнения "до и после" приписывают все изменения за период внедрённому инструменту, хотя за это же время вы нанимали людей, переписывали CI и меняли поставщиков. Сравнение разработчиков с ИИ против контрольной группы, использующей "ничего", ещё хуже: такого базового уровня не существует, поскольку у реальных разработчиков без LLM всё равно есть документация, коллеги и время на размышления. Внутренняя валидность требует правдоподобного контрфактуала, которого большинству индустриальных отчётов не хватает.

Эффект новизны и Хоторнский эффект. Новые инструменты кажутся быстрыми, а люди под наблюдением работают иначе. Четырёхнедельное исследование, зафиксировавшее прирост, обнаружило лишь четырёхнедельный прирост. Эффекты, определяющие реальную ценность инструмента - атрофия навыков (dont-outsource-learning), накопление техдолга, изменение взаимодействия в команде, - проявляются месяцами. Опросы с самооценкой добавляют третий загрязняющий фактор: склонность давать социально одобряемые ответы, которая проявляется сильнее всего, когда инструмент выбрало руководство.

Ошибка отбора. Сравнение добровольцев с теми, кто не вызвался сам, сопоставляет две разные группы людей, а не два условия. Ранние последователи изначально сильнее мотивированы и нередко показывают более высокую производительность; одно лонгитюдное исследование показало, что пользователи Copilot'а были активнее остальных ещё до того, как инструмент вообще появился. Это самый частый изъян индустриальных отчётов, поскольку такое исследование дешевле всего провести.

Индивидуальный уровень против системного. Написание кода на 30% быстрее ничего не меняет, если время от взятия тикета до выкатки в продакшен остаётся прежним: написание кода не было узким местом, а увеличение объёма сгенерированного кода означает рост нагрузки на ревью. Именно здесь локальный выигрыш превращается в глобальный проигрыш.

Наиболее убедительные свидетельства

Четыре результата несут основной вес, поскольку в них устранены перечисленные выше методологические ошибки:

• РКИ от METR (+19% ко времени). Рандомизированное контролируемое испытание (RCT) с участием опытных open-source разработчиков показало, что ИИ-инструменты увеличили время выполнения задач на 19% - прямо противоположно тому, что прогнозировали сами участники. Реальная контрольная группа на реальных (не с нуля) задачах, поэтому этот результат весомее цифры "на 55% быстрее" у Copilot'а, полученной в 90-минутном упражнении по разработке с нуля.
• Xu 2025 (senior −19% / +6.5% к ревью). Менее опытные разработчики увеличили выработку, тогда как сеньор-разработчики потеряли 19% собственной продуктивности, поглощая возросшую на 6.5% нагрузку на ревью кода, сгенерированного ИИ. Это прямое измерение конфликта между индивидуальным и системным уровнями.
• He 2026 (807 репозиториев). В 807 open-source репозиториях, внедривших Cursor, наблюдался заметный, но кратковременный рост скорости наряду со стойким увеличением сложности кода и предупреждений статического анализа. Эффект новизны и отложенные издержки, разделённые благодаря измерению во времени.
• Liu 2026 (300k+ коммитов, >15% с дефектами). Более 15% из более чем 300 000 коммитов, написанных с помощью ИИ, привнесли как минимум одну проблему с качеством, и почти четверть из них сохранилась в долгосрочной перспективе: "простая половина" (генерация) выглядит отлично, пока "сложная половина" (корректность, поддержка) деградирует.

Связь с другими страницами

danluu-ai-coding-testing доказывает тот же тезис на практике: единичные итоговые цифры скрывают разброс от прогона к прогону, достаточный для обоснования любого вывода, поэтому "покажите мне распределение". no-silver-bullet-llms приводит данные DORA/CircleCI о нестабильности, которые противоречие между индивидуальным и системным уровнями предсказывает на этапе доставки. reviewing-ai-code формулирует этот же конфликт как жёсткий потолок пропускной способности: скорость ревью упирается примерно в 400 LOC/час, так что ускорение генерации лишь сдвигает узкое место. constraint-decay объясняет, почему замеры времени на задачах с нуля вводят в заблуждение: агенты сильны на слабо специфицированной работе и деградируют по мере накопления производственных ограничений. dont-outsource-learning описывает долгосрочные издержки, которые исследования с коротким окном новизны структурно не способны заметить.