Intuit развернула Claude Code на всю организацию, а продуктовые менеджеры в компании уже сами доводят pull request до merge. Для рынка это куда важнее очередного спора о том, «заменит ли ИИ программистов»: инженерное лидерство сдвигается от производства строк кода к системному мышлению, проверке гипотез и управлению риском. Для русскоязычной IT-аудитории сигнал прямой: ценность команды все меньше определяется скоростью набора кода и все больше тем, кто умеет превращать ИИ-ускорение в рабочий продукт.
Об этом в выпуске подкаста Leaders of Code рассказал директор по инженерии Intuit Эрик Андерсон, сообщает Stack Overflow Blog. В беседе с директором по инженерии Stack Overflow Беном Мэттьюсом он сформулировал тезис, который еще пару лет назад звучал бы как провокация: предельная стоимость новой строки кода никогда не была такой низкой. Если раньше именно разработка часто была главным узким местом в сроках, рисках релиза и отката, то теперь компаниям приходится заново определять, что вообще считать «построить фичу», где проходит граница между дизайном, инженерией и продуктом и за что именно отвечают сильные инженеры.
Важная деталь: в Intuit не сводят оценку эффективности к тому, сколько кода сгенерировал ИИ. Андерсон прямо говорит, что классические инженерные метрики вроде числа PR, code review и строк кода никуда не делись, но перестали быть главным ответом на вопрос о результате. Главная метрика осталась прежней: создало ли это ценность для клиента. На практике это меняет управленческий фокус. Если код стал дешевле, то дороже становятся хорошие продуктовые вопросы, корректная инструментализация, качественный дизайн эксперимента и умение быстро понять, какая версия решения реально работает лучше. По сути, инженерное лидерство теперь упирается не в добычу пропускной способности команды любой ценой, а в то, чтобы эта пропускная способность не ушла в бессмысленный шум.
Отсюда и второй тезис Андерсона: AI-first-команды получают не просто ускорение, а почти нелепо выросшую опциональность. Если раньше команда выбирала один вариант пользовательского сценария, потому что на большее не хватало времени, то теперь можно проверять несколько вариантов сразу. В разговоре он перечисляет эту логику почти нарочито: не два эксперимента, а пять, девять, хоть сотни, если есть смысл и измеримость. Для крупного бизнеса это означает простой, но неприятный вывод: дефицитом становится уже не код, а качественные дизайн-решения, постановка задач, понимание пользователей и способность быстро закрывать цикл «гипотеза - реализация - проверка». И это довольно трезвый ответ тем, кто до сих пор меряет прогресс компании количеством «сгенерированных миллионов строк».
На этом фоне особенно показателен пример со сближением ролей. По словам Андерсона, в Intuit PM уже могут сами мержить собственные PR. Речь не о том, что продуктовые менеджеры внезапно превратились в полноценных backend-разработчиков, а о размывании прежней перегородки между «придумал» и «сделал». Если ИИ берет на себя значительную часть механической реализации, у человека с сильным продуктовым контекстом появляется прямой путь к изменению системы. Для одних компаний это ускорение, для других - новый источник хаоса, если нет дисциплины вокруг архитектуры, ревью и ответственности за последствия. И вот здесь инженерное лидерство снова становится центральной функцией: кто-то должен выстраивать правила, по которым быстрые изменения не разнесут платформу, процессы и поддержку.
Разговор затрагивает и менее приятную тему - рост младших специалистов. Андерсон признает, что развивать junior-таланты стало сложнее. Это звучит логично и для российских команд, которые уже живут с кодогенераторами в редакторе, чат-ассистентами в IDE и все чаще получают от новичков не «я написал», а «мне сгенерировало». Когда рутинный код делает машина, исчезает часть привычной учебной лестницы, на которой джун нарабатывал мышечную память: дебаг, разбор чужих решений, локальные рефакторы, маленькие доработки через боль и повторение. В итоге бизнес выигрывает в краткосрочной скорости, но рискует получить провал в инженерном резерве через несколько лет. Для тимлидов это уже не абстрактная HR-проблема, а вопрос проектирования среды обучения: какие задачи оставлять человеку, как проверять реальное понимание, как учить не только промптингу, но и системному разбору последствий.
Показательно, что сам Андерсон использует ИИ далеко не только для кода. Он рассказал, что применяет такие инструменты для разбора входящей почты, синтеза спецификаций и даже в процессах, связанных с повышением сотрудников. Но есть и ограничитель: он перестал давать ИИ право отправлять письма от его имени. Деталь мелкая, но очень внятная. На уровне менеджмента это и есть новая норма работы с AI: использовать модель как ускоритель анализа, подготовки и структурирования, но не отдавать ей безусловный контроль над коммуникацией и решениями, где важны контекст, интонация и персональная ответственность. Если перевести на язык корпоративной практики, то руководитель будущего - это не человек, который «умеет пользоваться ИИ», а человек, который понимает, где делегирование машине окупается, а где начинает разрушать доверие.
Для российских продуктовых команд, интеграторов и крупных разработчиков из финтеха, телекома и e-commerce здесь нет экзотики, но есть неприятно точный ориентир. Если код действительно дешевеет быстрее, чем перестраиваются процессы, то конкурентное преимущество уходит от тех, кто просто купил лицензии на модный ассистент, к тем, кто пересобрал планирование, дизайн, ревью, тестирование и обучение под новую экономику разработки. Главный вопрос на ближайшие пару лет звучит уже не «сколько кода напишет ИИ», а «какие компании успеют перестроить инженерное лидерство раньше, чем их бэклог окончательно перестанет соответствовать их реальной скорости».