Мы строим покерную платформу, и ИИ только что попытался задеплоить нашу инфраструктуру
Строить покерную платформу с нуля — это носить одновременно очень много шляп. В любой отдельно взятый день я думаю про игровую логику, требования комплаенса, пользовательский опыт, финансовые потоки и ещё примерно сотню вещей, не связанных друг с другом. ИИ стал настоящим спасением, чтобы удерживать всё это в голове.
А ещё он только что попытался задеплоить нашу инфраструктуру в ответ на просьбу написать абзац.
Вводная
Покерная платформа работает поверх подробной технической спецификации — живого документа, покрывающего всё: как устроен карточный движок, как ledger отслеживает средства игроков, как geofencing обеспечивает игру только в Техасе, как каждое заведение получает свой white-label-опыт. Это фундамент, из которого всё растёт.
Когда пришло время формализовать наш подход к Terraform как infrastructure-as-code, я хотел задокументировать стратегию в спецификации. Какие паттерны мы будем использовать, как структурировать деплои в Azure, общую философию. Один раздел. Несколько абзацев.
Я попросил ИИ это добавить.
Вместо этого ИИ добавил полную, запускаемую реализацию Terraform.
Клёвый код, не тот результат
Модули. Файлы с переменными. Определения ресурсов. Полностью каркасированный IaC-проект — засунутый внутрь markdown-документа со спецификацией.
А самое главное? Код был реально хорош. Крепкая структура модулей, чистая организация ресурсов, разумные имена переменных. Если бы я попросил его построить Terraform-сетап, это было бы сильной стартовой точкой.
Но я попросил его описать стратегию, а не исполнить её. Между "задокументируй, как мы собираемся использовать Terraform" и "вот тебе Terraform" есть содержательная разница. Человек бы это поймал. ИИ уверенно не поймал.
Почему именно для покерной платформы это важно
В покерной платформе много движущихся частей, которые должны быть правильными — не примерно правильными, не правильными по направлению, а ровно правильными. Состояние игры, записи ledger'а, правила комплаенса, логика geofence'а. Спецификация — это контракт между дизайном и реализацией. Когда в неё что-то добавляется, это должно быть сделано сознательно.
ИИ, который услужливо генерирует код и втыкает его в документ спецификации без просьбы, не просто выполняет лишнюю работу — он потенциально портит источник истины, на который опирается всё, что ниже по течению. В такой чувствительной кодовой базе радиус поражения неправильно понятой инструкции имеет значение.
Конкретный инцидент был с низкой ценой ошибки и легко поправился. Но это хорошая иллюстрация к тому, что стоит держать в голове, пока мы строим: ИИ исполняет уверенно и почти никогда не задаёт вопросов. Человек в петле нужен, чтобы покрывать зазор между тем, что было сказано, и тем, что имелось в виду.
Исправление и урок
Тридцать секунд, чтобы удалить сгенерированный код. Ещё тридцать, чтобы переписать промпт с явными ограничениями: "только проза, никаких блоков кода, опиши стратегию." Со второго раза получил ровно то, что хотел.
Практический вывод: когда просите ИИ делать документацию или работу по спецификации, относитесь к этому как к написанию инструкций для того, кто выполнит ровно то, что вы скажете, и щедро интерпретирует любую двусмысленность как разрешение сделать больше. Потому что именно это он и делает.
Явно задавайте формат. "Добавь раздел про X" — двусмысленно. "Добавь раздел в виде прозы, без кода, описывающий наш подход к X" — уже нет.
Ожидайте, что он переделает в неправильную сторону. ИИ склоняется к тому, чтобы делать больше, а не меньше. Когда задача сама по себе аддитивная (например, обновить спецификацию), этому инстинкту нужны ограничители.
Читайте перед тем, как коммитить. Это очевидно, и при этом почему-то — самый часто пропускаемый шаг.
Мы строим эту платформу публично — победы, странные развороты и моменты, когда инструменты делают что-то неожиданно смешное. Это был один из таких моментов.
ИИ потрясающ для такого проекта. Иногда, впрочем, он чуть слишком рвётся помогать.
Глубже про agentic AI, spec-driven development и про то, каково это на самом деле — использовать ИИ для построения прод-систем, я пишу на The Salty Korean — методология за покером, без самого покера.
Платформа движется вперёд. Скоро будет ещё.
Stay salty.
The Salty Korean
Основатель Salty Poker Network. Пишет о техасском покере, создании платформ и будущем онлайн-покера. Подробнее на The Salty Korean.