«Тренд — маленькие команды и кросс-люди». Как ИИ меняет инженерные роли и найм во Flo (и вообще)

«AI fluency — такой же навык, как System Design или знание Computer Science»

— Как вообще внедрение ИИ-инструментов изменяет хайринг? Насколько внимательно вы присматриваетесь к тому, умеет ли человек работать с ними?

AI fluency стала обычной частью навыков, которые мы проверяем на интервью. Это не отдельный этап и не бонус, а такой же навык, как System Design или знание Computer Science. Главное изменение в том, что нам теперь важнее не то, решил ли кандидат задачу на интервью, а то, как они её решали.

Кандидат может расшарить экран и показать свой харнес: как он общается с агентом, какие у него (неё) правила и skills, как он (она) разбивает задачу. По этому сразу видно и уровень инженера, и уровень его работы с ИИ.

На то, как устроен наш найм, можно посмотреть на примере engineering-менеджеров. Там хорошо видно, что мы смотрим на суждения и компромиссы, а не на заученные фреймворки.

Что делать джунам и вузам

— Джунов вы не нанимаете?

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

Именно этому джунам теперь нужно учиться с самого начала, потому что простых задач, на которых раньше набирали опыт, становится меньше. Сложность при написании кода ушла, да? Но всё равно остались фундаментальные вещи, на которые нужно набивать руку: постановка задач, проверка качества.

— Получается, что ИТ-вузы сейчас выпускают сотни специалистов, которые вообще не нужны продуктовым компаниям, пока не наберутся опыта, а набраться почти негде. Как решать эту проблему? Уменьшать выпуск айтишников?

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

Проблема в индустрии, о которой ты говоришь, есть. Есть новости от условной «Меты», которая сокращает очередной Х тысяч человек. Есть скрытые сокращения, когда позиция ушедшего специалиста не занимается. Как это делается? Часто говорят: «Точно ли вам нужен человек на замену? А докажите, что вы не сможете делать всё то же самое, что и с ним, но без него, с меньшей командой».

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

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

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

Легче программировать = меньше программистов?

— Людей, для которых программирование — это профессия, будет становиться всё меньше?

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

Это уже не кодеры, которые когда-то просто писали код. Вот для тех будущее — действительно очень туманное.

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

— Помнишь, ты говорил, что спрос на софтвер может оказаться конечным? Так вот, пока ответа на этот вопрос никто не знает. Мы видим, что появляются новые ниши, как в этом твоём примере. Если нужно какое-то персонализированное приложение, как игра этого историка, у тебя теперь возникает вопрос: нужно сходить в маркет поискать, или я могу сесть и для себя его написать? С нужным функционалом, а не какой-то комбайн, от которого мне будет нужен 1% его функциональности.

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

С ИИ работы меньше, а выгорание больше?

— Давай про рост когнитивной нагрузки на сеньоров, которые у вас занимаются ревью. Она ведь растёт? Когда на тебя сваливается цунами сгенерированного кода, когда тебе нужно постоянно переучиваться — разве это не ведёт к быстрому выгоранию высокоуровневых специалистов. Как в таких условиях сохранить этих очень-очень ценных людей, "конечный ресурс"?

— Да, ты прав, количество пул-реквестов явно выросло. Мы это видим по нашим метрикам. Наша задача — это удержать метрику PR Cycle Time, одну из главных, про которую я рассказывал в прошлый раз, в диапазоне двух дней. У инжиниринг-менеджера, который будет работать с командой, это будет одна из метрик, которую он будет стараться с командой оптимизировать.

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

Мы смотрим, как всё это можно сместить влево. Почему мы ревьювили этот код? Какие мы попросили внести правки? Можно ли это вынести в какие-то скилы, которые будут запускаться от локального инженера после того, как он либо она написали какие-то изменения перед тем, как отправить PR. И этот цикл улучшений идёт постоянно. Соответственно, нагрузка на инженера, который занимается ревью, перестаёт расти с той же скоростью, как растёт количество пул-реквестов. И становится более-менее линейной.

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

