«Модель — не самое важное». Какие ИИ-тулы (не) прижились во Flo

ИИ-стеки инженеров и не только

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

Со временем выбор сделали сами пользователи, и сейчас основной инструмент разработки у нас Claude Code. Codex и Cursor мы выключаем. Плюс у нас всегда есть предустановленные харнесы, и мы подключаем определённые наборы коннекторов, которые нам нужны.

Для разработки мы используем самые сильные фронтир-модели. И не экспериментируем с локальными. Причина в том, что результат даёт не модель сама по себе, а связка модели и харнеса, то есть всего, что вокруг неё: инструменты, контекст, правила, skills, хуки, проверки. Сейчас это называют harness engineering, и формула тут простая: agent = model + harness. Хороший разбор на эту тему есть у Addy Osmani.

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

Кроме того, мы используем Backstage, это такой dev-портал, который по сути для нас выступает агентской базой знаний. Там находятся все сервисы, которые у нас есть на продакшене, оттуда можно узнать, как они связаны друг с другом, кто за них отвечает, какие там схемы API.

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

— Но это всё о разработчиках. А что с ИИ-стеками у других специалистов?

— Дизайнеры сделали собственные Figma-плагины с AI, в том числе AI-проверку макетов. А AI-QA в локализации проверяет переводы в Figma за 15 минут вместо 1–2 дней.

К слову, для перевода мы выбрали не самую сильную модель, а ту, что лучше всего справляется с задачей: Mistral.

Эксперименты и фейлы

— Кроме Codex и Cursor вы ещё пробовали что-то, что по итогу у вас не прижилось?

— Мы попробовали Code Review от Anthropic, где несколько агентов параллельно ищут баги и проверяют находки. Это сильная вещь, но для нашего объёма PR она оказалась слишком дорогой. Оплата идёт по токенам, и одно ревью в среднем стоит $15–30. Если умножить на все PR, а при ревью на каждый push ещё и на число пушей, ловить баги этим способом получается слишком дорого. Сейчас базовое AI-ревью на PR у нас делает GitHub Copilot. Ещё до коммита разработчик сам прогоняет локальный skill для ревью и проверки безопасности, а в CI работает отдельная security-проверка.

Ещё мы пробовали такую вещь, как память компании, давай так назовём этот компонент. Агентам для работы над задачей нужен контекст. Наша первая попытка решить эту задачу выглядела так: всё выгрузить в какие-то МD-файлики, как у Андрея Карпатого в LLM Wiki. Там оно всё лежит, и мы агенту даём этот контекст.

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

Есть ещё гипотеза, которую мы проверяем прямо сейчас, — кросс-модельное ревью. Код пишет одна модель, а проверяет другая, из другого семейства: у разных моделей разные слепые зоны. Здесь, как мне кажется, есть потенциал у open-weight моделей. Ревью — более узкая задача, чем написание кода, и там дешёвая модель может давать хорошее соотношение цены и качества. Но пока это идеи и планы, результатов ещё нет.

И ещё немножко расскажу про агентный цикл для триажа багов. В одной команде запустили пилот на базе Linear. Агент разбирает трейсы, заводит баг, оценивает его влияние и создаёт задачу в Linear. Дальше решение принимает engineering manager: стоит ли этот фикс токенов. Если да, агент делает фикс. Человек здесь стоит в одной точке, где нужно суждение, — в приоритизации. А всё механическое делает агент. Отдельная тема — это то, где проводить такие границы автономности и как их измерять. Здесь останавливаться на этом не буду, но если интересно — этот вопрос мы тоже обсуждали в нашем подкасте.

Главный вывод из всех наших экспериментов такой: инструмент и модель — не самое важное, и выбор между ними быстро устаревает. К слову, мой соведущий по 3 AImigo Саша Поломодов говорил, что полураспад инструментов харнеса сейчас составляет от 3 до 6 месяцев. Поэтому важно всё то, что накапливается поверх: правила, skills, проверки и процессы. Всё это остаётся с вами даже когда вы меняете модель или инструмент.

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

