Як ми провели внутрішній AI-хакатон

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Привіт, спільното. Мене звати Ігор, я Director of Engineering у VITech.

Минулого року наш підрозділ Research and Innovation взявся за задачу, яка, думаю, актуальна для багатьох читачів: як зробити так, щоб AI не залишався на рівні теорії і розмов на all-hands, а почав реально використовуватись на проєктах.

Ми розуміли, що проблема не в нестачі знань. Наші колеги використовували AI-інструменти в роботі, але точково і обережно. Проблема була в середовищі: в аутсорсі немає багато можливостей для експериментів, бо є клієнт, є дедлайн, є відповідальність. І коли ти не впевнений у результаті, то безпечніше йти перевіреним шляхом.

Так у нас з’явилась ідея внутрішнього хакатону AI Innovation Summit. За два тижні 48 інженерів об’єдналися в 16 команд і побудували власні AI-рішення з нуля. Частина з них дійшла до реальних клієнтських проєктів. Звучить як success story, але не все було так просто.

Розповідаю, що з цього реально спрацювало, що ні. І що варто врахувати, якщо робити щось подібне.

Передісторія

У Q1 2025 ми запустили підрозділ Research and Innovation, до якого увійшли CTO, CDO, Head of Architecture і я. Ми одразу взялись за інтеграцію AI у щоденну роботу команд.

Почали з навчання: Machine Learning, Deep Learning, LLM. Потім поступово перейшли до більш прикладних речей: prompt engineering, agentic-підходи, робота з фреймворками на кшталт LangChain і LangGraph (prompt engineering, до речі, встигли назвати «новою професією», а він уже майже зник з радарів 😀 ось наскільки швидко все змінюється!).

Досить швидко стало зрозуміло, що цього недостатньо, бо командам бракує практики. Крім того, клієнти все частіше питали про AI, але майже ніхто не був готовий тестувати нові підходи на живих проєктах.

Саме тоді і з’явилась ідея внутрішнього хакатону. І оскільки це був перший подібний досвід для компанії, сумнівів було достатньо.

Від ідеї до реальності

У сервісній компанії не можна просто зупинити роботу на кілька днів, тому формат довелось будувати з нуля та доопрацьовувати його по ходу.

Ми не хотіли обмежувати команди в ідеях, тому задали лише напрям ідей через два треки на вибір:

• Трек A: рішення для клієнтських проєктів: проблеми, які давно хотілося спробувати вирішити
• Трек B: внутрішні інструменти для покращення процесів компанії

Спочатку планували формат на два тижні: цього достатньо, щоб зробити MVP, але недостатньо, щоб вигоріти. Але не все пішло за планом 😀

Хакатон розтягнувся удвічі довше, ніж ми планували. Виявилось, що синхронізувати 48 людей з різних проєктів — це непросто, тому дати прийшлось переносити не один раз.

З одного боку, це дало результат. За чотири тижні команди зробили значно більше, ніж MVP — частина рішень виглядала майже як production-ready. Але водночас це було занадто довго для хакатону. Під кінець замість спринту вийшов марафон поверх основної роботи.

У цьому році ми повернулись до двох тижнів, бо краще менший скоуп у нормальному темпі, ніж амбітніший, але з ризиком вигорання для команди.

Що ми недооцінили на старті

Окрім формату і тривалості, у першому хакатоні вилізло ще кілька моментів, які ми просто не передбачили.

Комунікація

Ми створили окремий Slack-канал і вважали, що цього буде достатньо. Частина команд активно ним користувалась: задавали питання, ділились прогресом, просили фідбек.

Але все ж кілька команд фактично працювали ізольовано. Ми побачили їхні ідеї тільки на демо (та іноді вже тоді, коли щось змінювати було пізно).

Зараз я вже розумію, що нам не вистачило нормального kick-off’у і хоча б одного проміжного sync-up’у, де можна було б помітити проблему раніше.

Менторство

Ми закладали, що ментори — це скоріше підтримка, ніж обов’язкова частина процесу. Але на практиці виявилось, що деякі команди пішли у напрямку, який не зовсім відповідав критеріям або не вирішував конкретну бізнес-задачу. Ментори могли б скоригувати це ще на першому тижні, але ми не зробили це системною частиною формату.

Критерії оцінювання

На старті для нас було важливо задати прозорі правила. Ми окреслили основні критерії, щоб команди розуміли: переможців обирають не за принципом «кому пощастило більше» і не за красиве демо.

Ми орієнтувались на такі критерії:

