Цена 10x продуктивности: как ИИ физически ломает сеньоров

Если вы сеньор, который в последний год ловил себя на том, что к 18:00 мозг физически пустой и вы не помните, что хотели сделать через секунду после того как встали из-за стола, — это не возраст и не выгорание от «обычного» объёма работы. Денис Стецков в блоге From the Trenches собрал исследования за последние 18 месяцев и показал, что происходит с сеньорами под ИИ-потоком: ИИ-ускоритель вдвое увеличил количество PR на проверку, но осознанное внимание человека по-прежнему работает на скорости ~10 бит/с. Разбираем, что именно в этой математике не сходится и почему сильнее всех достаётся как раз сеньорам.

Денис Стецков — инженерный лид, ведёт блог techtrenches.dev. Статья «The Human Cost of 10x: How AI Is Physically Breaking Senior Engineers» за пару дней набрала на Hacker News оживлённое обсуждение — сеньоры узнают себя в описании и добавляют своих деталей. Автор собирает под один тезис данные из UC Berkeley, Upwork, Neuron, GitHub Octoverse, Faros AI, METR, Qodo, GitClear и старой работы Bainbridge «Ironies of Automation» 1983 года. Получается не манифест против ИИ, а попытка честно посчитать арифметику.

Workload creep: ИИ не сокращает работу, он её интенсифицирует

Workload creep — это когда объём и границы работы ползут вверх без официального пересмотра планов и ожиданий. В феврале 2026 UC Berkeley опубликовали результаты восьмимесячного полевого исследования в 200-человечной tech-компании — 40+ глубинных интервью. Вывод, ради которого стоит прочитать оригинал: ИИ не уменьшает объём работы, он его интенсифицирует через три механизма.

• Task expansion: у каждого расширяется скоуп, потому что ИИ делает возможным «ещё вот это». Раньше вы делали три задачи — теперь формально можете пять, и вам их молча накидывают.
• Blurred boundaries: ИИ-промптинг просачивается в обед, дорогу домой, вечер — «ну это же не работа, я просто спросил у Claude». В итоге 14 часов думающего времени в сутки вместо 8.
• Implicit pressure: когда коллеги на глазах делают больше с ИИ, ожидания поднимаются для всех. Даже если ваши — не поднялись, то в голове они поднялись уже.

Upwork Research Institute (опрос апреля-мая 2024) квантифицировал: 77% сотрудников, использующих ИИ, говорят, что инструменты либо снизили их продуктивность, либо добавили нагрузку — минимум по одному из пунктов. 71% рапортуют выгорание. А теперь главная находка, ради которой стоит не закрывать вкладку: рабочие с самыми высокими показателями ИИ-продуктивности выгорают сильнее всех. 88% burnout rate у «самых продуктивных». Они в два раза чаще увольняются. Тот, кто лучше всех выглядит на вашем дашборде, — ближе всех к тому, чтобы уйти.

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

Мозг обрабатывает 10 бит в секунду. Это биология, а не характер

В декабре 2024 года Чжэн и Майстер опубликовали в Neuron работу с неприятным для индустрии выводом. Сенсорные системы собирают данные на скорости около миллиарда бит в секунду. А вот осознанная аналитическая мысль — та самая, которой вы делаете code review — работает на скорости примерно 10 бит в секунду. Рабочая память при этом удерживает около 4 чанков информации одновременно.

Поверх этого — классическое исследование SmartBear и Cisco (Best Kept Secrets of Peer Code Review): эффективность обнаружения дефектов резко падает, когда скорость ревью превышает ~500 строк в час, и качество заметно проседает после первого часа непрерывной работы. Это не про «собраться и потерпеть» — это про то, что после часа когнитивная точность мозга физически падает.

