ПроектыP02

Игровая платформа AI-чатов

Разработка 0→1 игровой B2C-платформы AI-чатов; я вёл её как Project Lead и full-stack инженер в кросс-функциональной команде из 20 человек.

Роль
Project Lead / Full-Stack Engineer
Организация
Ikigai Co., Ltd.
Период
2025/07–2026/0511 мес.
Статус
Завершён
  1. L1Клиент

    • React
    • TypeScript
    • Vite
    • TanStack
  2. L2Идентификация · отдельный домен

    • Keycloak
  3. L3API и вычисления

    • API Gateway
    • Lambda
    • Go
  4. L4Данные · общие

    • PostgreSQL
  5. L5Инфраструктура как код

    • Terraform
Путь запроса сверху вниз. Вход в систему идёт через сервер Keycloak на отдельном домене — он задумывался как общая точка входа для планировавшегося семейства приложений. Упрощённая реконструкция, а не продакшен-схема архитектуры.

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 / Система

Запрос проходит через четыре уровня, показанных на схеме выше:

  1. Веб-клиент на React, TypeScript и Vite; TanStack отвечает за загрузку данных и состояние.
  2. Keycloak на отдельном домене — аутентификация и авторизация.
  3. API на Go, на AWS Lambda и API Gateway.
  4. PostgreSQL как хранилище данных.

Инфраструктуру AWS описали в Terraform, и среды разработки и проверки стали воспроизводимыми, а не собранными вручную.

На клиенте я сделал интерфейс чата, экраны прогресса игры и логику состояния, которая синхронизирует разговор со сценарием. На сервере Go-API отвечал за хранение истории чата, управление сессиями и вызовы, которые порождают ответ AI.

05 / Диалог с AI

Разговор и есть продукт, поэтому сторона AI была задачей проектирования, а не интеграции. Моя часть — форма диалога: я проектировал работу чата вокруг того, на что в модели можно положиться, и занимался промпт-инжинирингом, который удерживает персонажа в роли — способным отказать и при этом отвечающим достаточно быстро, чтобы это было похоже на разговор с человеком.

06 / Процесс работы

Как Project Lead я отвечал за планирование, технические решения, код-ревью, инженерные стандарты, выбор технологий и релизы. Работа шла спринтами: планирование и управление задачами — вместе с собственной разработкой.

Результаты продукта принадлежат всей кросс-функциональной команде; статус релиза и итоги здесь не раскрываются.

07 / Ретроспектива

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