От wow-эффекта и быстрых побед вайбкодинга к проектированию архитектуры и формированию полноценной AI-driven команды

Привет! Я Катя Образцова, AI-продакт-лид и зам. руководителя развития продукта в Битрикс24. Одной из моих задач этого полугодия было внедрение AI-процессов в работу продуктового отдела, развитие культуры вайбкодинга и экспериментов с нейросетями. Чтобы чему-то учить, надо сначала самому пройти весь путь от А до Я. Я предложила нашему HR-отделу сделать сервис для ежегодного корпоративного марафона, и так за три месяца работы по вечерам и выходным мы командой из пяти человек собрали с нуля многопользовательский сервис для внутреннего спортивного марафона компании.

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

Почему именно сервис спортивного марафона 

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

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

Все изменилось на одной из общих встреч компании, где коллега увлеченно рассказывал про вайбкодинг. Я написала в общий чат сообщение «Давайте мы навайбкодим приложение для марафона». Все поддержали, публичный коммитмент был дан. Так в середине марта 2026 года стартовал проект.

Цели и инструменты

Цель сформулировали достаточно четко. Сделать сервис для спортивного марафона, который будет удобен нашим коллегам.

В нем должны быть:

• простая регистрация через корпоративный портал Битрикс24, чтобы не заводить отдельный аккаунт;

• автоматическая синхронизация с фитнес-трекерами для всех платформ, включая Android;

• понятная логика начисления баллов;

• удобная модерация для организаторов.

Три года работы со сторонними сервисами дали очень четкое понимание того, чего мы не хотим, и это сильно помогло на старте.

Для разработки мы использовали Claude Code и VS Code. Бота для поддержки участников моя коллега Настя делала отдельно, через вайбкод-платформу и конструктор ботов Битрикс24.

Что получилось в итоге

За три месяца мы сделали:

• два мобильных приложения, для iOS и Android;

• веб-версию сервиса;

• полноценную админку для модераторов с управлением тренировками, челленджами и участниками;

• бота Бита для консультации сотрудников по ходу марафона.

Авторизация во всех сервисах идет через корпоративный портал Битрикс24, отдельный аккаунт сотрудникам не нужен. Тренировки синхронизируются автоматически, через Apple Health на iOS и Health Connect на Android. С первого июня сервисом пользуются 260 участников. Они загружают тренировки, смотрят ленту активностей, лайкают и комментируют результаты коллег, следят за командным и личным рейтингом.

К этому результату нас вела крайне извилистая дорога.

Быстрые победы вайбкодинга и ловушки, в которые мы попали 

Ловушка №1 Отсутствие устойчивой архитектуры

Рабочий прототип появился в первый же день. Сайт работал, записанные тренировки автоматически отображались на платформе, интеграция с Apple Health подключилась с двух-трех промптов.

Открывать игристое за победу было рано. Многопользовательский сервис устроен принципиально иначе, чем приложение для личного пользования. Когда 200-300 человек одновременно открывают приложение, загружают тренировки, листают ленту и лайкают чужие результаты, нужна устойчивая архитектура. Очереди запросов, распределение нагрузки, корректная авторизация под нагрузкой, разграничение прав доступа. Ничего из этого в первом прототипе не было, и каждый сценарий наглядно показывал, к чему приводит архитектурная неустойчивость. Наш директор по продукту Юра Волошин помог с техническими параметрами очереди, распределением нагрузки и контейнерами, и с этого момента разработка пошла в правильном направлении. Без этого мы бы еще долго итерировали вхолостую.

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

Дальше начинается интересное. Триста человек заливают тренировки почти одновременно, и один и тот же рейтинг прилетает на пересчет десятки раз подряд. Лечится дебаунсом, первая задача ставит флаг в Redis на несколько секунд, остальные за это время отваливаются сами. А сам пересчет рангов завернут в одну атомарную операцию под блокировкой, иначе параллельные процессы перетрут друг другу результаты.

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

Ловушка №2 Хаотичный кодинг мобильных приложений без учета бека

