Двенадцать способов ошибиться в оценке ИИ-ассистентов

Майский пост Грега Уилсона 2026 года (greg-wilson-blog) начинается с будничной ситуации: менеджер требует доказательств, что подписка на ИИ-инструменты окупается. Можно посчитать строки кода, закрытые задачи или разослать опросник. Каждый из этих подходов ошибочен, и у каждой ошибки есть конкретное название. В посте разобраны двенадцать подобных промахов, и каждый сопоставлен с методологическими искажениями, давно описанными в гуманитарных и социальных науках: законом Гудхарта, хоторнским эффектом, систематической ошибкой отбора, внутренней валидностью. Здесь важна оговорка: речь идёт о том, как люди оценивают разработку с помощью ИИ, а не о том, что сам такой код плох. С минимальными правками те же двенадцать пунктов применимы к аргументам в пользу agile, TDD и большинства других модных веяний в процессах.

Двенадцать ошибок

1. Подсчёт сгенерированных строк. LLM выдают больше кода, а не лучшие результаты. Рост объёма строк на 40% на разработчика измеряет многословие. Удалить 2000 строк запутанного кода и написать 200 чистых - это прогресс, который в этой метрике выглядит как провал. При этом каждая лишняя строка обернётся тратой времени на чтение, поддержку и отладку в будущем, чего счётчик строк никогда не учитывает.
2. Замер времени на искусственных задачах. Известный результат "на 55% быстрее с Copilot" (Peng 2023) был получен при написании HTTP-сервера на JavaScript с нуля за девяносто минут без каких-либо сторонних обязанностей. Реальная работа - это ориентирование в чужой кодовой базе, неоднозначные формулировки задач, совещания. Скорость на игрушечных проектах с чистого листа ничего не говорит о реальной работе.
3. Сравнение "до и после" без контрольной группы. В июне PR'ы закрываются быстрее, чем в январе, но за это время компания наняла двенадцать инженеров, перестроила CI и сменила облачного провайдера. Без контрольной группы, не переходившей на новые инструменты, приписать изменения этим инструментам нельзя. Для внутренней валидности необходимо правдоподобное контрфактическое сравнение.
4. Опросы разработчиков об их продуктивности. Утверждение "87% отмечают рост продуктивности" (Liang 2024) искажено сразу тремя факторами: хоторнским эффектом (люди ведут себя иначе, когда за ними наблюдают), эффектом новизны (новые инструменты поначалу кажутся быстрыми, но ощущение проходит за несколько недель) и предвзятостью социальной желательности (респонденты отвечают так, как от них ждут, особенно если инструмент выбрало руководство).
5. Подсчёт коммитов, PR'ов и закрытых задач. Именно это предложила McKinsey в 2023 году. Вступает в силу закон Гудхарта: начните считать коммиты, и разработчики станут делать их чаще и мельче; считайте задачи - задачи начнут дробить. Цифры растут, объём работы остаётся прежним.
6. Измерение только лёгкой половины. Генерацию кода измерить просто; ревью, отладку уверенно-неверных подсказок, дыры в безопасности и технический долг - трудно. Анализ более 300 000 коммитов, сгенерированных ИИ, показал, что более 15% содержали как минимум одну проблему с качеством, и почти четверть из них оставалась в коде надолго (Liu 2026). Оценка пяти крупных LLM в 2025 году показала, что ни одна из них не сгенерировала код веб-приложения, соответствующий отраслевым стандартам безопасности.
7. Процент внедрения как показатель успеха. "90% внедрения в инженерном отделе" - это результат закупок: инструмент просто установили и запустили. Это ничего не говорит о том, полезны ли подсказки и верны ли они.
8. Сравнение добровольцев с теми, кто отказался. Сравнение разработчиков, выбравших инструмент добровольно, с теми, кто этого не сделал, сравнивает две разные группы людей, а не два разных условия. Ранние последователи исходно сильнее мотивированы и часто показывают более высокую отдачу - это ошибка отбора. В отраслевых отчётах этот дефект встречается чаще всего, так как провести подобное исследование дешевле всего; одно продольное исследование выявило, что пользователи Copilot были активнее остальных ещё до того, как получили инструмент (Stray 2026).
9. Индивидуальный уровень вместо системного. Если код пишется на 30% быстрее, но время от создания задачи до выкатки в продакшен не изменилось, написание кода никогда и не было узким местом. Одно исследование показало: ИИ помог начинающим разработчикам, но старшие инженеры потеряли 19% собственной продуктивности, взяв на себя возросшую на 6.5% нагрузку по ревью сгенерированного кода (Xu 2025). Оптимизация одного этапа конвейера без учёта остальных - типичный сбой системного мышления.
10. Замеры в период новизны. Четырёхнедельное исследование, зафиксировавшее прирост, зафиксировало лишь четырёхнедельный эффект. По-настоящему важные последствия - атрофия навыков, накопление долга, изменения в совместной работе - проявляются спустя месяцы. Анализ 807 open-source репозиториев, перешедших на Cursor, показал именно такой раскол: крупный, но кратковременный выигрыш в скорости вкупе со стойким ростом сложности и предупреждений статического анализа (He 2026).
11. Процент принятых подсказок как показатель качества. Факт принятия подсказки показывает лишь то, что код выглядел достаточно правдоподобно для нажатия Tab, а не то, что он корректен или безопасен. Корпоративное исследование с участием 400 разработчиков показало среднюю долю принятия в 33% при высокой удовлетворённости, причём корректность и безопасность не отслеживались вовсе (Bakal 2025). Давление дедлайнов повышает процент принятия по совершенно неверным причинам.
12. Сравнение ИИ с полным отсутствием инструментов. Контрольная группа, не использующая вообще ничего, в реальности не существует. Разработчики без LLM всё равно пользуются документацией, советуются с коллегами и думают над задачей. Настоящий вопрос в том, превосходит ли инструмент эти альтернативы, и его задают крайне редко.

