Повысило ли ИИ-программирование эффективность? Не сводите три вида данных к одному выводу

Один разработчик говорит, что ИИ помог ему собрать прототип за десять минут; другой — что проверять правки ИИ дольше, чем писать с нуля. Оба утверждения могут быть верны одновременно. Создание прототипа, доработка зрелого проекта и долгосрочное сопровождение — разные виды работы. Если не указать задачу, критерии готовности и способ замера времени, разговор о «росте эффективности» легко превращается в спор о разных вещах.

Для технических руководителей полезнее другой вопрос: какую часть работы над нашими задачами ИИ сократил и куда он её сместил? В этой статье на примере нескольких открытых исследований METR мы объясняем, как читать на первый взгляд противоречивые выводы, и предлагаем метод оценки, который команды могут взять на вооружение. Данные актуальны на 2026 9 5; здесь нет внутренних экспериментов EveryInfra по эффективности и рейтингов каких-либо моделей.

Что именно измерялось в показателе «на 19% медленнее»

В исследовании, опубликованном в июле 2025 года, METR привлёк 16 разработчиков, хорошо знакомых каждый со своим проектом с открытым исходным кодом, для выполнения 246 реальных задач. Возможность пользоваться доступными тогда ИИ-инструментами определялась случайным распределением. В условиях исследования время выполнения задач с ИИ выросло на 19%. Исследование касается инструментов начала 2025 года и конкретных рабочих сценариев и не даёт единого результата для всей разработки в 2026 году.

Эта оговорка нужна не чтобы преуменьшить результаты, а чтобы сохранить их полезность. Мейнтейнер, хорошо знающий большой репозиторий, уже знает соглашения проекта, исторические компромиссы и места, где легко ошибиться. Даже если первая версия правок от модели выглядит разумно, её всё равно может понадобиться перепроверить с учётом этого контекста. С другой стороны, работа в незнакомом проекте, разовая обработка данных или быстрая проверка идей могут подчиняться другим ограничениям.

Поэтому объявлять на основании этого эксперимента, что «ИИ-программирование бесполезно», значит выходить за пределы данных; столь же необоснованно толковать его как «любой, кто умеет писать промпты, обязательно повысит эффективность работы». Полезнее воспринимать его как напоминание: субъективные ощущения и реальное время выполнения задач не обязательно совпадают.

В обсуждении на Hacker News того времени читатели также задавались вопросами о размере выборки, знакомстве участников с проектом и о том, как учитывать время последующих переделок. Эти комментарии помогают дополнить вопросы для оценки, но не могут считаться новыми экспериментальными результатами. В частности, яркое соотношение из личного опыта не стоит выдавать за статистическое правило для всех проектов.

Почему из материалов 2026 года нельзя просто извлечь новый процент

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

Это не значит, что «старый эксперимент опровергнут». Старый эксперимент по-прежнему описывает сценарий, который тогда изучался; новые материалы напоминают, что в новой среде меняются даже объекты исследования и способы измерения. Люди, активнее всех пользующиеся ИИ, могли не попасть в выборку, а задачи, лучше всего подходящие для ИИ, могли не быть предложены.

Для корпоративных пилотов это вполне практический вопрос. Если учитывать только пользователей, готовых показать результаты, легко упустить неудачные или брошенные задачи; если привлечь только сотрудников, не знакомых с ИИ, трудности периода обучения могут сойти за долгосрочный эффект. Оба варианта способны изменить вывод.

Мы рекомендуем сначала фиксировать, как задачи попадают в пилот, и только потом смотреть на средние результаты. Отмечайте, кто не участвовал, какие задачи исключены и по каким причинам. Собирать не относящиеся к делу персональные данные не нужно: журнал с разбивкой по типам задач объясняет больше, чем несколько успешных демо.

Работать быстро, делать много и приносить большую ценность — разные метрики

В опросе технических специалистов в мае 2026 года METR дополнительно разделил скорость и ценность. Опрос охватил 349 технических специалистов; медианный множитель ценности работы по самооценке респондентов составил от 1,4 до 2 в зависимости от формулировки вопроса, а медианный множитель скорости по самооценке — 3. Речь идёт о субъективных оценках в анкете, а не о росте продуктивности команд, подтверждённом рандомизированными экспериментами.

Почему эти метрики могут расходиться? Представьте команду, которая с помощью ИИ быстро создаёт несколько внутренних демо-страниц. Если эти страницы помогли подтвердить важное требование, ценность может быть высокой; если они не повлияли ни на одно решение, число файлов кода и страниц растёт, а бизнес-ценность может не прибавиться. Это гипотетический пример, а не выборка исследования из конкретной компании.

