Около 5% инженеров в компании первыми лезут в AI-агенты для кода, пока остальные 95% ждут понятный и безопасный сценарий работы. Из этого, по данным Stack Overflow Blog, следует неприятный для CTO и тимлидов вывод: миф о том, что один 100x инженер вытянет внедрение ИИ за всех, скорее мешает команде, чем ускоряет ее.
Поводом стала колонка от 5 августа, в которой разобрали тезисы Вивека Рагхунатана, старшего вице-президента по разработке Snowflake, из недавнего выпуска Leaders of Code. Он предложил смотреть на AI в инженерных командах через рамку из обучения с подкреплением: есть explorers, то есть люди, которые сами бегут проверять пределы инструмента, и exploiters, которым нужен уже уложенный асфальт. Пропорция, по его грубой оценке, показательная: около 5% против 95%. Важная оговорка тоже на месте: вторые не слабее и не ленивее, они просто оптимизируют время под текущую работу, а не под исследовательский азарт.
Почему культ звезд не работает
Проблема начинается, когда руководство делает из этой схемы кастинг супергероев. В компаниях быстро замечают одного-двух людей, которые после появления кодовых агентов начинают закрывать задачи на совсем другой скорости, и дальше включается привычный сценарий: понять, чем они особенные, а потом масштабировать этот набор качеств на весь отдел. Автор спорит именно с этой логикой. По мысли Рагхунатана, ИИ усиливает не прежний статус инженера, а любопытство, гибкость и готовность учиться. Поэтому ставка на самых заметных senior-ов или сотрудников с уже громкой репутацией легко бьет мимо цели: те, кто покажут резкий рост с AI-инструментами, не всегда были главными звездами до их появления.
Отсюда критика двух популярных стратегий. Первая: выдать всем готовый процесс, шаблоны промптов и список разрешенных инструментов, а затем объявить, что внедрение ИИ состоялось. Пол на такой схеме правда поднимается: меньше хаоса, меньше страха, чуть быстрее рутинные задачи. Но потолок остается низким, потому что никто не ищет новый максимум именно для этой команды. Вторая стратегия симметрично плоха: построить всю историю вокруг нескольких ярких кейсов, где условный 100x инженер уже творит чудеса, пока остальные 95% просто делают ту же работу немного быстрее. Для красивой внутренней презентации этого достаточно. Для реальной производительности отдела, как следует из текста, этого мало.
Не лучше выглядит и попытка решить вопрос наймом. Рагхунатан прямо предупреждает: купить готовых исследователей с рынка вряд ли выйдет, потому что извне таких людей распознать не легче, чем внутри своей компании. Причина та же: речь не о дипломе, грейде или бренде в резюме, а о том, кто именно в новой среде первым начинает экспериментировать без приглашения. Если переводить это на язык управления, проблема не в дефиците редкого типа кандидатов, а в слабом механизме движения людей по шкале от осторожного пользователя к уверенному практику. Иначе AI в разработке остается зависимым от удачи, а не от системы.
Что это значит для команд
Практическая часть у этой идеи вполне земная. Исследователей не нужно вычислять тестами: они сами приходят с демо, спорят, показывают собранное за выходные и довольно быстро становятся заметны любому менеджеру. Вопрос в том, что делать после первого эффекта вау. В заметке предлагают вытаскивать из таких находок воспроизводимую практику: выделять структурированное время на обучение, собирать внутреннее сообщество вокруг AI-инструментов, запускать менторство и измерять не количество легенд в отделе, а то, сколько людей за квартал реально сдвинулись на одну ступень вперед. Это скучнее, чем истории про гениев, но именно так растет средняя скорость команды.
Для русскоязычной IT-аудитории вывод довольно приземленный. Во многих командах AI в разработке пока сводят либо к схеме «дайте лучшему бэкендеру корпоративный доступ, и пусть научит остальных», либо к обратной крайности: купим инструмент на весь отдел и разошлем инструкцию. Источник объясняет, почему обе модели неполные. Нужны и люди, которым можно без лишней бюрократии искать новые приемы, и нормальная дорожка для большинства, которое хочет просто быстрее делать свою работу без вечернего ресерча. Для CTO это аргумент против культа героев. Для продактов это напоминание, что скорость команды нельзя мерить по одному блестящему кейсу. Для HR это повод осторожнее относиться к самой логике найма под ярлык «100x инженер»: полезнее может оказаться не редкий профиль с рынка, а среда, в которой следующий такой человек проявится уже внутри компании.
На ближайшие кварталы вопрос звучит так: компании хотят найти очередного сверхрезультативного разработчика или научиться быстро превращать его приемы в общий стандарт? Пока рынок спорит, существует ли 100x инженер как устойчивый типаж, более полезным тестом зрелости выглядит другой: насколько быстро команда переводит чужой эксперимент из разряда «вау» в повседневную норму.