Ловушка плато

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

Это все хорошо и правильно, но есть больше к этой истории, и оно быстро становится более очевидным. Реальный риск, с которым сталкиваются инженерные команды в настоящее время, не является выгоранием. Это плато.

Новая разница

Почти каждый старший инженер сейчас использует ИИ. Copilot, Claude, Cursor, Codex, назовите что угодно. Это уже решено. Если вы руководите инженерной организацией, вы, вероятно, видите широкое внедрение и чувствуете себя хорошо от этого.

Не должны.

Показатель внедрения бессмысленен. То, что имеет значение, – это разница, которая происходит под ним. Ваша команда тихо делится на две группы. Есть инженеры, которые получили прирост производительности и устроились, и инженеры, которые продолжают толкать каждую неделю. Новые рабочие процессы, новые конфигурации агентов, новые способы разложения проблем для обработки ИИ.

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

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

Как выглядит плато

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

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

Это не о том, чтобы быть энтузиастом ИИ или ранним采用щим. Фаза раннего внедрения закончилась. Это о непрерывной адаптации, а не одномоментной корректировке. И разница между этими двумя подходами становится невозможной для игнорирования.

Конкурентное давление реально и ускоряется

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

Но если вы посмотрите на более широкую ситуацию в软件-индустрии, скорее всего, у вас нет этого роскоши.

Сoftware-индустрия в целом была создана, чтобы помочь людям с цифровой работой: помогать агентам поддержки видеть входящие заявки, отслеживать ответы клиентов, управлять рабочими процессами. Теперь агенты ИИ вытесняют весь рабочий процесс и нарушают основные платформы SaaS. Кроме того, поскольку ИИ становится более способным с каждым днем, ваши клиенты начинают задавать вопрос: “Нам все еще нужно покупать это или мы можем построить это сами?” ИИ начал сокращать барьер между “купить” и “построить” для расширяющегося набора случаев использования. Липкость, которая ранее защищала вашу выручку, ослабевает каждый квартал.

Ваши инженеры, застрявшие на плато, работают с темпом, откалиброванным для конкурентной среды, которая больше не существует.

Цитата, которая переформулировала все для меня

Я слышал это более чем один раз, от менеджеров продукта, которые закатывали рукава и кодировали функции, от лидеров инженерных команд, которые переработали неудачные архитектуры, в разных компаниях, в разных контекстах:

“Было легче для меня итерировать это с моими агентами, чем с этим инженером.”

В первый раз, когда я услышал это, я подумал, что это гипербола. В третий раз я понял, что это ведущий индикатор.

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

• Они работают “на одной волне” со своими заинтересованными сторонами (менеджерами продукта, инженерными менеджерами и т. д.). Они понимают, что такое “хорошо”, поэтому вам не нужно им многое объяснять. Потому что если они производят столько же недоразумений, сколько ваш агент кодирования, агент всегда выиграет эту битву. Он доступен мгновенно, 24/7, и неустанен.
• Они постоянно улучшают свои настройки ИИ, поэтому когда вы передаете им что-то, вы знаете, что это будет сделано не только хорошо (см. пункт выше), но и достаточно быстро, чтобы соответствовать новому рыночному темпу.

Почему это проблема лидерства, а не индивидуальная

Это заманчиво представить это как ответственность отдельного инженера. “Держись или отстань.” Но если вы руководите инженерной организацией, такое представление освобождает вас от ответственности.

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

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

Это проблема управления изменениями, и одна из моих любимых рамок для этого来自 книги Хит-братьев Switch. Короткая версия: вам нужно дать людям четкое направление, сделать их чувствовать, почему это важно, и изменить окружение так, чтобы новое поведение было путем наименьшего сопротивления. Применительно к инженерным командам это выглядит так:

Найдите свои яркие пятна и сделайте их видимыми. Определите инженеров, которые продвинулись дальше всего в своих рабочих процессах ИИ, и пусть они демонстрируют команде регулярно. Не тренировочные сессии. Живые демонстрации реальной работы. Когда середина вашей команды видит разницу между своим рабочим процессом и рабочим процессом лучшего адаптера, это создает продуктивное неудобство, которое никакой мандат не может сравниться.

• Уменьшите изменение. “Принять ИИ” слишком абстрактно, чтобы действовать. В этом спринте мы закрепляем агентное тестирование от начала до конца, в следующем спринте мы развертываем его во всей организации, и так далее. Конкретные управляемые шаги побеждают амбициозные программы трансформации каждый раз, и небольшие победы имеют значение.
• Измените значения по умолчанию. Закодируйте процесс верификации в навыках ИИ и убедитесь, что они развернуты по всей команде и по всем их агентам. Определите свои рабочие процессы и используйте инструменты, которые поддерживают это. Сделайте новый способ работы путем наименьшего сопротивления, чтобы люди скользили к нему, не имея необходимости бороться.

Окно закрывается

Вот часть, которая делает это срочным, а не просто важным.

Сейчас разница в адаптации является производственной разницей. Ваши инженеры, застрявшие на плато, медленнее, чем ваши адаптированные, но они все еще производительны. Они все еще вносят вклад. Вы можете их нести.

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

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

Каждый инженерный лидер, с которым я говорю, понимает это интеллектуально. Очень немногие изменили, как они управляют своими командами в ответ. Разрыв между пониманием и действием – это своего рода плато.

Нет комфортного темпа

В статье об усталости от ИИ я утверждал, что боль – это доказательство того, что тренировка работает. Это все еще правда. Но следующая правда труднее: вес продолжает расти.

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

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