Почему не ложится GenAI у сотрудникам в компании?

Три кризиса, которые переживает инженер, когда ему выдают агентов

«Он генерит код за 5 минут, а я потом два часа его читаю и всё равно нахожу тысячу ошибок»

Это самое частое возражение, которое я слышу на коучингах по GenAI. И оно почти всегда звучит как претензия к инструменту: модель тупая, код грязный, проще самому.

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

Я довольно долго собирал фидбэк от разных команд и свёл его к трём системным ограничениям. Это не вредность и не технофобия. Это три профессиональных кризиса, которые раньше инженер проходил постепенно и по мере карьеры, а теперь они свалились на него все сразу - и на джуна, и на мидла, и на сеньора.

Кризис первый: делегирование

Люди не умеют делегировать. Вообще. Не агентам - живым людям не умеют.

Делегирование - это не «попросил сделать». Это четыре отдельных навыка:

1. Понять задачу самому и сформулировать её так, чтобы тебя поняли.
2. Подобрать ключик к исполнителю, чтобы он действительно её сделал.
3. Сделать ревью.
4. Если пошло не так - помочь исправить и передать знание, чтобы в следующий раз было лучше.

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

Раньше через это проходили единицы и с подготовкой. Сейчас мы сказали всем: вот вам агенты, делегируйте. И человек горит ровно так же, как сеньор, которому впервые дали семь подчинённых.

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

Кризис второй: мышление девопса

Посмотрите, как на проект приходит девопс. Он не думает: «наконец-то я нашёл задачу на полгода и спрятался от бенча». Он думает: «мне надо написать N скриптов и свалить, чтобы меня больше не трогали - у меня ещё три проекта в очереди». Его цель - чтобы всё работало без него. Он будет приглядывать, если попросят, но по дефолту он строит систему, а не делает работу руками.

Теперь ровно это сказали всем: ребята, вот вам скиллы, инструкции, агенты - автоматизируйте свою рутину.

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

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

Вопрос инженера старого образца: «как мне сделать эту работу хорошо?»
Вопрос инженера нового образца: «как мне эту работу не делать?»

Кризис третий: взгляд CEO

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

Суть дилеммы собственника: ты смотришь на всё. И любой косяк, который никому не адресован, ты выполняешь сам - потому что если его никто не сделает, конвейер встанет.

Исполнитель так не смотрит. У исполнителя есть свой квадратик, и ему фиолетово, что слева и справа.

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

Это дополнительная когнитивная нагрузка. По доброй воле на неё никто не подписывается.

Почему у менеджеров «взлетает», а у инженеров - нет

Наблюдение, которое многое объясняет.

Менеджер ставит себе Claude или Cursor, просит сделать отчёт - и получает отчёт. Ему всё равно, как оно внутри реализовано. Он подходит к модели как к исполнителю - ровно так же, как он всю жизнь подходил к любой команде. У него вдруг за десятки долларов в месяц появилась своя команда, и он переключается в режим продуктоунера: наконец-то он может не обслуживать чужой продукт, а сделать свой. И у него всё цветёт.

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

Приём, который работает: сформулируйте задачу так, чтобы её нельзя было сделать самому

Самое честное возражение звучит как «я сделаю лучше». Спорить с ним бесполезно - обычно это правда.

Поэтому не спорьте. Поменяйте постановку задачи.

Не «за спринт», а «сегодня до вечера мне нужно пять компонентов, которые делают вот это».

Всё. Сам он это не сделает. Ему придётся опереться на не очень качественного исполнителя - и дальше включится правильный вопрос: «ладно, модель стабильно даёт мне 40% от того, что сделал бы я, но за пять минут вместо трёх часов. Как мне поднять эти 40% до 60? до 80?»

Вот в этот момент человек начинает учиться делегировать, а не возражать.

И здесь же появляется главный размен, который надо проговаривать вслух:

Да, качество ниже. Но я беру скейлом. Десять агентов работают параллельно. Мы дойдём до конца спринта с прототипом на 40%, получим фидбэк, за второй спринт доведём. Сам я бы делал это пять спринтов - а задачу поставили на два.

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

Локус контроля: главный переключатель

Есть ещё одна вещь, без которой ничего не поедет.

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

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

Это и есть смена локуса контроля с внешнего («моделька виновата») на внутренний («что я сделал не так, если энциклопедист не справился»).

Аналогия из жизни лида. В команду пришёл человек - гениальный по хардам и невыносимый по софтам. Лид идёт к деливери-менеджеру: уберите его, команда деградирует. А деливери-менеджер говорит: не уберу, вот тебе тренинг по коммуникации, попробуй ещё раз. И лид думает: «блин, ладно» - и идёт договариваться.

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

Про страх, который редко произносят вслух

Под всеми тремя кризисами лежит ещё один слой: ощущение, что твой труд обесценивается. То, чему ты учился годами, теперь делает модель.

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

И честный ответ здесь не «не бойся», а разложенный кнут с пряником.

Кнут: если ещё два года работать в старом формате, количество проектов, которые будут тебя хотеть, станет сильно меньше. Нам на это повлиять нечем - это случится в любом случае.

Пряник: сегодня из каждого утюга вайб-кодит кто угодно. Но только человек, который отработал в индустрии пять-десять лет, понимает, что на самом деле лежит под капотом такой работы. Он может взять свои знания - архитектуру, SOLID, проектирование API, базы такие, базы сякие, многопоточность, ассинхронная разработка и так далее - и усилить их агентами. Это другая лига, и её пока мало кто занял.