В 2026 году разработчики все чаще отказываются работать без ИИ-инструментов, но новые данные показывают, что рост скорости не всегда означает рост качества кода. Исследователи и участники рынка предупреждают: выгода от генерации кода может сопровождаться ростом числа ошибок и затрат на поддержку.
В феврале 2026 года исследовательская лаборатория METR сообщила, что большинство разработчиков не готовы выполнять даже ограниченный набор задач без ИИ. Команда хотела повторить свое исследование 2025 года о влиянии ИИ на продуктивность в программировании, но провести эксперимент не удалось.
По словам исследователей, разработчики не захотели участвовать в тесте без ИИ. Как признали в METR, они отказывались, потому что «не хотят работать без ИИ» даже ради самого исследования.
В предыдущей работе METR сравнивала, сколько времени разработчики open source тратят на задачи вручную и с ИИ. Участники считали, что ИИ повышает их продуктивность, но результаты показали обратное: инструменты ускоряли написание кода, однако дополнительное время уходило на поиск и исправление ошибок, управление подсказками и ожидание ответа системы.
Вместо повторного эксперимента METR в мае опубликовала опрос, где технические сотрудники сами оценивали эффект от ИИ. Респонденты сообщили, что с ИИ они чувствуют себя в два раза полезнее для своих компаний, однако автор материала отмечает, что такие оценки могут быть слишком оптимистичными.
Сомнения усилились на фоне обсуждения так называемого tokenmaxxing — подхода, при котором число использованных токенов считают показателем продуктивности при работе с ИИ. В 2026 году этот показатель быстро стал популярным, но уже появились примеры, ставящие его под вопрос.
По данным Financial Times, Amazon закрыла внутренний рейтинг Kirorank, который отслеживал использование токенов. Сотрудники начали искусственно повышать показатели, слишком активно используя ИИ-агентов, что увеличивало расходы. Этот случай показал, что рост использования ИИ сам по себе не означает рост продуктивности.
Издание The Information также сообщило, что Uber израсходовала весь бюджет на ИИ на 2026 год за первые четыре месяца. Операционный директор компании Эндрю Макдональд позже заявил в подкасте, что такие траты не привели к заметному росту числа проектов или производительности.
Проблема касается и дальнейшей поддержки кода. Программист и автор Джеймс Шор в посте, который широко разошелся на Hacker News, написал: «Вы теперь пишете код в два раза быстрее? Лучше надеяться, что вы вдвое сократили расходы на его поддержку. Иначе у вас проблемы. Вы меняете временный прирост скорости на постоянную зависимость».
Есть и другие сигналы о росте затрат на сопровождение. Основатель и гендиректор Entelligence AI Айшварья Санкар заявила в вирусном посте, что компании тратят 44% токенов на исправление багов, появившихся из-за ИИ-сгенерированного кода. Компания Code Rabbit сообщила, что при анализе pull request в open source обнаружила: код, созданный ИИ, приносил в 1,7 раза больше проблем, чем код, написанный человеком.
При этом такие данные исходят от компаний, которые продают инструменты для проверки ИИ-кода, поэтому к ним нужен осторожный подход. Но схожие выводы сделали и независимые исследователи.
В апреле исследователи из Singapore Management University опубликовали отчет с предупреждением: «Код, созданный ИИ, может добавлять долгосрочные расходы на поддержку в реальных программных проектах».
На этом фоне участники рынка предлагают разные решения. Основатель и гендиректор Cognition Скотт Ву, чья компания выпускает ИИ-агента Devin, считает, что разработчики могут применять ИИ-агентов и для исправления кода. Но он сам признает, что Devin пока работает на уровне между junior и middle-разработчиком в зависимости от задачи, поэтому полностью передать ему работу и забыть о контроле нельзя.
Исследователи SMU предлагают другой подход. По их мнению, программисты должны хорошо понимать, с какими задачами ИИ справляется уверенно, а с какими — хуже. Командам нужны сильные системы контроля качества для кода, созданного с помощью ИИ, а результаты работы таких систем нужно проверять так же внимательно, как код младшего разработчика.
Авторы отчета также считают, что за людьми должны оставаться задачи верхнего уровня, включая архитектуру ПО и проектирование безопасности. С этим согласен и Скотт Ву.
Источник: METR, Financial Times, The Information, Hacker News, Singapore Management University.