• innovation & creativity (30%): наскільки нестандартний підхід обрала команда (при тому що AI має бути в ядрі рішення, а не приклеєний зверху). Оцінюємо і свіжість ідеї, і глибину використання AI: чи команда переосмислила процес, чи просто додала ще один feature.
• business impact (30%): чи може рішення реально покращити клієнтський продукт або внутрішній процес, а не залишитись ефектною демкою. Команда має показати, де воно даватиме вимірюваний результат і що з цим робити далі.
• technical execution (20%): рішення має запускатись і робити те, що показано на демо. POC або MVP — ок, production-ready рівня не очікуємо. Але це має бути живий код, а не моки для демо.
• якість демо і презентації (20%): наскільки чітко і захопливо команда пояснила проблему, рішення і його потенційний вплив. За п’ять хвилин у суддів і аудиторії має складатись зрозуміла картина: яку проблему вирішували, як саме AI допомагає, і чому це варто розвивати далі. Сильне рішення без зрозумілого пояснення — це втрачена можливість.

Проблема в тому, що деталі і баланс між цими критеріями ми уточнювали вже по ходу. Через це частині команд було не до кінця зрозуміло, що інноваційність і бізнес-вплив важать більше за красиве демо.

У підсумку перемогли правильні рішення. Але якби критерії були повністю зафіксовані з першого дня, це дало б командам чіткіший орієнтир.

Результати

Тепер до найцікавішого. Ми отримали шістнадцять рішень від шістнадцяти команд. Опишу три, які вже зараз у проді. Без клієнтських назв (NDA), але з технічними деталями, які мають значення.

1. Clinical Protocol Assistant

Один із найсильніших кейсів — це інструмент для роботи з клінічними протоколами. Команда сфокусувалась на задачі, яка напряму впливає на швидкість запуску досліджень і кількість помилок.

Проблема. Клінічні протоколи — це складні документи на сотні сторінок із десятками сценаріїв, форм і даних. Їх підготовка в клієнтському healthcare-продукті займає 4–5 повних робочих днів одного фахівця. При цьому будь-яка помилка може призвести до protocol amendment: додаткових перевірок, переузгоджень і затримки дослідження.

Рішення команди. Команда побудувала pipeline, який приймає PDF протоколу, розбирає його і генерує структуровану конфігурацію для клієнтського продукту з можливістю перегляду і редагування.

У технічній частині використали LangChain і LangGraph для оркестрації, моделі Claude через AWS Bedrock. Цікаво, що команда свідомо відмовилась від RAG. Пояснення тех-ліда: для RAG треба знати, що саме шукаєш, а при обробці протоколу ти наперед не знаєш, які сторінки містять ключову інформацію. Замість цього вони паралельно генерують summary для кожної сторінки, а потім поступово будують структуру протоколу.

Результат. Час підготовки протоколів скоротився з кількох днів до хвилин. Після хакатону ми презентували рішення клієнту і зараз рухаємось в сторону production як частина реального продукту.

2. Clinical Assistant Chat

Проблема. Інший healthcare-клієнт працює з великим обсягом клінічних метрик якості. Дані є, але UI для їх дослідження обмежений — користувач може застосувати фільтри, подивитись таблицю, але не може задати питання типу «які пацієнти потребують втручання найбільше за кількома метриками одночасно».

Рішення команди. Команда побудувала чат-інтерфейс поверх існуючих даних: користувач формулює запит природною мовою, модель генерує SQL-запит, отримує дані і повертає відповідь з поясненням.

У технічній частині використали Python (FastAPI), Postgres, Claude через AWS Bedrock і LangChain для оркестрації. Реалізували streaming відповідей у реальному часі і збереження чатів у БД з можливістю вести кілька діалогів паралельно.

Окремо продумали прозорість: для технічних користувачів показують згенерований SQL, для бізнес-користувачів — пояснення природною мовою.

Команда додала автотести на промпти, що дозволило безпечно ітеративно покращувати якість відповідей.

Результат. Рішення інтегроване в клієнтське середовище і використовується на практиці.

3. Patient-facing Knowledge Chatbot

Проблема. У клієнта великий обсяг контенту для кінцевих користувачів — статті, документи, пояснення процесів. Користувачам було складно знайти конкретні відповіді: доводилось або довго читати, або звертатись у support.

Рішення команди. Команда побудувала RAG-based чат-бот, інтегрований у продукт клієнта, який дозволяє знаходити відповіді через natural language.

