Это продолжение статьи "Я попробовал вайбкодинг после 26 лет разработки. Через 2 недели у меня был ИИ-продукт".
В этот раз я подробно разбираю практическую сторону своего личного опыта, как Claude Code писал код, а Codex помогал его ревьюить, про выбор архитектуры и другие технические моменты.
Claude Code пишет, Codex ревьюит
Когда бизнес-требования были готовы, я запустил Claude Code на тарифе за 100$ и отдал ему этот файл.
Сразу описал порядок работы:
Claude Code генерирует код, сам проверяет свои изменения, разбивает работу на этапы и фазы. Codex выступает в роли ревьюера.
В конце каждого этапа Claude Code должен писать подробный промпт для Codex о том, что было сделано, какие файлы изменены, на что обратить внимание. Я отдаю этот промпт в Codex, получаю ревью и возвращаю результат обратно в Claude Code.
Получилась связка двух моделей:
одна пишет код и быстро прогоняет проверки;
вторая смотрит со стороны, критикует, ищет ошибки и архитектурные проблемы.
Почему я использовал Codex только для ревью, а не для написания кода?
Потому что в ChatGPT у меня был тариф за 20$ в месяц, там доступен Codex, но контекстное окно не такое большое, и я использовал mini-модель именно как ревьюера. Для полноценной разработки пришлось бы платить больше, а я пока к этому не был готов.
В первом же промпте я попросил Claude Code сформировать структуру проекта так, чтобы и Claude Code, и Codex видели одно и то же. Также попросил инициализировать локальный Git для контроля версий и дать рекомендации, нужны ли какие-то skills, дополнительные инструменты, правила.
Обе модели рекомендовали пока ничего специального не ставить. Скиллы, по их мнению, понадобятся позже, когда появятся повторяющиеся действия, которые явно стоит вынести в отдельный процесс.
Выбор архитектуры
Я не стал полностью отдавать архитектуру на выбор ИИ. У меня есть собственный опыт, предпочтения и понимание, как я хочу это видеть.
В итоге архитектура получилась такой.
На CDN лежит статичный JavaScript и картинки виджета, которые загружаются на сайты клиентов.
Сам виджет обращается к субдомену widget, где работают скрипты на Go. Они выполняют роль gateway, т.е. принимают входящие запросы, логируют события, кэшируют промежуточные действия в Redis и проксируют запросы дальше.
Зачем Go? Потому что gateway должен быть быстрым, лёгким и хорошо держать нагрузку. Через него будут проходить события, типа открылся виджет, пользователь что-то написал, получил ответ, закрыл, не дошёл до конца и так далее.
Эти события нужны не только для истории диалога. Я хочу использовать их ещё и для оценки "роботности". Например, пришёл ли на сайт реальный человек или это бот, который имитирует активность.
Дальше Go-gateway проксирует запросы в отдельный API на PHP. Этот API уже отвечает за суть, т.е. какие сообщения отдавать, какие сценарии запускать, как реагировать на ответы пользователя.
Важно, что API stateless. Он не должен помнить весь контекст сессии. Он получает запрос, смотрит данные, отдаёт ответ. Состояние и быстрые промежуточные вещи живут на стороне gateway и Redis.
Отдельно есть субдомен client как клиентский кабинет на Laravel. Там регистрация, проекты, операторы, сценарии, настройки виджета, лиды, диалоги, интеграции, тарифы, биллинг и всё, что обычно нужно пользователю продукта.
Ещё есть секретный субдомен для back-office, как внутренняя админка для меня и команды.
Почему не React и не Vue
Сам виджет - это чистый JavaScript. Он должен легко вставляться на чужие сайты, быстро грузиться и не тащить за собой лишнего.
Кабинеты и админки сделаны на Laravel, blade-страницах и небольшом количестве JavaScript там, где он действительно нужен.
Мне важно было не сделать технологически модную витрину, а быстро собрать управляемый продукт, который можно поддерживать, развивать и выводить в продакшн.
Кабинет клиента съел почти две недели
В нём пользователь может зарегистрироваться, создать проект, настроить виджет для своего сайта, добавить операторов и задать правила их показа.
Оператор в моём понимании - это не живой человек, а ИИ-ассистент в виде аватара и сценария поведения. Например, на одном разделе сайта может появляться один оператор, на другом - другой. Где-то виджет появляется сразу, где-то не появляется вообще. Один и тот же аватар может работать по разным сценариям в зависимости от текущей страницы.
Для каждого проекта можно настраивать сценарии ответов. Есть дефолтный сценарий, можно добавлять свои. Есть визуальное управление виджетом, превью, получение кода для вставки на сайт.
Хранятся все входящие лиды с фильтрацией, также все диалоги, включая "брошенные" (когда пользователь начал общение, но по какой-то причине не дошёл до конца).
Есть интеграции, когда заявки можно отправлять в Telegram, на электронную почту, а в перспективе и в CRM.
Есть авторизация, восстановление пароля, подтверждение e-mail. Биллинг я уже сделал через Робокассу, хотя монетизацию пока не включал. Идея в том, чтобы сначала получить удобный и полезный инструмент, а не спешить с монетизацией.
Команды, роли и права
В клиентском кабинете я сразу заложил командную работу. Тот, кто создаёт аккаунт, становится owner, т.е. владельцем. Он может приглашать других людей в свой кабинет и управлять всем.
Admin тоже может управлять настройками и приглашать сотрудников, но не может удалить владельца.
Manager - это чаще всего маркетолог. Он может настраивать виджеты, сценарии, внешний вид, но не может влиять на оплату тарифов и звать новых людей.
И есть уровень доступа только для работы с лидами. Это условный продавец, который видит заявки, диалоги, может с ними работать, но не может менять настройки виджета или видеть то, что не относится к его задаче.
Для маленького продукта такие вещи иногда кажутся избыточными. Но если ты видел, как продукты потом растут, то понимаешь, что лучше сразу заложить нормальную ролевую модель, чем потом болезненно переделывать всё на живой системе.
Скучный CRUD, который однажды спасёт поддержку
Там можно видеть клиентов, тарифы, проекты, проблемы с чатами, сущности системы. Идея в том, чтобы менеджеру или поддержке не нужно было заходить в аккаунт клиента. Всё можно посмотреть и поправить из своей админки, с учётом ролевой модели.
Это не самая романтичная часть продукта. По сути, много обычного CRUD (операции Create, Read, Update, Delete) для каждой сущности.
Но именно такие скучные вещи потом определяют, можно ли продукт нормально сопровождать. Сделать красивый виджет - это одно. А поддерживать клиентов, разбирать проблемы, видеть, что происходит в системе, это совсем другое.
Продолжение в статье "ИИ может писать код, но умеет ли он делать красиво? Мой опыт с виджетом и аватарами".
В ней рассказываю про AI-дизайн, виджет, клиентский кабинет, аватары и ту самую неделю на маленькую штуку в углу сайта.
Если вам интересны детали реализации, промпты, архитектурные решения и сами продукты, которые я вайбкодю, подписывайтесь на мой Telegram‑канал. Там я показываю больше технической кухни, чем помещается в статью.
В комментариях буду рад вашим вопросам. Особенно интересен опыт тех, кто уже пробовал связки из нескольких моделей.