AI-хакатон в GlowByte:
как мы решали задачи для вымышленной розничной сети «МегаБайт»

У нас на старте было 28 команд, как я уже отметила выше, но устояли в гонке только три — семь человек суммарно. Ни одна из команд-участниц не была «командой разработки» в привычном смысле: людей собирал не отдел, а интерес к задаче.

• Первая команда (Hallucination Station) — трое: маркетолог, ведущий бизнес-аналитик и бизнес-аналитик. Двое каждый день разбирали требования и данные, третий объяснял цифры бизнесу. Победитель хакатона (13 177 баллов).

• Вторая команда (EDA) — трое: администратор проектов, BI-консультант и руководитель отдела поддержки и обучения. Состав максимально далёкий от стереотипа «хакатон для дата-инженеров». Он и взял серебро (13 100 баллов).

• Третья команда (Me, Myself and AI) — соло-участница из отдела маркетинга. Один человек против двух команд, полный комплект DWH-артефактов и третье место (12 505 баллов). Название команды, как видите, говорящее.

Дальше по тексту мы называем их первой, второй и третьей — по местам в итоговой таблице.

Баллы – это не абстрактная «оценка жюри», а накопительная сумма за четыре недели. Механика такая:

● Каждое задание оценивает AI-судья по трём критериям: работа с промптом, техническая часть и бизнес-составляющая. Жюри может скорректировать итог вручную, тогда участнику приходит отдельное уведомление.

● У каждой недели свой потолок за одно задание: 200 баллов на первой неделе, 300 – на второй, 400 – на третьей и 500 – на четвёртой. Задания от недели к неделе усложняются, поэтому и стоят дороже.

● На каждое задание даётся три попытки, но в зачёт идёт только лучшая. Баллы попыток не суммируются.

● Есть два бонуса, оба работают только на первой зачтённой попытке. За скорость: если вы сдали задание раньше других команд, к итогу добавляется от 10% до 30% в зависимости от того, сколько команд успело до вас. И плюс 15% за «не своё задание», если в команде нет ни одной роли из тех, на кого задание рассчитано. Бонусы складываются: маркетолог, первым сдавший задание для дата-инженера, получал 45% сверху.

● Отдельно идут баллы за пятничные вебинары: от 100 за выступление на открытии сезона до 500 за последнюю пятницу. В потолок за задания они не входят, а прибавляются к строке команды в таблице лидеров.

Отсюда и порядок чисел. 13 177 баллов у победителя – это не один блестящий артефакт, а сумма десятков оценок за четыре недели плюс бонусы за скорость и вебинары. Отсюда же понятно, насколько тесным был финиш: 77 баллов разницы между первым и вторым местом – это меньше половины стоимости одного задания самой лёгкой, первой недели.

Ещё одно следствие правил стоит держать в голове: бонус «не своё задание» прямо поощряет вылезать из своей роли. Поэтому в финале и оказались маркетологи с администратором проектов, а не только аналитики.

По пятницам участники по желанию вели вебинары: рассказывали коллегам, как именно они применяют ИИ в работе. Темы говорящие: «Не Клодом единым. Собираем свой AI-стек», «Вайбкодинг. От создания „1 session product“ к управляемой последовательной разработке сложного продукта», «Личный AI-ассистент 24/7: промты, которые реально меняют жизнь» и "Рай для интроверта: как Claude AI разгрузил мой Telegram".

В основе сезона лежит принцип, который мы формулируем так: ИИ ускоряет сбор черновика, накидывание структуры и проверку формулировок, но не превращается в специалиста, который подписывается под результатом перед клиентом. Финальная ответственность и сложные решения остаются за человеком. Поэтому участники вели «паспорт делегирования»: что отдали ИИ, что поправили руками и почему, какой получился итог.

Хакатон построили вокруг одного кейса. Вымышленной розничной сети «МегаБайт» нужны DWH и BI-слой поверх него, на масштабе сотен магазинов и миллионов заказов. Все получили одну и ту же задачу и сдали полный комплект наработок: от dbt-моделей и Airflow-пайплайнов до дашбордов и документов передачи. Каждая команда защитила решение на вебинаре.

Общий зачёт получился плотным. Первая команда набрала 13 177 баллов. Вторая шла по пятам и с разрывом всего в 77 баллов взяла серебро — 13 100. Бронзу отдали за 12 505 баллов. Дальше разберём, в чём конкретно сила каждого решения: жюри подробно расписало все три работы, и там есть что забрать в свою практику.

Первое место (Hallucination Station): рабочая система, а не комплект документов

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

Забрали себе в работу:

• Стенд, который запускается одной командой. База, планировщик, модели и проверки качества собраны в одном docker compose, с одной командой верификации. Отличный шаблон для пилотов и демо заказчику.

• Трёхслойный контроль качества. Тесты в моделях данных, автоматические проверки в YAML и SQL-сверка источника с витриной. В проде так и должно быть: не один инструмент контроля, а несколько линий обороны.

• Набор регрессионных тестов. Эталонные кейсы с типами ошибок: дубли, потеря строк, неверная формула. Полезно при смене разработчика или миграции SQL.

• Сверку, которая учитывает пограничные случаи бизнеса. Магазины с нулевой выручкой не выпадают из сверки. Редкая, но важная деталь для розницы.

• Инструкции для дежурного. Что делать при сбое и когда запускать полный пересчёт. Шаблон для любого расчёта, который идёт по расписанию без присмотра.

