Вайбкодинг для не-технарей: как взяться за сложный технический проект и не обмануться быстрыми победами

Вайбкодинг может создать у новичка обманчивое ощущение: рабочий прототип с первого взгляда уже выглядит идеально. На самом деле работа только начинается. Дальше идут грабли, архитектура, тестирование и реальность. Екатерина Образцова, AI-продакт-лид и заместитель руководителя развития продукта в Битрикс24, рассказала о том, как провести продуктовую команду без единого разработчика через трехмесячный проект многопользовательского сервиса.

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

Главный риск: обмануться быстрой победой

На следующий день после старта сайт уже работал. Интеграция с Apple Health подключилась с первого промпта, тренировки сотрудников отображались и ранжировались по системе начисления баллов.

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

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

Спроектируйте архитектуру раньше, чем напишете первый экран

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

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

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

Ничего из этого нельзя дописать потом, поверх готового экрана. Такие вещи закладывают в самом начале, до первого промпта про пользовательский сценарий.

Сначала бэкенд и контракт, потом клиенты

Соблазн делать клиентское приложение «по фиче» и откладывать бэкенд велик, особенно когда фронт оживает за секунды. Это прямой путь к расхождению версий, когда веб, iOS и Android начинают жить своей жизнью.

Команда сосредоточилась на главной задаче мобильных приложений, интеграции с Apple Health и Health Connect, и потом стала добирать остальные разделы. В какой-то момент веб и оба мобильных клиента разъехались. Пришлось сделать шаг назад, завести корректные эндпоинты и SDUI на бэкенде и завязать приложения на них. После этого разработку можно было продолжать. Все-таки бэкенд определяет логику, а клиенты лишь работают в ее рамках.

AI-тесты не заменяют ручное тестирование и фокус-группу

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

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

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

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

Как собрать AI-driven команду под такой проект

За три месяца сложилось понимание оптимального состава для подобного проекта:

• 1 архитектор — человек, который понимает, как обеспечить стабильность многопользовательского сервиса под нагрузкой;
• 2 продакт-инженера — берут на себя и проработку пользовательских сценариев, и собственно вайбкодинг;
• UX/UI-дизайнер;
• QA-инженер.

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

Похоже, именно умение мыслить системно и станет ключевым навыком продакт-инженера в ближайшем будущем. Код все чаще будет писать AI, а думать за систему — человек.

Что в итоге

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

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