Мы построили salty.poker с помощью ИИ. Вот та часть, которую никто не увидел.

Двадцать две сессии за десять дней.

Каждая сессия: агент Claude Code работает по 100-страничной спецификации — читает текущее состояние кодовой базы, берёт назначенный модуль спецификации, пишет код, подключает сервисы, запускает миграции, делает коммиты. Без митингов по оценке. Без обсуждений объёма. Без тикетов Jira в переговорках.

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

Журнал изменений охватывает то, что было выпущено. Этот пост — о том, что произошло потом.

Что Реально Происходит После Написания Кода

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

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

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

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

Ни один из этих багов не был написан человеком. ИИ-сессия написала представление стола. ИИ-сессия написала лобби. Это всё равно были баги. Их всё равно нужно было найти, отследить до первопричины и исправить.

Почему Это Всё Равно Лучший Путь

Перед историей о том, как-это-сломалось: сам факт того, что мы находимся в фазе сквозного тестирования за десять дней, и есть история.

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

Мы сократили этот разрыв за десять дней. Фаза тестирования — это сложная часть. Мы в ней.

Что Дальше в Этой Серии

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

Подробнее о методологии я пишу на The Salty Korean.

Stay salty.