Сейчас мы как раз переходим с Jira на Linear. И в Linear это классно можно реализовать. У нас уже есть небольшой пилот, где мы это проверяем. Изначально формулируем какие-то продуктовые требования, ставим задачи. Дальше с агентом дополняем план, который идёт ему на execution. И там подключается человек, чтобы этот план поревьювить. QA может сказать, какая валидация здесь нужна, инженер — какие есть ограничения у системы, Product может задать свои требования. Сейчас это три роли, три разных человека, но со временем для этого понадобится меньше людей.

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

А сейчас получается, что я беру одну задачу и, пока агент её делает, должен переключиться на следующую. Для меня нет смысла смотреть в монитор и следить, что он там делает. Моя задача — прийти, проверить результат работы, добавить какие-то вводные, что-то подрулить.

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

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

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

Знаешь эту фразу про мусор на входе и мусор на выходе? И если мы не хотим мусора на выходе, наверное, нужно, чтобы и на входе не было мусора. Будем экспериментировать. Думаю, ревью — это то, от чего индустрия со временем будет отказываться в пользу автоматизации. Тот же Anthropic Code Review — неплохой инструмент. Просто пока супердорогой.

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

Люди-роутеры и кросс-люди

— Ты уже достаточно давно работаешь на менеджерских позициях, но пришёл на них с инженерного направления. Опыт работы на инженерных позициях в Объединённом институте проблем информатики НАН Беларуси как-то помогает тебе рулить ИИ-трансформацией во Flo?

— Весь предыдущий опыт для меня полезен. Например, в ОИПИ мы были крупным интегратором медицинских систем. Там я работал в медицинском домене и был чуть-чуть погружён в него. Интеграция какой-то медицинской системы в систему здравоохранения — это общение с заказчиками, с вендорами. Конечно, эти вещи были очень полезными.

Ещё я был техническим директором и фаундером в компании BIS-Soft. Не очень большой стартап, который делал платформу обмена медицинскими данными. Учреждения здравоохранения — они фрагментированные. В том смысле, что переслать какие-то данные из одной клиники в другую иногда просто невозможно, потому что системы для них делали разные вендоры. И мы делали платформу, которая помогала обмениваться данными.

Этот опыт тоже был суперполезным. Потому что через него я, как оунер, пришёл к такой мантре: идеи нужно проверять очень быстро. Я это называю Fail Fast or Learn Fast. Если что-то не работает, не нужно за эту идею держаться. Ты проверил гипотезу, она не работает? Подумай, как её можно адаптировать.

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

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

— Работая на менеджерской позиции ты скучаешь по кодингу?

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

— Интересно. Здесь, наверное, тоже будет какой-то естественный отбор, и таких людей-роутеров LLM заменят быстрее остальных менеджеров?

— Да. Это, кстати, одна из моих мотиваций быть Head of AI Platform. Это чуть ближе к технологиям. Я всегда пытаюсь строить траекторию карьерного развития. Мы как-то обсуждали это с Сашей Поломодовым. Он какое-то время работал в Т-банке как СТО одного из направлений, а потом переключился в Fellow-инженера. Понимаешь, ты должен иногда задаваться вопросом «что ты можешь дать компании?» Но должен быть и вопрос «что компания может дать тебе?» Потому что ты со временем должен развиваться, твои навыки для рынка должны оставаться релевантными.

Сейчас в индустрии мы видим, что количество вакансий для инженеров схлопывается. Менеджеров и так было меньше, один приходился на команду из пяти-десяти инженеров. Но число вакансий для них уменьшается ещё быстрее. Сами команды становятся меньше, и наличие у менеджера сразу двух-трёх-четырёх команд становится нормой. Оставаться ближе к hands-on — это, как мне кажется, стратегическая ставка для менеджеров.

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

— Три года — большой горизонт. Как оно всё изменится, очень сложно сказать. Но какой я вижу тренд сейчас? Он называется Tiny Teams, «маленькие команды». Когда команда из двух-трёх человек начинает выполнять больше задач. За счёт чего она это делает? За счёт того, что в команде у человека появляется больше ролей. Раньше мы делали кроссфункциональную команду, куда добавляли роли по принципу «плюс роль — плюс человек». Мобильный инженер, бэк-энд, JS и так далее. А сейчас человек плюс ИИ-инструмент может совмещать в себе разные роли. И делать сразу решение под ключ, когда тебе не нужно ждать бэк-энда и можно сразу сделать свою часть.

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

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