Собранные контрсвидетельства

Самый убедительный факт, который приводит Уилсон - рандомизированное контролируемое испытание (Becker 2025, исследование METR), где ИИ-инструменты увеличили время выполнения задач на 19% у опытных open-source разработчиков, хотя сами они ожидали прямо противоположного. Если поставить рядом цифру "на 55% быстрее" у Copilot, выясняется, что у этих двух исследований почти нет общих точек измерения: одно представляет собой изолированный спринт с чистого листа, другое - реальную поддержку существующего кода с контрольной группой. Остальная картина выглядит так же последовательно: падение продуктивности ведущих инженеров на 19% при росте нагрузки на ревью на 6.5%, временный всплеск скорости с долговременным усложнением кода в 807 репозиториях, свыше 15% проблем с качеством на выборке из 300 000+ коммитов от ИИ и 33% принятых подсказок, качество которых никто не проверял на корректность.

Зачем эта страница в базе знаний

Это методологическая основа для всей ветки об измерениях. Страница понятий measuring-ai-coding-productivity собирает регулярные ошибки - закон Гудхарта, отсутствие контрольных групп, эффект новизны, смещение выборки, подмену системы индивидом - в одном месте. danluu-ai-coding-testing приводит тот же аргумент "покажите мне распределение" с позиции инженера-практика: усреднённые сводные цифры скрывают разброс от прогона к прогону, достаточный для подтверждения любого вывода. no-silver-bullet-llms приводит данные DORA и CircleCI о нестабильности, которые предсказывает ошибка №9. constraint-decay объясняет механику ошибки №2: агенты хорошо показывают себя на свободных задачах с нуля и деградируют по мере накопления производственных ограничений. reviewing-ai-code рассматривает ошибку №9 как ограничение пропускной способности, а dont-outsource-learning описывает долгосрочные издержки от атрофии навыков, которые ошибки №4 и №10 упорно не замечают.