Если коротко: когда опытный программист берёт в помощники ИИ, он почти наверняка чувствует, что работает быстрее, — а по секундомеру делает ту же задачу примерно на пятую часть дольше. Это не байка из интернета, а результат контролируемого эксперимента: инженеры, которые годами ведут свои проекты, с ИИ-ассистентом потратили на задачи на 19% больше времени, чем без него. И, что самое неприятное, сами они этого не заметили.
Это канал «Всё про ИИ и роботов», и сегодня разберём не очередной рейтинг моделей, а механизм одной очень живучей иллюзии. Почему помощник, который реально пишет куски кода за тебя, в итоге крадёт время — и почему мозг при этом бодро рапортует об ускорении. Когда понимаешь механизм, из него сами собой следуют выводы: где ИИ в разработке правда помогает, а где только красиво имитирует помощь.
Что именно измерили — и почему к этому стоит прислушаться
Эксперимент провела исследовательская организация METR. Схема честная, как в медицине, — рандомизированное контролируемое испытание. Взяли 16 опытных разработчиков открытого кода: не студентов, а людей со стажем около пяти лет и примерно 1500 коммитами в своих же проектах. Дали 246 реальных задач из их собственных репозиториев — больших и зрелых (в среднем старше 10 лет, миллион с лишним строк кода, десятки тысяч звёзд на GitHub). Каждую задачу монетка случайно относила в одну из двух корзин: «можно пользоваться ИИ» или «нельзя». Полные условия и результаты METR выложила открыто, а методику подробно расписала в научной работе.
Инструменты были не самые слабые для начала 2025 года: Cursor Pro с моделями Claude 3.5 и 3.7 Sonnet. Эксперимент шёл с февраля по июнь 2025-го. То есть это не какая-то урезанная версия чат-бота, а ровно те инструменты, которыми тогда хвалились все. Именно поэтому результат и прозвучал так громко.
И ещё одна причина отнестись к этим цифрам серьёзно. Почти всё, что мы слышим о пользе ИИ, — это либо демо от производителя на специально подобранной задаче, либо опросы в духе «чувствуете ли вы себя продуктивнее» (а чувствуют почти все — мы уже видели почему). Здесь же замеряли не ощущение и не рекламный сценарий, а реальное время на реальных задачах, которые разработчик всё равно собирался делать. Такой дизайн трудно обмануть, и тем ценнее, что результат разошёлся с ожиданиями даже у самих авторов.
Парадокс: на 19% дольше — и всё равно «быстрее»
Перед началом инженеров спросили, как ИИ повлияет на их скорость. Ответ был дружным: ждём ускорения примерно на 24%. Логично — помощник же пишет код сам. Когда задачи сделали и время посчитали, картина перевернулась: с ИИ те же люди работали на 19% дольше. Не на проценты быстрее — на пятую часть медленнее.
Дальше начинается самое интересное. Уже после эксперимента, зная все цифры, участники оценили свой результат — и снова сказали, что ИИ их ускорил, примерно на 20%. Между тем, что происходило на самом деле, и тем, что люди чувствовали, образовалась пропасть почти в сорок процентных пунктов. Люди не врали — они честно рассказывали о своём ощущении. Проблема в том, что ощущение разошлось с часами.
Инженеры закончили задачи, своими глазами увидели потраченные часы — и всё равно были уверены, что ИИ их ускорил. Ощущение скорости и реальная скорость оказались разными величинами.

Куда на самом деле утекает время
Чтобы понять, куда девается выигрыш, исследователи вручную разметили сотни часов записей экрана. И увидели, как меняется сам характер работы. Без ИИ инженер почти всё время пишет и правит код — руки на клавиатуре, голова в задаче. С ИИ работа дробится: сформулировать запрос, подождать ответ, прочитать то, что сгенерировалось, понять, подходит ли оно, выбросить лишнее, дописать своё. Доля «чистого кодинга» падает, а на её место приходят промпт, ожидание и ревью.
Ключевая деталь механизма — качество вывода. Разработчики принимали меньше 44% того, что им предлагал ИИ. Больше половины сгенерированного кода отправлялось в корзину. Но чтобы отправить его в корзину, этот код сначала нужно прочитать и понять — а это тоже работа, причём не самая быстрая. Получается ловушка: ты не пишешь решение с нуля, но платишь временем за разбор чужих черновиков, половина из которых не годится. На задаче, которую ты и сам сделал бы за час, такой обмен невыгоден.
Здесь прячется неочевидная асимметрия. Прочитать и по-настоящему понять чужой код почти всегда дольше, чем написать свой: когда пишешь сам, решение рождается у тебя в голове по ходу дела, а когда проверяешь — приходится реконструировать чужой ход мысли, да ещё и держать в уме подозрение, что где-то спрятана ошибка. Добавьте переключения внимания: написал промпт — отвлёкся — вернулся к ответу — снова нырнул в задачу. Каждое такое переключение стоит нескольких минут на «вспомнить, где я остановился». По отдельности мелочь, в сумме за день — заметный кусок времени.
Пять причин, по которым выигрыш съедается
METR не ограничилась одной цифрой и разобрала, какие факторы складываются в это замедление. Пять из них выглядят особенно убедительно:
1. Переоценка пользы. Инженеры тянулись к ИИ даже там, где он явно мешал, — просто потому что верили в него.
2. Свой, знакомый код. Там, где ты сам эксперт и держишь проект в голове, подсказка со стороны почти не добавляет ценности: ты и так знаешь, что писать.
3. Большой и зрелый репозиторий. В проекте возрастом десять лет и на миллион строк модель вязнет — контекста слишком много, и она чаще промахивается.
4. Низкая точность вывода. Те самые меньше 44% принятого кода: остальное нужно вычитать и отбраковать.
5. Невидимый контекст. Негласные договорённости команды, стиль, подводные камни проекта живут в голове разработчика, а не в файлах — и модель о них не знает.
Важно удержать одну мысль: это механизм для конкретной ситуации — эксперт на своём большом проекте. Поменяйте условия, и знак может смениться. Новичку на незнакомом языке тот же ИИ, скорее всего, реально сэкономит часы. Об этом — чуть ниже.

