Привет, Хабр! Это Александра Павлова, деврел Friflex. В этой статье расскажу про наш недавний эксперимент — хакатон по вайб-кодингу.
Если коротко: вместе с Институтом №8 МАИ мы собрали 14 команд студентов IT-специальностей, дали им один вечер, минимум ограничений, максимум генеративных ИИ — и предложили придумать и реализовать мини-игру для страховой компании ЭНЕРГОГАРАНТ. Мы назвали это гордым словом «Вайбатон» (ну вы поняли: вайб + хакатон), потому что вайб-кодинг и правда был, но была еще и проверка кода экспертами жюри.
То есть это был эксперимент в программировании с ИИ, где важнее всего быстрая реализация идеи. Мы хотели проверить, на что способен такой подход — и какие ограничения у него есть.
Эта статья — для тех, кто интересуется:
как использовать ИИ-инструменты в разработке без формального бэклога,
как организовать быстрый формат для генерации нестандартных продуктовых идей,
как инженерные команды работают, когда им дают много свободы, задачу от клиента и три часа времени.
Задача: геймификация для приложения страховой компании
Придумать механику мини-игры для мобильного приложения страховой компании ЭНЕРГОГАРАНТ. Ее выбор должен был быть обоснован предпочтениями возможной аудитории страхового приложения.
Определить мотивацию пользователя: бонусы, баллы лояльности, розыгрыш страховки.
Реализовать это в виде прототипа — с помощью ИИ. Команды могли использовать любые языки, а для работы с ИИ у них был доступ к OpenRouter. Также можно было использовать ChatGPT, Copilot, Cursor и любые другие инструменты. Все, что поможет быстро превратить идею в понятный интерактивный результат.
За 3 часа собрать MVP и презентовать его жюри.
Решения оценивали продуктовые и технические специалисты из Friflex, МАИ, X5 Group, Avito, Дикси и Самоката и других компаний – в сумме 12 человек. Формально мы оценивали по четырем критериям — и каждый из них требовал баланса между идеей и реализацией:
Техническая реализация — эксперты оценивали архитектуру решения, обращали внимание, чтобы код был логично структурирован, легко расширяем. Было важным плюсом, если документация понятная и позволяет другим разработчикам быстро разобраться в проекте.
Оригинальность идеи — свежесть концепта, неожиданное решение, нестандартный подход к игровому сценарию или механике.
Соответствие и применимость — попадает ли идея в контекст задачи? Понятно ли, как это можно внедрить в реальный продукт? Это — мост между фантазией и бизнесом. Если да — хорошо.
Презентация — кому удалось уложить идею в короткий и понятный сторителлинг, быть убедительным и показать сильные стороны своего решения, тот получал плюс.
Каждый критерий имел вес в общем подсчете, наибольший коэффицент — у технической реализаций, второй за ним — у оригинальности идеи.
«Чтобы оценка технической реализации была не только строгой, но и в духе нашего Вайбатона, мы подключили секретное оружие — утилиту оценки качества кода, созданную специально под мероприятие. Этот ИИ-сервис, можно сказать, сам родился в вайб-кодинге: его писали в темпе эксперимента, буквально накануне, с верой в ИИ и легким волнением — а вдруг не заработает? Но он заработал: анализировал код команд по пяти критериям (конечно же, выбранными ИИ), не споткнулся ни на одном репозитории и стал настоящим цифровым гуру в составе жюри. Его оценка учитывалась наряду с оценками экспертов-людей. Участники, погруженные в процесс, даже не подозревали, что их код будет проходить такой ИИ-скрининг. Это позволило нам, жюри, немного «повайбить» самим, доверившись технологиям, и добавило объективности в оценку», — Александр Федотов, технический координатор хакатона.
Белка-кликер, страховой тамагочи, катастрофический остров: идеи и реализация
Несмотря на общий фрейм (геймификация страховых приложений), подходы команд были совершенно разными. Некоторые — почти корпоративные, другие — с вайбом. Вот несколько концептов, которые удивили:
Белка-кликер (команда Chill Vibe corp.) Игра «Орешек Гарантии»: белка собирает бонусы за осознанное поведение. Ярко, странно, смешно. Механика — клик-квест с элементами юмора и накоплений.
Дом как персонаж (Чуваки). Игра в духе «tower defense»: у дома — 2000 HP, на него нападают пожары, потопы и грабители. Игроку нужно защищать его, чтобы не потерять страховку.
Страховой тамагочи (Neuro&Tochka). Мини-истории, где пользователь ухаживает за объектом страховке, а его преследуют происшествия — от засора в ванной до угона авто.
Катастрофический остров (GPTeam). Симулятор решений в экстренных ситуациях: затопление, пожар, отключение электричества. Игрок выбирает, как действовать, и получает «оценку зрелости».
Большая часть команд принесла какой-то прототип, пусть и на разной стадии готовности.
«Я ожидал каких-то простых решений типа адаптированной змейки или каких-то других головоломок, которые можно было бы довести до рабочего состояния за отведенное время. Но ребята ставили себе более амбициозные цели, что сказалось на законченности проектов, в то же время презентации были на высоте», — Александр Федотов, технический координатор хакатона.
По функциональности был большой разброс, но все проекты требовали дальнейшей доработки. Это понятно, было всего три часа. Несколько примеров, где реализация выделялась:
1. Level Up: Insure (Vibelino Codaratti) — три мини-игры, которые работали. Команда пошла структурным путем. Вместо одной игровой механики представила три мини-игры — раннер, кликер и квиз — и реализовала пять уровней. Каждый из уровней отражает реальные страховые случаи в 2D. Сделали все на фронте: Vite, TypeScript, React, Tailwind, shadcn-ui.
Сценарии довольно универсальные, но за счет того, что получилось все склеить в одну систему, прототип казался даже технически устойчивым. Создать полноценные 3D-игры не удалось, но решение работающее.
2. City Builder (Kis-Kis-Misis) для страхования — SimCity с рефералами и кэшбэком
Команда переосмыслила классическую механику градостроителя (SimCity 2000 / Cities: Skylines) для сценариев страхования. Пользователь получает ежедневные бонусы, тратит их на строительство зданий и открытие новых районов, объекты в городе возвращают кэшбек или выдают задания, реферальная система добавляет социальный рост.
Стек включал cursor, GPT-4.1, Claude Sonnet 4, Docker Compose, nginx, React + Vite, PixiJS, FastAPI, MongoDB. То есть фронт на WebGL-ориентированной библиотеке, бэкенд — на FastAPI, хранение данных в MongoDB; окружение собрано docker-compose’м, поверх nginx. Часть интерфейса и вспомогательный код сгенерированы LLM-ами через Cursor.
3. Risk Rush Deluxe (Code Wings) — раннер про страховые риски. Команда собрала мини-игру на Pygame. Это был раннер, в котором игрок уклоняется от рисков, связанных со страховыми событиями. Простая механика — и неожиданный выбор языка: Python, что нечасто встретишь в игровых прототипах.
«Игра разрабатывалась в двух вариантах. Одна группа писала все с использованием Gemini и claude sonnet (они практически полностью писали код, нашей задачей было только качественно прописать промпты). Вторая группа писала в Cursor с использованием ии-агента и gemini-2,5.pro. Здесь уже разработка велась с структурированием кодовой базы, логичным разделением директорий, но, к сожалению, во время хакатона возникла проблема на стороне cursor — он счел наши действия подозрительными и ограничил возможность дальше писать промпты, поэтому в результате представили одну вариацию игры», — Code Wings.
Что показала практика с ИИ без формального плана
Я думаю, что формат ИИ-кодинга в нашем эксперименте сработал — и сработал очень хорошо для того, что мы хотели проверить: что за три часа реально придумать и реализовать мобильную игру для клиентского приложения. По словам коллег из компании ЭНЕРГОГАРАНТ, хороших идей, которые кажутся перспективными, было много, и из них трудно было выбрать.
Многие вышли за привычные рамки, попробовали разные жанры, технологии и подходы — от градостроителей до раннеров. Плюс порадовали персонажи, например, любимец многих в жюри и мой тоже — Энергокот от команды Duck teaming, который сопровождает пользователя в прохождении игры.
Мы не ждали от формата готовых продуктов. Три часа — это слишком мало. И получили именно рабочие наброски — с минимальной документацией, поверхностной обработкой ошибок и архитектурой на скорую руку.
Что хотелось бы улучшить? Многие участники говорили, что им не хватило времени. Интересно, что бы у них вышло часов за шесть. С другой стороны, ценность такого формата — в скорости эксперимента. А какой минимальный тайм-бокс для прототипа вы считаете рабочим? Приглашаю обсудить в комментариях.