Теперь посмотрите, что ИИ сделал с очередью на ревью. GitHub Octoverse 2025 показывает 43,2 млн смердженных PR в месяц — рост 23% год к году. Faros AI проанализировала 10 000+ разработчиков и зафиксировала главное: с ИИ-помощью мерджат на 98% больше PR. PR review time +91%, размер PR +154%. И каждый из этих PR ложится на стол сеньору.

Джуниоры генерят гораздо больше кода с ИИ-инструментами, но сам объём насыщает пропускную способность сеньоров по ревью.

MITсводка по индустрии, 2025

В марте 2026 мейнтейнер OCaml отклонил 13 000-строчный ИИ-сгенерированный PR целиком — у команды не было пропускной способности его разбирать. И это уже не отдельные истории, это статистика. Ранее METR показала, что опытные разработчики с ИИ-инструментами на самом деле работают медленнее, хотя чувствуют себя быстрее. Зазор между ощущением и реальностью — самый опасный вывод из всей этой серии исследований: вы не можете починить то, чего не чувствуете.

Почему экспертность делает только хуже

В 1983 году Лизанн Бэйнбридж опубликовала в Automatica эссе «Ironies of Automation». Основной тезис: чем более сложной становится автоматизация, тем более требовательной становится остающаяся человеческая роль. После автоматизации в работе человека остаётся самое неоднозначное, самое сложное, хуже всего инструментируемое. Microsoft Research в 2024 подтвердила это для генеративного ИИ: ИИ-системы могут делать сложные задачи ещё сложнее, оставляя пользователю ту же или бо́льшую когнитивную нагрузку.

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

Clutch опросили 800 разработчиков: 59% используют ИИ-код, который не понимают полностью. Для джунов это ещё допустимо, для сеньоров — нет. Их работа — ловить то, что выглядит правильным, но не является. Отчёт Qodo даёт распределение по стажу: уверенность в ИИ-коде у сеньоров — всего 22%. Боль с контекстом: 41% у джунов против 52% у сеньоров. То, что все остальные сгружают в «когнитивный оффлоадинг», сеньор обязан не сгружать — это его работа. Он впитывает всю ту когнитивную цену, которую сняли с себя все остальные.

Тело записывает всё

Когнитивный ущерб — это половина истории. Вторую половину собирает тело. Computer Vision Syndrome — синдром компьютерного зрения (на tproger.ru про это есть отдельный разбор — про туннельный синдром, близорукость и выгорание у айтишников) — затрагивает 74% пользователей экранов в периоды увеличенной нагрузки, и тяжесть цифрового напряжения глаз сильно растёт вместе с ростом когнитивной нагрузки. ИИ-интенсифицированное ревью — это не просто «больше часов перед экраном»: каждый час становится физически более разрушительным, потому что вы не просто смотрите в монитор, а упираетесь в него со всей остротой внимания.

Метаанализ 2024 года на 26 916 участников: выгорание повышает риск сердечно-сосудистых заболеваний в среднем на 21%. Отдельное проспективное исследование Toker et al. 2012 (8838 участников, Psychosomatic Medicine) показало для верхнего квинтиля по выгоранию +79% к риску ишемической болезни сердца. Крупнейшее IT-исследование: метаболический синдром у 32% долго сидящих программистов — вдвое больше, чем в общей популяции.

Плюс сон. Пережёвывание рабочих задач после работы напрямую ломает качество сна. Когда вы закрываете ноутбук, мозг не выключается — он проигрывает PR, который вы не досмотрели, зависимость, которую флагнули, но не успели отследить. Больше ревью днём → хуже сон ночью → хуже решения утром → больше rubber-stamped PR → больше багов в проде → больше стресса. Цикл замыкается. Ломается — обычно человек.

Дашборд лжёт

GitClear (компания-вендор инструментов для анализа качества кода — к выводам стоит относиться с оглядкой на конфликт интересов) проанализировала 211 миллионов изменённых строк и показала неприятный тренд. Code churn за период массового внедрения ИИ-ассистентов вырос с ~3% до ~7–8%. Дублированный код в статистике вырос в несколько раз. Агрегированные цифры по росту багов и логических дефектов Стецков приводит со ссылкой на GitClear — но сам отчёт GitClear закрыт за формой лидогена, независимо верифицировать их нельзя.