— Всё верно.

Почему не локальные модели?

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

— Я бы разделил этот сценарий на две части. Для разработки мы используем Claude Code от Anthropic. Это топовый инструмент, вероятность того, что с ним что-то случится… Для этого, наверное, действительно нужно что-то вроде падения метеорита. Впрочем, в июне 2026 года доступ к Fable и Mythos действительно закрывали почти на три недели. Но, как уже говорил выше, правила, skills и проверки переносимы. Поэтому смену инструмента мы тоже переживём

Другое дело — встраивать ИИ-функции в само приложение Flo. Здесь хорошо работает подход с локальными моделями. 

Соответственно, здесь уже можно использовать локальные fine-tuning модели, которые мы можем инференсить. Они становятся нашим инструментом для того, чтобы скейлить такую нагрузку.

Да, для разработки мы пока используем Anthropic, но смотрим и по сторонам. На самом деле локальные модели становятся довольно неплохими. Я не сказал бы, что мы их активно используем или что мы делаем на них ставку. Мы к ним присматриваемся. Пока всё же проще взять какое-то SaaS-решение от того же Anthropic и использовать его.

Как создавать ИИ-фичи для огромной аудитории

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

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

Именно для этого мы сделали команду AI Platform. Строить такую инфраструктуру в каждой продуктовой команде заново дорого, и делается это по-разному. Принцип у нас простой, как у любой хорошей платформенной команды: We do the hard work so you don’t have to.

— Наверное, с точки зрения этой работы огромная аудитория в +80 млн — это не совсем хорошо? Если бы у вас было всего 100 пользователей, скорее всего, они задавали бы какие-то типичные вопросы, и подстроиться под них было бы просто. Но когда их 80 млн, нетипичных вопросов приходит очень много?

— Для решения этой проблемы мы можем сегментировать пользователей. Внутри Flo у нас есть разные режимы. Почему пользовательница использует наше приложение? Например, для того, чтобы отслеживать цикл. Или использует его тогда, когда хочет забеременеть. У таких групп разные потребности, и они разные с точки зрения безопасности (дать какой-то совет беременной женщине может быть опаснее, чем дать совет в обычном трекере).

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

Цикл создания ИИ-фичи в упрощённом виде выглядит так.

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

• Датасеты. Примеры реальных ситуаций, которые размечают эксперты. На них промпт калибруется.

• Judges. Это автоматические проверки. Они бывают детерминированными, а бывают LLM-as-a-judge, и такие судьи тоже нужно калибровать по разметке экспертов. Иначе непонятно, можно ли доверять их оценке.

• Симуляции и оптимизация. Реальный разговор — это не один вопрос и один ответ, поэтому мы прогоняем симуляции диалогов. Если промпт не проходит какой-то критерий, его можно оптимизировать автоматически. Например, есть подход GEPA: оптимизатор анализирует, где промпт провалился, и переписывает его так, чтобы он проходил проверки.

• Релиз и обучение. Только после того, как промпт прошёл калибровку офлайн на evals, мы его выпускаем, причём постепенно. Сначала на внутренних пользователей, сотрудников компании, чтобы получить ранний фидбек и посмотреть, как люди взаимодействуют с продуктом. Потом на небольшой процент пользователей.

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

Размер промпта влияет на latency и на стоимость каждого запроса. Поэтому на входе AI-приложения часто ставят роутер — дешёвую быструю модель, которая определяет интент, тему или аудиторию. Дальше уже бизнес-логика выбирает промпт под конкретный сценарий, и каждый промпт остаётся компактным и проверяемым.

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

Подробнее про evals я рассказывал на Podlodka AI Crew, а в ноябре буду говорить об этом на AI Summit Europe в Вильнюсе.

«Мы никого не заставляем». Как стать AI-native компанией (а не такой, где все как-то пользуются AI) — пример Flo

По теме

«Мы никого не заставляем». Как стать AI-native компанией (а не такой, где все как-то пользуются AI) — пример Flo

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

По теме

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