Generative AI in software development: not a replacement for junior developers, but a new source of burnout

Исследователи из НИИ ИИ два года наблюдают, как разработчики синхронизируются с генеративными моделями — и называют происходящее не ростом производительности, а новым типом производственного выгорания.

Как выглядит работа с ИИ изнутри Паттерн один и тот же во всех командах.

Просишь поправить одну строку — получаешь полностью переписанный файл. Просишь объяснить ошибку — получаешь уверенный ответ, который при проверке оказывается неверным. Просишь подтвердить подход — получаешь альтернативный вариант, поданный как единственно правильный. За два года наблюдений сложился устойчивый портрет ИИ-ассистента в команде: Выдаёт устаревший или нерелевантный код за актуальный Оспаривает решения техлида, не имея полного контекста проекта Не признаёт ошибку, пока не переформулируешь запрос несколько раз Требует постоянного ревью каждого выданного результата * Переписывает рабочий код «в лучшую сторону», ломая существующую логику При этом уволить его нельзя — потому что «за ним будущее отрасли», а значит, команда обязана настраивать синхронизацию и ждать, когда он наконец вырастет.

Почему это выгорание, а не ускорение

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

«Как будто во всех проектах появился ещё один разработчик, который постоянно косячит, нуждается в постоянном ревью и при этом не может быть уволен», — пишут исследователи в обзоре.

Проблема ещё и в том, что этот тип усталости почти невидим снаружи. Метрики показывают больше кода за меньшее время. Ревью-очереди и количество откатов показывают другое.

Синхронизация как новая квалификация

Умение работать с ИИ де-факто становится обязательным профессиональным навыком — даже если конкретный инструмент замедляет конкретного разработчика. Команды без AI-ассистентов воспринимаются как отстающие. Команды, которые ими пользуются, несут новый вид накладных расходов, который нигде системно не считается.

Исследователи фиксируют: выработка рабочего подхода к модели — персонального и командного — занимает месяцы. Этот процесс требует реального времени и энергии, но в метриках эффективности не отражается никак. В отчётах нет строки «время, потраченное на то, чтобы объяснить ИИ контекст проекта в пятый раз».

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

Что это значит ИИ-ассистенты изменили не скорость разработки, а её структуру.

Новая когнитивная нагрузка реальна и пока системно не измеряется. Командам, которые хотят честно оценить ROI от AI-инструментов, стоит смотреть не только на скорость написания кода, но и на объём ревью, количество откатов и общий уровень нагрузки на каждого разработчика.