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

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

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

Новый раскол

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

Вы не должны.

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

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

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

Что такое плато на самом деле

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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