И наоборот: если благодаря ИИ инженер реже заглядывает в документацию и меньше переключается между инструментами, работать может стать удобнее, даже если итоговая дата сдачи проекта заметно не сдвинется. Улучшения в удобстве стоит фиксировать, но не стоит пересказывать их как экономию бюджета на персонал в той же пропорции.

Мы предпочитаем задавать три вопроса по отдельности: выполнена ли та же задача быстрее, сколько ручного труда понадобилось, чтобы достичь того же стандарта, и стоило ли вообще делать выполненную задачу. Если свести их в один «множитель роста эффективности», потеряется именно та информация, которая больше всего помогает команде менять способы работы.

Чтобы оценить работу команды, сначала определите, что значит «готово»

Перед внедрением новых инструментов зафиксируйте согласованный критерий готовности. Например, для задачи интеграции API можно требовать: основной сценарий работает, причины критических сбоев понятны, необходимые тесты проходят, а сотрудник, принимающий работу, понимает ограничения. Для конкретных проектов условия можно добавлять или убирать, но нельзя снижать требования, увидев результат ИИ, только чтобы итоги выглядели лучше.

Затем фиксируйте два вида времени по отдельности. Первый — календарное время от начала задачи до приёмки, включая ожидание; второй — фактические трудозатраты людей, включая разбор требований, подготовку контекста, ревью и переделки. Когда параллельно работают несколько агентов, минуты работы отдельных машин нельзя просто складывать в человеко-часы, а всё время ожидания нельзя считать сэкономленным.

Для начала пилота достаточно записи со следующими полями:

• Тип задачи, оценка сложности и знакомство участников с кодовой базой.
• Использованные инструменты и их версии, применялась ли помощь ИИ и кто отвечает за окончательную приёмку.
• Время создания первой версии, время достижения установленного критерия готовности и фактические трудозатраты людей.
• Проблемы, найденные на ревью, число итераций переделок и дефекты, обнаруженные позже.
• Бизнес-цель задачи; был ли результат в итоге принят, а если нет, то почему.
• Прерванные и неудачные задачи, а также задачи, от которых сознательно отказались, не должны пропадать из записей.

Этот список — наша рекомендация по оценке, а не воспроизведение экспериментов METR, и он не гарантирует значимых выводов на малых выборках. Его главная задача — показать, на каком этапе застревает работа: генерации, проверки или передачи.

Если сейчас основные трудности связаны с несовпадением интерфейсов, переход на более сильную модель может не решить проблему. Например, то, что SDK формирует запрос, ещё не значит, что сервис поддерживает те же параметры или способы ответа. Такие оценки совместимости разбираются в статье на нашем сайте о границах миграции между OpenAI SDK и Gemini; эти ограничения интеграции тоже стоит включить в критерии готовности пилотных задач.

Малые выборки должны помогать принимать решения, а не создавать цифры для рекламы

Проведя оценку в течение какого-то времени, разбейте результаты по типам задач. Если на малорисковых, хорошо структурированных задачах удалось сэкономить труд, а изменения, затрагивающие несколько модулей, потребовали больше ревью, следующим шагом может быть корректировка области применения ИИ, а не повсеместное расширение или прекращение его использования.

При разборе результатов проверьте также, не изменились ли сложность задач и требования к качеству. Если раньше задача требовала полной обработки ошибок, а теперь закрывается только основным сценарием, сравнивать их напрямую нельзя. Если раньше задача давала готовый к передаче план, а теперь порождает десять непринятых черновиков, рост объёма результатов нельзя оценивать только по количеству.

Стоимость инструментов можно учитывать как отдельное измерение, но рассматривать её стоит вместе с ревью, переделками после сбоев и затратами на сопровождение. Если надёжных записей нет, признайте, что пока посчитать это невозможно, и не выдавайте число вызовов API или сгенерированных строк кода за окупаемость инвестиций. Как сравнивать соответствие задаче, поведение при сбоях и стоимость вместе, читайте в руководстве по выбору API.

У METR есть и заметка о научной коммуникации, посвящённая тому, как представлять результаты исследований, которые легко понять неправильно. То же касается и корпоративного контента: чтобы читатель мог оценить применимость, сохранить неприглядные ограничения часто полезнее, чем выбрать самую эффектную цифру.

Единого ответа на вопрос «Повышает ли ИИ-программирование эффективность?» не появится только потому, что вышла очередная колонка. Но команда может сформулировать вопрос так, чтобы на него можно было ответить: при каких типах задач, версиях инструментов и критериях готовности сократился ручной труд, изменилось ли качество и были ли результаты действительно приняты? Полезнее сначала получить такие ответы с чёткими границами, а потом решать, расширять ли использование инструментов, чем спорить о множителе эффективности в отрыве от задач.