Да, было и такое. Главная задача мобильных приложений нашего сервиса, обеспечить интеграцию с Apple Health и Health Connect. Сначала мы сосредоточились на ней, когда получилось, стали делать другие разделы. В какой-то момент поняли, что веб и мобильные приложения на iOS и Android начали расходиться.

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

Ловушка №3. Надежда на нативные элементы мобильных платформ

Нативные элементы сами по себе, без продуманного UI, выглядели мягко говоря страшно. Мы подключили в команду UX/UI-дизайнера, который вайбкодил стильный дизайн на обе платформы.

Ловушка №4. Недостаток экспертизы в домене

Чем больше мы занимались сервисом, тем лучше понимали, как мало знаем про специфику спортивных активностей. Как корректно тянуть шаги из Apple Health и Health Connect? А бег? А велосипед? Как отличить реальную тренировку от поддельной?

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

Хороший пример того, как домен заставляет принимать незапланированные решения, это борьба с накруткой. Когда за тренировки начисляются баллы и идет соревнование, часть людей неизбежно пробует систему на прочность. Загрузить одну тренировку дважды, ввести вручную несуществующий забег, выдать прогулку до магазина за велозаезд. Готового ответа, как считать тренировку настоящей, у нас не было, он сложился по ходу из нескольких слоев. Мы ограничили число засчитываемых тренировок в день, чтобы нельзя было накидать их пачкой. Для каждого вида спорта задали правдоподобные диапазоны темпа и скорости, пробежать «марафон» за двадцать минут не выйдет. Все, что участник вводит руками, а не подтягивает трекер, не публикуется автоматически, а уходит на модерацию. И отдельно пришлось отсекать «фантомные» тренировки, которые трекеры иногда выдумывают сами, например когда телефон в кармане засчитывает поездку в транспорте как активность.

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

Ловушка №5. Недостаток ручных тестов

Claude всегда пишет тесты на свой код. Много, аккуратно, с покрытием. Первое время это здорово успокаивает: тесты зеленые, значит все работает.

По факту они проверяют то, что можно посчитать: правильно ли начисляются баллы и как отрабатывают зависимости. А что будет, когда живой человек с конкретным телефоном, конкретными часами и своей версией Android попробует залить тренировку, которую его трекер обозвал не так, как ждет система, об этом тесты молчат.

Все это вылезло на фокус-группе. Через полтора месяца мы собрали 30–40 коллег и пустили их в тестовый режим на реальных тренировках. Дальше пошли сюрпризы, которые ни один автотест не поймает. Айфоны грузят фото в HEIC вместо JPEG, и пока мы не научили систему его читать, часть народа просто не могла прикрепить фото. Некоторые Android-телефоны отдавали битый по стандарту JPEG, на котором обычная библиотека спотыкалась. А самый цимес в том, что разные трекеры зовут одну и ту же активность по-разному, и система, заточенная под одно название, не понимала другое.

Мораль простая. Зеленые автотесты усыпляют, а весь стык с реальным миром остается непокрытым — форматы файлов, капризы конкретных моделей, разнобой в данных от трекеров. Этот слой закрывается только тестированием живыми устройствами в руках живых людей, и чем раньше их подключишь, тем дешевле выйдет.

Как прошел марафон 

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

• Сервис выдержал нагрузку, очереди работали корректно. Один раз он лежал полдня. Неприятно, но не смертельно, иногда лежат даже большие сервисы, так что мы восприняли это без паники.

• Заложенная геймификация зашла на ура. Участники активно включались в челленджи, следили за выдачей медалей, комментировали активности друг друга и ставили лайки.

• По ходу пришлось несколько раз обновлять мобильные приложения и веб. Все прошло незаметно для пользователей благодаря CI/CD и удобной системе обновлений.

Итоги и планы

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

Еще одно направление, которое точно стоит добавить — AI-модерация тренировок. Сейчас модераторы проверяют скриншоты вручную, и мы целенаправленно копим этот опыт, чтобы потом обучить нейросеть делать это автоматически.

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

Источник: habr.com