• Стек: PostgreSQL, Docker, Apache Airflow, dbt с dbt_utils, Soda Core, Chart. js, Python, Lightdash как BI поверх dbt, Wren AI для вопросов на русском с переводом в SQL, MinIO, Qdrant.

Второе место (EDA): прозрачность и проверяемость как продукт

Команда присудили серебро за прозрачность и проверяемость решения. У каждого артефакта прослеживается цепочка: что требовалось, что сделала нейросеть, что поправили и почему, как это доказать. К этому добавилась зрелая подготовка к запуску: команда заранее продумала, кому что сказать и каким документом.

Что из их подхода коллеги из GlowByte забрали в свою практику:

• Любой артефакт можно размотать назад до исходного промпта. На каждую задачу заводится папка с промптами и два файла: чем подтверждается приёмка и как воспроизвести запуск. Благодаря этому жюри, аудитор или новый человек в команде может разобраться в решении сам, без созвона. Хороший стандарт для любой разработки с участием ИИ.

• Проверяющие скрипты на Python. Один проверяет структуру артефактов, второй корректность расчётов, третий убеждается, что код реально запускается. Готовый чек-лист для автоматической сборки в любом BI-проекте.

• SETUP. md как пошаговую инструкцию. «Как проверить решение с нуля за 10 минут». Удобный шаблон для введения в проект нового ревьюера или заказчика.

• Отчёт не уходит руководству без визы аналитика. Публикация в пайплайне физически заблокирована, пока человек не подтвердил данные. Ответственность закреплена за человеком, а не за расписанием. Модель рабочая, переносится в продакшен без переделки.

• Готовый план, кому и что сказать на запуске. Список заинтересованных сторон, расписание сообщений на три дня до, день до и два дня после, шаблоны писем, ответы на частые вопросы. Каркас, по которому можно выводить любой BI-продукт внутри компании.

• Карту потребления и руководство пользователя. Кто смотрит какую метрику и что делать при «красном» статусе. Применимо в любом проекте, где у данных несколько ролей-потребителей.

Стек у команды открытый: PostgreSQL, Docker, Python (PyYAML, Pillow, openpyxl, python-pptx), dbt с dbt_utils, Apache Airflow, Soda Core, HTML/CSS для портала и BI-прототипов. Отдельно отметили генерацию артефактов из кода: Excel с инцидентами, PNG-макет дашборда и PPTX-презентация собираются не руками, а воспроизводимым пайплайном.

Третье место (Me, Myself and AI): продуктовая упаковка и честные цифры

Третье место соло-участница взяла за упаковку продукта: понятные документы для заказчика и верная бизнес-логика в расчётах. Лендинг и главный экран дашборда получились самыми продуктовыми среди трёх решений, а документы написаны так, что разработчик может начать работу без десятка уточняющих вопросов.

Что забираем себе в практику GlowByte:

• Документ передачи. Источники данных, правила расчёта, DDL, проверки, риски интерпретации. Шаблон, по которому консультант передаёт витрину команде заказчика.

• Финансовую логика в сверке. Валовая и чистая выручка явно разделены, без «красивых, но ложных» цифр в отчётности. Это правило мы в GlowByte можем переносить в любой розничный DWH без исключений.

• Schema. yml как договор между DWH и BI. Не только dbt-тесты, но и метаданные для BI-инструмента: названия полей, форматы, владелец метрики. Снижает трение на стыке двух команд.

• Проверки данных по уровням важности. Разделены на блокирующие и предупреждающие, отдельно проверяется консистентность среднего чека. Практичная и не избыточная модель для продакшена.

• Разбор после генерации. README с перечислением конкретных ошибок нейросети и того, как их исправили. По сути стандарт код-ревью после генерации кода, которого многим командам не хватает.

Стек: PostgreSQL, Docker, dbt-core, Apache Airflow, Soda Core, Python, HTML/CSS. Отдельная находка: production-shaped DAG, где публикация блокируется при ошибке сверки, есть SLA-callback для COO и экспоненциальный backoff. Паттерны, которые переносятся в прод без адаптации.

В конце сезона все три команды вышли с отдельной презентацией: показали подход к решению кейса и поделились впечатлениями о хакатоне. Параллельно с зачётом жюри шло народное голосование в библиотеке решений. Лидером стала первая команда с 537 лайками, у второй 409, дальше отрыв резко растёт: у третьего места в голосовании всего 78.

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

Главный вывод по следам ИИ-хакатона в GlowByte: AI-ассистированная разработка работает хорошо тогда, когда у неё есть проверяемый след. Не «нейросеть написала dbt-модель», а конкретная цепочка из промпта, артефакта, человеческой правки и обоснования.

Показательно, что призовые места взяли не те, кто меньше пользовался ИИ. Разница была в другом: победители писали решение так, будто завтра уходят в отпуск, а разбираться с ним будет посторонний человек и звонить с вопросами ему будет некому.

Сеть «МегаБайт» вымышленная, а задача настоящая, и в проектах она выглядит примерно так же. У нас есть отдельное направление AI-консалтинга для DWH и BI: помогаем встроить генерацию кода и документов в пайплайн так, чтобы не потерять контроль над качеством и ответственностью.

Если у вас похожий сюжет, от выбора стека до выстраивания прослеживаемости внутри команды, напишите нам напрямую на bi@glowbyteconsulting.com.