У технічній частині вони підійшли системно: побудували власний evaluation framework з двома підходами — keyword matching і LLM-as-judge, протестували кілька моделей (зокрема Mistral і Gemini) і обрали оптимальний варіант за співвідношенням cost vs quality. Також передбачили автоматичне оновлення embeddings при зміні контенту в CMS.

Результат. Клієнт погодився на імплементацію одразу після демо. Рішення було доведене до production за тижні, а не місяці.

Як AI змінює швидкість розробки

Один із найцікавіших моментів стався не під час презентації демо, а на Q&A сесії після неї. Команда з двох інженерів показала застосунок, який за два тижні виріс у продукт із десятком фіч: time logging, planning poker з AI-ботом, семантичний пошук по тікетах, профілі співробітників, гейміфікація, система компенсацій. У клієнтському проєкті така розробка зазвичай займає кілька місяців роботи.

Одразу прилетіло питання, як їм це вдалось. Власне, секрет полягав у тому, що частину коду команда писала через AI-асистентів. Так, це ще не production-ready рівень, бо потрібен рефакторинг і немає всіх процесів, але на структуру і робочу логіку пішло всього кілька тижнів.

Це добре підсвічує головну зміну — роль і можливості інженера кардинально змінились. Складнощі зараз виникають не на етапі написання коду, а під час формулювання задач, якості вимог і прийняття рішень.

Власне саме тому формати хакатонів зараз особливо цінні, бо дозволяють побачити цю зміну без зайвого тертя і змушують переосмислити, де engineering team насправді створює цінність.

Що не спрацювало

Не всі 16 команд дійшли до прод-розмови. Частина рішень залишилась на рівні MVP (що нормально!).

Крім того був ще пост-хакатонний процес. Частина команд після демо залишилась у підвішеному стані, бо не знали, що робити далі. Найкращі рішення ми підхопили, найслабші свідомо залишили, але між ними був ще шар проєктів, для яких ми не одразу визначили подальший шлях. Це демотивувало.

У цьому році ми це виправили і прописали follow-up як окремий процес.

Висновки

Головне, що змінилось — команди перестали боятись експериментувати з AI. Не тому, що стало менше ризиків, а тому що з’явився простір, де ці ризики не є критичні.

Ідеї з хакатону перейшли в реальні проєкти. У деяких кейсах шлях від ідеї до production зайняв не місяці, а тижні. І важливо, що клієнти самі підхоплювали такі рішення, коли бачили конкретну бізнес-цінність.

Але це не сталося випадково. Я для себе зафіксував три речі, без яких нічого б не спрацювало:

Середовище. У хакатоні зникає головний бар’єр — страх зламати щось у проді. Нам вдалось створити простір, де можна пробувати нові підходи і помилятись без наслідків для клієнтських проєктів. Саме це і дало людям можливість експериментувати на повну і братись за ідеї, до яких не доходили руки.

Культура. Ми довго будували культуру навчання і безперервного розвитку всередині компанії: внутрішні лекції, вебінари, knowledge-sharing канали. Тому хакатон не виник нізвідки, він став логічним продовженням цього підходу. Підозрюю, саме тому нам не довелось вигадувати, як мотивувати людей реєструватись на таку тривалу позаробочу активність. Всім було просто цікаво спробувати.

Залучення менеджменту. C-level не просто підтримали ініціативу, а реально включились: дали ресурси, брали участь у рев’ю і фідбеках. Це задало правильний сигнал командам. Всі відчували, що це щось масштабне.

І ще один важливий момент. Коли ти знаєш, що працюєш не над демо, а над тим, що може реально поїхати в прод, мотивація зовсім інша.

Що змінюємо у 2026

Прямо зараз триває другий AI Innovation Summit.

Ми повернулись до двох тижнів замість чотирьох, зафіксували критерії оцінювання ще на етапі анонсу і додали обов’язкові sync-up’и в процесі. Post-hackathon follow-up тепер також прописаний як окремий етап. Цього разу я сам підключився до всіх команд, підтримую і регулярно допомагаю з питаннями, якщо це потрібно.

Окремий фокус цього року — автоматизація внутрішніх процесів через AI-coding інструменти. Це пряме продовження тих кейсів, які ми побачили у першому хакатоні.

Зареєструвались 14 команд, а призовий фонд складає $6,500.

Якщо ви запускаєте щось подібне у своїй компанії, буду радий обмінятись досвідом, пишіть у коментарях або мені в LinkedIn. І буду вдячний за критику та поради, адже перший раз ми точно зробили не все ідеально, і другий теж навряд вийде без нових помилок.

Але саме в цьому процесі і з’являється справжня цінність.