Игровая платформа AI-чатов
Разработка 0→1 игровой B2C-платформы AI-чатов; я вёл её как Project Lead и full-stack инженер в кросс-функциональной команде из 20 человек.
- React
- TypeScript
- Vite
- TanStack
- Keycloak
- API Gateway
- Lambda
- Go
- PostgreSQL
- Terraform
00 / Обзор
Контракт с июля 2025 по май 2026 года: разработка 0→1 B2C-продукта, в котором игроки разговаривают с AI-персонажами внутри игрового сценария. Я совмещал руководство проектом с собственной full-stack разработкой в кросс-функциональной команде из 20 человек и подчинялся напрямую президенту компании и проектному менеджеру.
01 / Контекст
Сценарий подстраивается под реплики игрока, но его общий ход остаётся таким, как задуман. По сути продукт — это сам разговор. Типичная слабость AI-персонажей в том, что они соглашаются со всем подряд. Здесь каждый ответ вырабатывает небольшая экосистема AI-агентов, чтобы персонаж мог убедительно отказать; при этом ответ всё равно должен приходить быстро.
Более ранняя кодовая база существовала: её написал один разработчик больше года назад. Для нового объёма задач он давал мало опоры, поэтому платформу, по сути, построили заново.
В команду входили инженеры, дизайнеры, контент-специалисты, AI-разработчики и проектный менеджер.
02 / Ограничения
- Скорость против реалистичности. Ответ зависел от нескольких AI-агентов, но разговор, который буксует, перестаёт быть разговором.
- Потребительский масштаб. Продукт планировали на потенциально очень большую аудиторию, а значит, стоимость инфраструктуры в расчёте на пользователя важна с самого начала.
- Не один продукт. Платформа задумывалась так, чтобы позже разместить в ней и другие приложения с AI-взаимодействием, поэтому ранние решения должны были это выдержать.
03 / Решения
Go на бэкенде — выбор по результатам PoC
Язык бэкенда выбрали после нескольких PoC, а не по личным предпочтениям. Критерии: масштабируемость, поддерживаемость, скорость и то, насколько хорошо код будет работать с AI-ассистированной разработкой. Go дал лучший баланс по этим четырём. Остальные части стека выбирали так же.
Keycloak вместо управляемого сервиса идентификации
Управляемые сервисы идентификации — Amazon Cognito, Auth0 — тарифицируются по числу пользователей. Для потребительского продукта, рассчитанного на очень большую аудиторию, такая модель превратилась бы в крупную статью расходов. У Keycloak платы за пользователя нет. Принятый компромисс: сервер идентификации становится частью системы, которую эксплуатирует команда, а не покупным сервисом.
Единый вход для платформы, а не для приложения
Keycloak работал на отдельном домене, а не внутри приложения. Он задумывался как единая точка входа для всей платформы — семейства приложений с AI-взаимодействием, с одним входом и одной базой данных. На этом проекте более широкая платформа оставалась проектным замыслом, а не работающей системой.
04 / Система
Запрос проходит через четыре уровня, показанных на схеме выше:
- Веб-клиент на React, TypeScript и Vite; TanStack отвечает за загрузку данных и состояние.
- Keycloak на отдельном домене — аутентификация и авторизация.
- API на Go, на AWS Lambda и API Gateway.
- PostgreSQL как хранилище данных.
Инфраструктуру AWS описали в Terraform, и среды разработки и проверки стали воспроизводимыми, а не собранными вручную.
На клиенте я сделал интерфейс чата, экраны прогресса игры и логику состояния, которая синхронизирует разговор со сценарием. На сервере Go-API отвечал за хранение истории чата, управление сессиями и вызовы, которые порождают ответ AI.
05 / Диалог с AI
Разговор и есть продукт, поэтому сторона AI была задачей проектирования, а не интеграции. Моя часть — форма диалога: я проектировал работу чата вокруг того, на что в модели можно положиться, и занимался промпт-инжинирингом, который удерживает персонажа в роли — способным отказать и при этом отвечающим достаточно быстро, чтобы это было похоже на разговор с человеком.
06 / Процесс работы
Как Project Lead я отвечал за планирование, технические решения, код-ревью, инженерные стандарты, выбор технологий и релизы. Работа шла спринтами: планирование и управление задачами — вместе с собственной разработкой.
Результаты продукта принадлежат всей кросс-функциональной команде; статус релиза и итоги здесь не раскрываются.
07 / Ретроспектива
Сегодня я бы с самого начала стандартизировал командный процесс AI-ассистированной разработки. Без общего процесса результат часто не совпадал с общими ожиданиями команды, его приходилось переделывать, и это снижало общее качество. Решение по Go учитывало AI-ассистированную разработку — процесс вокруг неё требовал такой же осознанной проработки.