Поговорили с Евгением Сергеевым, который до недавнего времени работал во Flo Health как Director of Engineering. Сейчас он сфокусировался на ИИ-трансформации в компании на позиции Head of AI Platform.
Поговорили с Евгением Сергеевым, который до недавнего времени работал во Flo Health как Director of Engineering. Сейчас он сфокусировался на ИИ-трансформации в компании на позиции Head of AI Platform.
Почему строки кода и количество PR — это ошибочные метрики для оценки ИИ-трансформации? На чём сфокусировались во Flo? Какой адопшен ИИ-инструментов лучше — сверху или снизу? Как оптимизировать расходы на токены? И сколько айтишников в мире имитируют работу с ИИ, чтобы избежать увольнения?
— Как во Flo Health измеряют эффективность использования ИИ? И как вы пришли к выводу, что он реально помогает в работе, а не создаёт иллюзию высокой продуктивности?
— Существует очень много фреймворков измерения продуктивности инженеров, часть из них я разбирал в одном из выпусков подкаста 3AImigo, который мы ведём с Сашей Поломодовым. Там мы и DX затрагивали, и DORA репорты, и SPACE. Все они довольно сложные, комплексные.
Во Flo мы давно сфокусировались на нескольких метриках, которые, мне кажется, довольно хорошо могут показать и импакт, и то, насколько инжиниринг в целом хорошо работает.
Но начну с того, что НЕ работает. Токены, число лицензий, доля кода, написанного ИИ, — это метрики активности, такой же Lines of Code. Агенты легко увеличивают и объём кода, и число PR, это и есть иллюзия продуктивности. Мы подробно разбирали это во втором выпуске нашего подкаста.
Главная метрика для нас — это cycle time: сколько времени проходит от момента, когда задачу взяли в работу, до момента, когда ценность доходит до пользователя. Она показывает, на каком этапе работа замедляется. Когда AI ускоряет один этап, узкое место переезжает на следующий, и его надо расшивать. Обычно для этого мы пересматриваем сам процесс и переносим проверки левее.
Самый наглядный пример сейчас — код-ревью. Агенты пишут в 5–10 раз больше диффов, а людей и часов на ревью осталось столько же. Узким местом стало ревью, а сразу за ним QA. Если починить только ревью, работа просто будет ждать в очереди на QA. Поэтому мы делаем несколько вещей:
Ревьюим не только код, но и план. Сеньор смотрит намерение и план, которые уходят агенту, ещё до того, как появится код. Потому что ошибку в архитектуре дёшево исправить на бумаге и дорого в коде.
Каждое замечание на ревью становится правилом. Задача ревьюера — не написать LGTM, а превратить замечание в правило или skill, чтобы агент не повторил ошибку в следующий раз. Раз в месяц правила, которые не работают, выбрасываем.
Механическую часть ревью отдаём AI. До коммита разработчик прогоняет локальный skill для ревью и проверки безопасности. На каждом PR работают security-проверка в CI и AI-ревью, где несколько агентов параллельно ищут баги и отсеивают шум. Человек решает то, что требует суждения: юридические риски, допустимый риск, продуктовое чутьё, границы доверия.
Каждое изменение проходит свою дорогу. Ориентир такой: изменение доходит до main за несколько дней. Если дольше, процесс сломан.
Начинать надо с малого. Мы начали с обновлений зависимостей через Dependabot и довели этот поток до полной автономности: PR мержится без человека, если проходят юнит-тесты и проверки безопасности. Чтобы это стало возможным, пришлось доработать проверки в CI/CD, написать правила и договориться с security-командой. За четыре месяца доля PR, которые мержатся полностью автоматически, выросла с 0 до 10,7%. Сейчас на этом фундаменте расширяем автоматизацию на другие классы изменений.
Адопшен — это важная прокси-метрика, но не цель. Она показывает, какие инструменты и как используют в командах. На старте важно вкладываться именно в адопшен и ничего не ограничивать: пусть инженеры экспериментируют с разными инструментами и практиками. Унифицировать и вводить стандарты можно позже. Если у какой-то команды или функции адопшен ниже, это повод для разговора, а не для наказания: надо понять, что у людей не работает. Из таких разговоров и рождаются задачи на улучшение.
Добавлю, что стоимость надо считать с первого дня, нужно сразу выделить бюджет. С ростом адопшена она точно будет расти. Со временем появляются правила оптимизации, и их надо включать по умолчанию в харнесе, а не оставлять на совести каждого инженера. Например, самая дорогая модель по умолчанию выключена, настройки раздаются централизованно. После того как мы включили такие дефолты, стоимость Claude Code на человека в день снизилась на 28%.
Хороший разбор этой темы — статья Uber Running a Software Factory Efficiently at Uber Scale: они раскладывают затраты на множители и оптимизируют стоимость сессии и запроса, а не общий счёт. Часть оптимизаций мы подсмотрели у них.
— Как-то в цифрах это можно выразить? Допустим, есть инженер без AI-инструментов и инженер с AI-стеком. Получится ли с вашими метриками напрямую сравнить их производительность?
— У нас сейчас нет инженеров (и даже не инженеров) в компании, которые не используют AI в своей работе. Потому что мы стремимся оптимизировать всю рутину через такие инструменты.
Но мы видим, что cycle time в командах, которые внедрили в разработку mature-практики с использованием AI, уменьшился до двух дней. И мы хотим уменьшить его ещё больше, до одного дня.
— А сколько времени такой типичный цикл отнимал у команд до внедрения ИИ?
— Примерно четыре дня, если взять какой-то медианный показатель.
— Есть какие-то метрики или примеры внедрения AI, которыми ты больше всего гордишься?
— Горжусь рабочей группой по company skills (на данный момент в реестре у нас 109 скилов), которую я запустил. Skills автоматизируют разные этапы работы. Шли мы к этому так:
Собрали skills, которые у кого-то уже лежали локально.
Стали продвигать их на AI gatherings, где люди показывают, какой skill сделали.
Сделали так, что skills автоматически доступны всем, и начали собирать аналитику использования.
Сейчас добавляем к ним тесты, чтобы поднимать качество, и собираем golden set skills.
Важно, что это не только про инженеров. У нас есть skills, которые сделали дизайнеры, аналитики и маркетинг. Из отдельных skills уже собираются целые AI-native workflow, где шаги одного процесса — skills разных функций.
Кстати, о том, что отличает AI-native компанию от компании, где все просто пользуются AI, мы говорили в восьмом выпуске нашего подкаста.
— Adaptavist недавно опросила тысячу айтишников из США, Великобритании, Германии, Нидерландов и Испании. И оказалось, что 50% опрошенных имитируют работу с ИИ-инструментами только для того, чтобы показать руководству, что умеют. Насколько реалистичной тебе кажется эта оценка?
— Мне эта цифра показалась очень сомнительной. Я вижу, что уже никто не может отрицать, что это хорошие productivity-инструменты. Раньше, конечно, были сеньоры, которые с трудом принимали новые инструменты или отказывались от их использования. Мне вообще кажется, что сеньоры отрицают любые новые инструменты до той поры, пока те не становятся настолько хорошими, что дают прирост продуктивности, легко видимый невооружённым глазом.
Но сейчас я точно вижу, что инструменты используются, и какой-то имитации работы с ними во Flo я точно не вижу. Плюс, наверное, всё это ещё очень зависит от компании.
У меня нет доступа к информации о тысячах компаний по всему миру. Но, если судить по тому, что я вижу и слышу от знакомых, такая имитация происходит в компаниях, где использование ИИ-инструментов насаждается сверху вниз, где есть какая-то директивность вроде «либо вы используете инструмент, либо мы вас увольняем».
— Похоже на то. Из этого же опроса следует, что частоту использования ИИ внесли как KPI уже для 58% опрошенных специалистов.
— У нас во Flo это внедрение шло как снизу вверх, так и сверху вниз. Сверху мы, как инженеринг-лидеры, сказали: «О’кей, нам важно, чтобы вы овладели этими инструментами. При этом мы сейчас не знаем, какой инструмент будет лучше — условный Claude, Codex или Cursor? Мы их всех заонбордили, пробуйте». Но даже движение сверху не должно быть директивным, оно должно работать через объяснения.
А снизу инженеры начали пробовать инструменты, у них получались какие-то интересные кейсы, они стали ими делиться в комьюнити.
В компаниях, в которых все эти нововведения и метрики навязываются сверху, людям ничего не остаётся, кроме как вести себя в соответствии с законом Гудхарта [Когда мера становится целью, она перестаёт быть хорошей мерой]. «Дайте мне любую метрику, и я её буду геймить». Для меня это выглядит так.
У меня инженерный бэкграунд. Знаешь, почему я стал инженером? Потому что я увлекаюсь новыми технологиями, и при этом я ленивый. Для меня программирование было способом автоматизировать рутину. И сейчас с ИИ-инструментами для инженеров происходит что-то подобное. Это хороший инструмент, который позволяет быть продуктивным, делать больше, узнавать больше.
И здесь человек, который имитирует работу с ИИ-инструментами, входит в конфликт с самим собой. Зачем тебе имитировать то, в чём ты видишь пользу для себя? Думаю, такая имитация происходит именно там, где люди не видят для себя пользы в новых инструментах и где соответствующие метрики ставят как цель.
Если в качестве метрики ставить импакт на пользователя, доставку фичей, я думаю, внедрение ИИ произойдёт довольно органично. Потому что люди будут воспринимать эти инструменты как ускоритель своей продуктивности.
— Ты допускаешь, что во Flo есть очень классный инженер, который отлично справляется со своей работой без ИИ-инструментов или использует их очень поверхностно? И просто чтобы не выбиваться из общей картины, он имитирует, что работает с их помощью?
— Думаю, я бы удивился этому очень сильно. По нескольким причинам.
Во-первых, чтобы имитировать, тебе нужно как-то тратить токены. А на что их тратить, если это не какие-то рабочие задачи? Для меня такая цепочка выглядит довольно странной.
Во-вторых, мы во Flo изначально нанимаем сеньор-инженеров с опытом минимум от пяти лет в индустрии. Мы не нанимали мидлов и джуниор-инженеров. И ещё на этапах интервью как продуктовая компания проверяем, насколько интересно людям делать продукт. Если человеку действительно это интересно, он будет делать продукт, а не симулировать какую-то бурную деятельность.
Кроме того, зачем что-то имитировать, если адопшен — это не KPI? Ну и, наконец, сейчас уже для всех очевидно, что ИИ даёт буст к продуктивности.
— Разработчиков по их отношению к ИИ можно разделить на три условные группы: тех, кто фанатеет от ИИ, тех, кто не испытывает от него особого восторга, но охотно копирует сгенерированный код и на скептиков, которые недолюбливают ИИ и сопротивляются его внедрению из-за разных опасений и консерватизма. В ваших командах есть люди из всех этих групп? Не конфликтуют ли они между собой?
— Я вижу это разделение чуть по-другому. Не по отношению к AI, а по тому, как люди вообще принимают новые технологии. Для этого есть классическая модель Technology adoption life cycle: новаторы и ранние последователи, раннее большинство, позднее большинство и отстающие. Она полезнее, чем деление на фанатов и скептиков, потому что описывает не отношение человека, а момент, когда новое становится для него полезным. И у каждой группы есть своя роль во внедрении.
Новаторы и ранние последователи — это те, кому интересно пробовать всё новое. Они пробуют новинку, а потом делятся впечатлениями с другими. Это костяк, на котором держится любое изменение, и для менеджера очень важно делать ставку на таких людей: давать им время, доступы и площадку. Мы их называем AI champions. Раз в две недели мы собираемся на AI gathering — форум, где люди показывают, что попробовали и что сработало: новый skill или новый подход к задаче. Если интересно, как раз модель с ИИ-чемпионами мы обсуждали в первом выпуске подкаста.
То, что нашли чемпионы, превращается в харнес. Удачный приём становится правилом или skill, skill попадает в общий маркетплейс, а оттуда автоматически на ноутбук каждого инженера. Проверки встраиваются в CI. В результате большинство получает ИИ уже не как новую технологию, которую надо осваивать, а как рабочий инструмент, встроенный в SDLC. Человеку не нужно разбираться, как правильно промптить и какую модель выбрать. Лучшие практики уже лежат в инструментах, которыми он пользуется.
Этим же способом закрывается и разрыв в компетенциях. Если каждый осваивает ИИ сам, разрыв между энтузиастом и всеми остальными только растёт. Если опыт энтузиаста становится общим харнесом, разрыв сокращается: средний инженер работает с теми же skills и проверками, что и самый продвинутый.
Конфликта между группами мы не видим, потому что никого не наказываем за низкий адопшен. Если у какой-то команды он ниже, это повод поговорить и понять, что у людей не работает. Опасения скептиков часто бывают разумными: это и про качество кода, и про безопасность, и про ответственность за результат. Такие опасения мы превращаем в проверки и правила. В результате получается, что скептик тоже вносит вклад: благодаря ему харнес становится надёжнее.
— Твоя новая должность была создана под тебя? Или она существовала в компании и раньше?
— Это новая должность. Она появилась в связи с тем, что мы стали использовать ИИ в приложении.
— На прежней позиции инженерного директора твой круг обязанностей был пошире, чем здесь? Сейчас ты углубился именно в ИИ?
— Обязанности примерно в том же диапазоне остались. Просто там я отвечал за несколько команд, а сейчас за одну команду. В целом же у меня была очень похожая схема, похожие проблемы, которые мы решали. Ну и раньше я был, скорее, консьюмером, а теперь моя команда делает платформу, в которой мои предыдущие команды будут выступать как консьюмеры. Я знаю проблемы со стороны ИИ-агентов и, соответственно, могу их решать.
— Уход глубже в сторону ИИ — это твоя инициатива? Или просто так сложилось?
— Да, это то, что мне нравится. Я потому и веду подкаст 3AImigo, что мне интересна эта тема. Выступаю на конференциях, рассказываю про ИИ-трансформацию. И мне нравится решать сложные задачи, связанные с ИИ.
Например, у меня была команда интернационализации, которая занималась переводами. Кажется, простая задача: попросить ChatGPT перевести что-то на все необходимые языки. Но тут же возникает куча нюансов. У нас медицинский контент, в котором мы рассказываем, какой у пользовательницы день цикла, что она будет испытывать, какие симптомы возможны. При дословном переводе на другой язык могут появиться какие-то нюансы, из-за которых эта информация прозвучит по-другому. Соответственно, тебе нужны специалисты по разным языкам, которые проверят эти переводы с точки зрения семантики, каких-то других нюансов. И автоматизировать такие вещи за счёт ИИ — это уже довольно интересная задача. Не совсем тривиальная, я бы сказал.
Я, как конечный пользователь этих чатов, вижу, что пока они с трудом понимают, что семантические поля в разных языках у одних и тех же понятий могут быть разными. И это иногда приводит к очень курьёзным ситуациям.
— Ты себя чувствуешь инициатором ИИ-трансформации во Flo? Или это идёт откуда-то ещё?
— Я точно не скажу, что я один её запустил. Инжиниринг-лидеры во Flo поддержали эту трансформацию. А идёт она, как мне кажется, от нашего CTO [Романа Бугаева]. Он у нас очень активный, показывает пример, как пользуется ИИ в жизни, автоматизирует рутину, рассказывает, как это важно для компании — трансформироваться.
Я, скорее, на позиции технического директора работал с командами, искал «бутылочные горлышки», разбирался, какие процессы мы можем автоматизировать. Напомню, что трансформация происходила и снизу вверх: активные инженеры понимали, насколько это круто, делились с комьюнити, стремились сделать какой-то общий стандарт для всех, чтобы впоследствии каждому не приходилось изобретать велосипед.
— Финансовым планированием на этом направлении ты тоже занимался?
— Да. Мы планировали headcount, бюджеты на вендоров для разных команд.
— Сейчас ваши траты на токены окупаются за счёт экономии трудовых ресурсов или не окупаются? Ваши финансовые ожидания от ИИ-трансформации оправдались?
— Когда у нас был адопшен, мы хотели попробовать как можно больше инструментов. Пока мы пробовали и не пришли к чему-то конкретному, мы не особо ограничивались в тратах. Но потом, когда мы увидели, что траты постоянно растут, пришла пора запускать цикл оптимизаций. Около двух месяцев назад мы сделали очередную оптимизацию и увидели, что наши траты на ИИ стали примерно плоскими. Даже стали понемногу проседать. Появляются модели чуть дешевле, модели, которые эффективнее справляются с задачами при тех же тратах.
Оптимизации делали и на уровне конфигов и харнесов. Где-то, например, ограничили использование супермощных дорогих моделей для решения несложных задач, вроде «сделать summary какого-то документа». Базовые гайдлайны в виде скиллов, которые на твой запрос отвечают: "О’кей, если ты просишь сделать summary, тебе достаточно будет Sonnet-а". И харнес всё это подхватывает сам, человеку даже не нужно будет самому всё это переливать. Но если необходимо, есть возможность переключиться и на более дорогую модель.
А ещё у нас есть лимиты.
Базовый лимит, с которого мы начинаем — это $1000 на человека. Если ты упираешься в этот лимит, можешь сделать запрос на увеличение. Это снова то, что я называю «хорошей бюрократией». Запрос придёт менеджеру на апрув. Менеджер почти всегда апрувнет, но может задать вопрос: что ты такого делал, что лимиты превысил? Но не с точки зрения какого-то возможного наказания, а из интереса: что здесь можно оптимизировать?
Может оказаться, что человек просто выполнял сложную задачу. И такой расход может быть оправданным, потому что если бы эту задачу выполняли люди, она растянулась бы и обошлась значительно дороже. Хороший пример — недавняя миграция. После изменения контракта Scala-библиотеки инженер с помощью Fable перенёс её реализацию на Python и TypeScript и мигрировал сервисы, которые её используют.
Раньше это был бы кросс-командный проект. Сейчас такую работу можно и нужно делать в одиночку. Мы даже записали это как инженерный принцип: миграцию может провести один человек, а не команда. Даже сложное и большое изменение на 95% может вести один инженер или одна команда, и за 10% прежнего времени.
Но когда миграция дешевеет, цена её качества растёт: даже мелкая шероховатость ломает коллегам представление о коде, который вы поддерживаете вместе. В результате влияние суждения отдельного инженера на компанию сейчас выше, чем когда-либо.
— Сотрудники обычно вписываются в лимиты?
— В среднем на человека у нас сейчас уходит около $20 в день.
— То есть лимит в $1000 на месяц — это с хорошим таким запасом?
— Да.
— Разработчики топовых моделей не скрывают, что работают в убыток. У того же Anthropic по уточнённым данным чистый убыток за первое полугодие 2026 составил $80,7 млрд. И есть такая популярная гипотеза, что они продают топовые модели ниже себестоимости для того, чтобы «подсадить» компании и инженеров на свои продукты. А потом начнут поднимать цены. Ты можешь подтвердить эти опасения? Или нет?
— Я точно не знаю, какие у них планы, поэтому моё мнение может выглядеть спекулятивным. Но давай попробуем. Есть конкуренция. Если то, о чём ты говоришь, начнёт делать Anthropic, этого, возможно, не будет делать OpenAI. А все эти настройки, харнесы, скилы — они очень легко переносятся. И миграция с одного ИИ-продукта на другой для компании суперпростая. А ещё есть Google, который немного отстаёт в этой гонке, но их Gemini-модели довольно неплохие.
Я думаю, что подписочная модель на короткой дистанции действительно может быть для них убыточной. Но они ведь тоже продуктовые компании, для них важен Feedback Loop, понимание того, как используются их инструменты и какие инструменты нужно выпускать на рынок ещё. И всё это требует расходов.
Сейчас видно, как ускорился выпуск моделей. Они ищут Loop, как сделать так, чтобы модели могли обучать следующие поколения моделей, сделать новое ускорение. И, как любая зарождающаяся технология, такие продукты поначалу могут быть дорогими и труднодоступными.
Но со временем, как когда-то интернет, все эти модели станут коммодити. Интернет сейчас доступный, мы с тобой легко через него созваниваемся, даже не задумываясь о его стоимости. И с моделями, я думаю, мы тоже к этому придём.
Как изменятся подписочные модели и доступ к ним в ближайшем будущем? Увеличат ли цену на него или нет? Мне кажется, что если они начнут повышать цену, компании просто активнее начнут проводить оптимизации. Перейдут, может быть, на китайские open-weight модели, от чего в итоге выиграют дата-центры и провайдеры, а не Anthropic. Думаю, что политику, которую ты описал, можно сравнить с выстрелом себе в ногу.
Уже существуют техники оптимизации таких костов, которые позволяют держать расходы в умеренном диапазоне. Опять же, всё очень зависит от компании. Я видел, что на рынке сейчас компании начинают перераспределять ИИ-бюджеты между разными проектами. Например, если это какой-то важный проект — да, мы выделяем на него токены. А если это какая-то internal система — можно её и силами инженеров разрабатывать, не тратя токены.
Мне сложно сказать, правильная или не правильная это политика. Я бы не хотел работать в команде, где мне говорят: "А теперь пишите код по-старому". После того, как попробовал писать код с агентами, написание кода по-старому можно сравнить, наверное, с созданием кода на ассемблере.
— Есть такой инструмент, как Anthropic Code Review, который умеет делать ревью, но обходится очень дорого. На твой взгляд, вам удастся приобщить его к своей ИИ-трансформации? Может, цены на него упадут, или ты сможешь уговорить руководство на больший бюджет?
— Скорее всего, необходимость в этом инструменте просто отпадёт. Какой-то verification loop встроится в цикл интента и разработки, и ещё раз ревьюить pull request нам просто не будет нужно. И когда агент сделает код, я уже смогу ему доверять.
Прогресс в эту сторону мы уже видим по последним моделям, которые стали справляться с подобными задачами значительно лучше. Раньше нужно было много «обвяза», чтобы направлять агента. А сейчас уже можно с ваншота получить довольно неплохой код. Когда агент начнёт точно следовать инструкциям и правилам, которые мы в него вводим, необходимость в ревью кода может отпасть. Механическая работа уйдёт агентам, а суждение человека переедет на ревью плана и интента.
Тут китайцы показывали инструменты с похожей функцией. Они делают паттерн с «судьёй», в котором на pull request накидывают сразу несколько моделей. Одна модель критикует, вторая критикует, потом всё это собирается, проходит ещё какой-то цикл. И если у условного Anthropic порядок цен около $30 за PR, у китайского вот этого аналога он уже порядка $8 за PR. Вот, собственно, и свободный рынок. Ты уже можешь решать, какой тебе инструмент использовать.
Во второй части мы обсудим с Евгением Сергеевым трансформацию найма в эпоху ИИ, судьбу джунов и вузов, которые их готовят, и то, как кросс-команды заменяются кросс-специалистами. Не переключайтесь!
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.
Классическая IT-проблема - обновить зависимости, когда их 1-2 тысячи и никто не понимает, зачем они нужны.
Можно перескакивать на очередную субсидируемую инвестиционными деньгами модель, но пока термоядерных электростанций нет - всё по итогу (как и с bitcoin) упрётся в стоимость электроэнергии, сжигаемой инференсом для выполнения детерминированных задач (а это 90+% задач в отрасли).
Если пользователями считать девелоперов, то cycle time легко может стать короче скорости публикаций обновлений в App Store и Google Play.