Faros AI на тех же 10 000+ разработчиках: несмотря на +98% смердженных PR с ИИ, компании целиком не показали никакого измеримого улучшения ни по throughput, ни по качеству. То есть индивидуально PR больше, а на уровне компании — ничего не изменилось, кроме количества людей с burnout.

CEO компании Sonar (той самой, что делает SonarQube) писал про скрытую опасность точно: ИИ-модели всё лучше избегают очевидных багов и простых security-дыр, но структурные дефекты сейчас составляют больше 90% всех проблем. Вы засыпаете в ложном чувстве безопасности: простые проблемы решены, а сложные прячутся под чистым на вид кодом, который проходит все автоматические проверки. А люди, которые умеют их находить, закопаны под потоком, превышающим их когнитивную пропускную способность by design.

Что делать прямо сейчас, если узнали себя

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

1. Поставьте верхний лимит на количество PR в день — 3–5, в зависимости от их размера. И держите его жёстко. Лучше пусть PR полежит в очереди день, чем вы отревьюите его в режиме rubber stamp в 19:00 с пустой головой.
2. Явно разделите время на «генеративное» и «review-only». Мозг переключается между написанием и ревью дорого: каждый свитч стоит 15–25 минут на возврат в контекст. Лучше два полутора-часовых ревью-окна в день, чем пять размазанных между всем остальным.
3. Считайте часы перед экраном как физическую нагрузку, а не как «ничего же не делаю». Вам нужны паузы, прогулки, нормальный сон и понимание, что 9 часов плотного ревью — это как тренировка на стадионе для того, кто к ней не готовился.

Если вы технический руководитель — проверьте у себя пару уязвимых мест. Технические лиды сами выгорают на ревью так же, как сеньоры, плюс несут отдельный груз ответа за дашборды, которые не показывают выгорание команды. Второе: у вас есть политика на максимальный размер PR на ревью? Если нет — это вопрос времени до первого человека, которого придётся выписывать из строя.

Что с этим делать командам

Это перекликается с темой переосмысления code review как процесса обучения, а не только отлова багов. Главная развилка, которую автор формулирует в финале: ИИ увеличил спрос на сеньорскую инженерную экспертизу на 76–98%. Предложение сеньоров — не сдвинулось. Более того, индустрия массово увольняет сеньоров с 2022 года (сотни тысяч), и pipeline, производящий новых, ломается теми же инструментами, что создают спрос. Формула не сходится.

Если вы технический руководитель, из статьи вытекает несколько неудобных вопросов к себе. Сколько времени сеньоры из вашей команды физически тратят на ревью за ИИ — и это измеряется? Дашборд с количеством смердженных PR этого не видит, он видит только throughput. Есть ли у вас политика на максимальный размер PR на ревью и на максимальное количество в день? Без этого «просто больше code review» — это вопрос времени до первого выгоревшего сеньора с диагнозом. Как выглядит разгрузка? Если ответ «увеличим штат» — откуда возьмутся эти сеньоры при текущем рынке, и не те же ли это люди, которых вы только что уволили в прошлой оптимизации?

У ревью-инженера в 2026 году нет версии выбора, где он не отвечает за результат. Доверился ИИ-PR — твоё имя на коммите. Перепроверил всё руками — твой сон и твоё сердце. Индустрия должна это считать.

по тезису Дениса СтецковаFrom the Trenches — парафраз

Если вы сеньор и узнаёте себя — стоит прочитать оригинал целиком: там больше деталей по исследованиям и меньше выводов-обобщений, чем в этом разборе. Автор собирает ответы от читателей для follow-up статьи. Комментарии на HN тоже стоят того: половина треда — это другие сеньоры, рассказывающие свои версии той же истории.