А где же обещанное ускорение?
Было бы нечестно сделать из одного исследования вывод «ИИ в коде бесполезен». Эксперимент специально взял самый невыгодный для ИИ случай — эксперта на его собственном зрелом проекте. Разверните каждый из пяти факторов наоборот, и получите портрет ситуации, где помощник реально выручает.
Там, где вы не эксперт, подсказка экономит не минуты, а часы: незнакомый язык или фреймворк, разовый скрипт, каркас нового сервиса с нуля, тесты, которые лень писать руками, перевод кода с одного стека на другой, разбор чужой библиотеки. Чем меньше у вас в голове готового решения и невидимого контекста, тем больше ИИ добавляет сверху, а не дублирует то, что вы и так знаете. Проще говоря: ИИ поднимает пол (что-то рабочее теперь соберёт почти каждый), но не поднимает потолок (эксперту на знакомой территории прибавить нечего). Подробнее этот эффект мы разбирали в материале про вайб-кодинг.
Почему мозг так легко обмануть насчёт скорости
Самое загадочное здесь — не 19%, а устойчивое ощущение ускорения вопреки фактам. Разгадка в том, что мозг измеряет не время, а усилие. Писать код с нуля — это напряжение: держать в голове структуру, вспоминать синтаксис, принимать десятки мелких решений. Читать готовый вариант и нажимать «принять» субъективно легче. А лёгкость мы принимаем за скорость. ИИ действительно снижает когнитивную нагрузку в моменте — и этот комфорт мозг честно переводит в «я справился быстрее», хотя на часах всё наоборот.
Добавьте сюда то, что психологи называют смещением в сторону ожидаемого: если ты заранее уверен, что инструмент ускоряет, ты будешь трактовать смутные ощущения в его пользу. Плюс ожидание ответа модели воспринимается как пауза, а не как работа, — а из суммы этих «маленьких пауз» набегают вполне реальные минуты. Ровно так же человек недооценивает время, проведённое в ленте соцсети: отдельный свайп ничего не весит, а час куда-то исчезает.
Что изменилось к 2026 году
Честный разбор требует оговорки: тот эксперимент относится к инструментам начала 2025 года, а они быстро меняются. В феврале 2026-го METR опубликовала продолжение — уже про инструменты конца 2025-го, — и выводы стали осторожнее. У вернувшихся из первого исследования разработчиков оценка по-прежнему ушла в минус (около −18%), у новых участников оказалась близка к нулю (около −4%), но доверительные интервалы теперь захватывают и честное ускорение. Коротко: твёрдого «ИИ замедляет» уже нет, но и уверенного «ускоряет» данные всё ещё не дают.
А вот что оказалось едва ли не важнее самих цифр: набрать людей на повторный эксперимент стало тяжело. Разработчики, привыкшие к ИИ, попросту отказывались работать в группе без него. Это сильный сигнал — но не о скорости, а о привычке. Комфорт и привычка не равны измеренной продуктивности, и именно их легче всего спутать.
Как получить пользу, а не иллюзию
Из механизма выводы следуют сами, без списка «десять лайфхаков».
- Смотрите на часы, а не на ощущения. Раз в пару недель сравните, сколько времени реально уходит на типовую задачу с ИИ и без. Ощущению доверять нельзя: оно системно врёт в плюс.
- Включайте ИИ там, где вы не эксперт. Незнакомый язык, разовый скрипт, шаблонный каркас, тесты, документация — здесь помощник экономит время. На своём ядре, которое вы знаете наизусть, он чаще мешает.
- Не превращайте ревью в основную работу. Если вы принимаете меньше половины подсказок и подолгу вычитываете остальное — на этой задаче ИИ вам не подходит, проще написать самому.
- Большой зрелый проект — зона повышенного риска. Чем больше невидимого контекста в голове команды, тем вероятнее, что модель уведёт не туда.
Коротко
- Опытные инженеры на своих больших проектах с ИИ работали на 19% дольше — и не заметили этого.
- До эксперимента ждали ускорения на 24%, после — были уверены, что ускорились на 20%. Разрыв с реальностью — около сорока пунктов.
- Причина не в «плохом ИИ», а в обмене: меньше письма, но больше промптов, ожидания и ревью; принимается меньше 44% сгенерированного.
- Мозг измеряет усилие, а не время, поэтому комфорт принимает за скорость.
- К 2026 году картина смягчилась, но уверенного ускорения данные всё ещё не показывают. Проверяйте пользу на своих задачах, а не на чужих обещаниях.


Пока нет комментариев