Мы думали, что с ИИ мы будем меньше работать

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

Но чаще всего мне писали про другое. Один ответил коротко:

из проблем - сильно вырос объем ревью (от моего агента и от чужих)

Другой:

сейчас с помощью нейронок я намного больше прогоняю за день через свой мозг информации

И дописал, что на свой проект к вечеру сил уже нет.

Мы думали, что с приходом ИИ будем меньше работать. Оказалось, что работаем больше, чем когда-либо. И самое неприятное: нас никто не заставлял.

Отсюда вопрос: это временная яма, которую надо просто пережить, или новая норма?

Нас никто не заставлял

В Berkeley Haas восемь месяцев наблюдали за американской технологической компанией примерно на 200 человек (HBR). С генеративным ИИ люди работают быстрее, берут задачи шире и позже заканчивают, причём никто их об этом не просит. Промпты отправляют в обед, на созвонах и пока грузится файл. При этом всё больше времени тратят на ревью того, что навайбкодили коллеги. Ранний рост продуктивности со временем сменяется падением качества и текучкой.

То есть сэкономленное время мы сами же и съели. Взяли ещё задач, запустили ещё агента, ответили ещё на один PR.

А PR-ов стало сильно больше. По телеметрии Faros с 22 000 разработчиков (отчёт) в командах с высоким внедрением ИИ медианное время ревью выросло на 441%. И PR без всякого ревью стали мёржить на 31% чаще: люди просто перестают успевать.

BCG добавляет важную деталь (HBR, “AI brain fry”): когда ИИ забирает рутину, выгорание снижается. Когда работа превращается в постоянный надзор за ИИ, растёт усталость от решений и желание уволиться. Выматывает не сам ИИ, а роль надсмотрщика.

Работы в кодинге стало меньше, но её стало больше в постановке задач, проверке и принятии решений. Это другой навык, и большинство разрабов ему никогда специально не учились.

Сначала станет хуже

Самое цитируемое исследование про “ИИ замедляет разработчиков” - METR, июль 2025. 16 опытных open-source разработчиков решали задачи в своих же репозиториях, и с ИИ это заняло на 19% больше времени. До эксперимента они ждали ускорения на 24%, после всё равно считали, что ИИ ускорил их на 20%. Cursor участники использовали всего несколько десятков часов, и авторы прямо пишут, что эффект обучения после 50+ часов исключить нельзя.

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

Что я из этого вынес. Без навыка и подготовленного проекта ИИ правда может замедлять. Ощущения врут. И у навыка есть кривая обучения: пока вы учитесь ставить задачи, проверять результат и настраивать окружение, вы работаете медленнее, чем руками.

Кто бросил в яме этой крвиой, делает вывод “ИИ не работает”. Кто прошёл - “без этого уже не могу”.

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

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

Главная сложность не техническая

Большинство разработчиков не привыкли делегировать. Привычный режим - “сам разберусь по ходу”: требования размыты, ожидания не проговорены, результат как получится. С коллегой в команде это иногда работает, с агентом нет. Агенту нужно объяснить, что сделать, что вернуть и как проверить.

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

Stack Overflow 2026 хорошо показывает границу: доверять ИИ в важных решениях готовы 6% разработчиков. Но почти половина доверяет, когда может проверить результат.

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

Нормальная позиция, по моему, как у тимлида: контролировать “ствол и ветки” - архитектуру, биллинг, data model, критичные тесты - и отпустить каждый лист.

Порядок важнее инструментов

В опросе в моём тг-канале выбрать инструмент оказалось главной проблемой только у 2 человек из 32, а систематизировать знания - у 19. Людям нужен порядок.

Коротко порядок, к которому я пришёл:

Инженерная база. Без неё вы не отличите работающее изменение от правдоподобного.

Постановка задачи с критериями приёмки до кода.

Feedback loop: типы, линтер, тесты, браузер, логи - всё, чем агент проверит себя сам. Это поворотная точка. Пока его нет, feedback loop - это вы: копируете ошибки в чат и читаете каждый дифф.

Расширения - skills, MCP, плагины - только после этого. Они ускоряют того, кто уже умеет проверять результат.

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

Пропущенный этап никуда не девается, проблема просто всплывает позже и обходится дороже. Самый частый прыжок, который я вижу - сразу в SDD, оркестраторы, worktrees и пять параллельных агентов, минуя постановку и feedback loop.

Важно и то, как вы учитесь. В эксперименте Anthropic junior-разработчики, осваивавшие новую библиотеку с ИИ, набрали на тесте 50% против 67% без ИИ. Но те, кто задавал агенту концептуальные вопросы и сам разбирался с ошибками, набрали 65%+. Спрашивайте агента “почему так”, а “сделай” оставьте на потом.

Что выкинуть и что оставить

Многие процессы вокруг агентов - SDD-фреймворки, ролевые “комбайны”, подробные спеки на каждую задачу - придуманы командами, у которых уже был опыт. Новичок берёт их целиком и получает бюрократию: спеки в 3–5 раз больше кода, которые никто не читает, сожжёные лимиты и ощущение чёрного ящика. А skills и MCP, поставленные не глядя, это ещё и supply chain: в феврале 2026 Koi Security нашли 341 вредоносный skill из 2 857 в маркетплейсе ClawHub.

Зато есть практики, которые как раз сейчас стали нужнее всего: критерии приёмки, тесты, маленькие PR, нормальное ревью. Раньше их можно было срезать, потому что код писали вы и держали его в голове.

Так это пройдёт?

Яма пройдёт. Объём - нет. Агенты будут писать всё больше кода, и проверять его кто-то должен. Я думаю, это новая норма.

Но выматывает в ней не объём, а то, что проверяете вы руками и без остановки. Это как раз можно поменять: отдать проверки инструментам и второму агенту с чистым контекстом, себе оставить только критичное, не промптить в обед и не держать открытыми больше агентов, чем успеваете проверить.

Теперь код пишете не вы, и проверка - единственное, что у вас остается.

Об этом мой доклад “Как вкатиться в разработку с ИИ и не выгореть” на онлайн конфе AI Dev Live, 12 ноября в 14:00 по Москве. Конфу мы организуем небольшой тусовочкой AI блогеров-технарей, она идёт 11-12 ноября. По теме этой статьи там ещё будут:

Алекс Волочнев, DevRel, CodeRabbit - AI-ревью здорового человека

Александр Поломодов, ex-CTO Т-банк - AI ускорил разработку: как понять, что это правда

Егор Толстой, Podlodka - кому нужен Spec-Driven Development в brownfield-проектах

Павел Комаровский, RationalAnswer – AI нас всех убьёт? Давайте разбираться

Кирилл Мокевнин, Hexlet – Внедряем AI в легаси-проект: пошаговый план

Николай Шейко, AI Grably - Агентный сетап на осень 2026: без субагентов, MCP, памяти и CLI

Программа и регистрация - ai-dev.live.