Як заповідав класик — «жить нада інтересно». Особливо в інтересні часи. Особливо коли ШІ безпардонно увірвався до нашої затишної бульбашки й почав погрожувати, що забере в нас роботу. Але якщо не можеш здолати — очолюй. Тож я вирішив першим добровільно віддати йому свою роботу. Ну як віддати — передати звання React-абізяни. Але в процесі так захопився, що незчувся, як створив цілу зграю різноманітних абізян із (майже) чіткими ролями, (майже) визначеними обовʼязками й обмеженнями, здатних (майже) одним порухом вирішувати мої задачі. Про це я й хочу розповісти: як із бажання змусити LLM писати рутинний код зʼявилася ціла команда спеціалізованих агентів, як я будував свій agent harness у Claude Code, що виходило, що не виходило і які обхідні шляхи довелося вигадувати. І, зрештою, чого дресирування ШІ-мавп навчило мене про моделі й промпти, та чому "ну будь лаааасочка" в промпті не гарантуватиме вам хорошого результату.

Якщо в тебе процес розробки виглядає як "я пишу в Claude Code промпт, а далі разом з своїм улюбленим комплектом скілів робимо справу" - то ви застарілі роки на півтора, що в наших ШІ-реаліях - вічність. Зараз в моді графи та self-improving loops - ви пишете задачу - її розбивають на 100500 окремих блоків, кожен з яких простий, дає вимірюваний результат а отже - ним легко керувати і легко покращувати. Виглядає ідеально? Так, доки тебе не втомлює, що проста задача робиться годинки півтори або поки ти не рахуєш скільки це коштує (в грошах чи токенах - неважливо). За останні півроку я побудував 6 подібних фабрик як консалтер - як під копірку за ідеологією - однак тепер з кожним новим клієнтом я починаю довгу розмову, що скоріше за все вам або воно не треба, або треба - але в інший спосіб. Ми зачепимо три аспекти: технологічний, економічний та культурний, щоб пояснити де власне виникають проблеми і чому я більше не вважаю dark software factory у її графово-блоковому вигляді срібною кулею для всіх.

Кілька років тому ми почали будувати Architecture as Code з доволі простою метою: зробити архітектурні знання доступними, актуальними та зрозумілими для інженерів. C4-діаграми, ADR, OpenAPI, ERD, ownership та інша документація поступово переїхали ближче до коду, стали version-controlled і machine-readable. Ми робили це для людей. А потім прийшли AI-агенти. І несподівано виявилося, що один із найскладніших етапів роботи з AI — передача агенту контексту про систему — у нас уже майже вирішений. У цій доповіді поговоримо про те, чому доступу до репозиторію недостатньо, чим code context відрізняється від system context і як практики Architecture as Code природно перетворюються на Context Engineering. На реальних прикладах розберемо, який контекст потрібен AI-агенту, щоб він не просто писав код, а розумів домени, архітектурні рішення, API-контракти, ownership та обмеження системи. А також поговоримо про наступний виклик: як переконатися, що контекст, на який спирається AI, відповідає реальному стану системи.

Створити AI-агента — лише половина задачі. Треба ще зрозуміти, наскільки добре він працює і чи не став гіршим після зміни моделі, запиту, інструментів або даних. У доповіді на практичному прикладі розберемо, як створювати Evals для AI-агентів: формувати тестові сценарії, визначати критерії та метрики якості, використовувати автоматичні перевірки, LLM-as-a-Judge і ручне оцінювання, порівнювати версії агента та вбудовувати Evals у процес розробки й тестування.

Сьогодні всі створюють AI-асистентів, які допомагають у повсякденних справах, і за допомогою vibe coding швидко збирають красиві демонстраційні застосунки. Однак, коли ви намагаєтеся запустити AI-асистента в реальному production-середовищі — особливо якщо ним користуватимуться громадяни на державному порталі, — стає зрозуміло, що створення самого AI-агента становить лише близько 10% усієї роботи. Решта 90% припадає на наскрізні вимоги системи та очікування різних груп стейкхолдерів. Доповідь базується на моєму власному досвіді запуску AI-асистентів для громадян на державному порталі, створеному на основі агентної AI-платформи. Я розповім про виклики, з якими ми зіткнулися, вимоги та застереження різних груп стейкхолдерів, важливі нефункціональні вимоги й атрибути якості рішення, а також можливі способи розв’язання цих проблем. Учасники отримають практичні поради, ширше бачення реальних викликів і зможуть розвинути критичне мислення. Вона буде корисною фахівцям із різними ролями, які хочуть отримати цілісніше уявлення про створення та запуск AI-асистентів у production. Серед тем, які я планую розглянути: — наївна реалізація чатбота порівняно з масштабованим і зрілим рішенням; — переваги та недоліки агентної AI-платформи порівняно з власною реалізацією; — вибір між публічною та приватною LLM; — продуктивність і якість роботи; — інфраструктура; — витрати; — обробка помилок; — UI/UX; — guardrails, захист від зловживань і DDoS-атак; — спостережуваність системи; — багатомовна підтримка; — фреймворк для тестування та оцінювання; — робота з персональними даними; — та інші аспекти.

ШІ сьогодні може відповідати на запитання, шукати інформацію та виконувати завдання. Але як зробити так, щоб він став не просто ще одним чатом, а справжньою частиною бренду? На прикладі Машрума Геннадійовича - АІ-асистента Сільпо - розповім, як створювався продукт, що поєднує сучасні LLM, продуктове мислення та характер бренду. Поговоримо про шлях від ідеї до запуску, архітектуру рішення, компроміси, помилки та висновки, які можуть бути корисними кожному, хто будує АІ-продукти.

Впровадження ШІ у державний сервіс на 23+ млн користувачів — це шлях постійних продуктових відкриттів та викликів. У цій доповіді я поділюся реальним досвідом того, як екосистема «Дія» переходить від класичної Цифрової держави (де юзер сам шукає потрібні послуги) до Агентної (де ШІ проактивно виконує намір користувача). Про що поговоримо: - Product Discovery та зміна парадигми: Перехід від Digital State до Agentic State. Чому звичні інтерфейси досягли своєї межі, та як ми валідували потребу в проактивних AI-рішеннях. - AI у Підтримці як перший великий крок: Як ми автоматизували 90% звернень без втрати якості (CSAT). М'який AI UX: чому люди не вміють користуватися промптами і як ми допомагаємо їм гібридними інтерфейсами. - Кейс Upskill та трансформація команди: Ми не звільнили жодного оператора. Як ми створили внутрішні AI-тули для команди, а вчорашні оператори стали AI-тренерами. - Deep Dive у Дія.AI на Порталі: Запуск першої у світі агентивної послуги на державному рівні. Як працює наша RAG-архітектура, як ми захищаємо персональні дані (PII) від потрапляння в LLM та відбиваємо спроби джейлбрейків.

Що відбувається, коли велика мовна модель стає точкою входу до державних сервісів, які працюють під реальним навантаженням і в умовах інформаційної війни? У такій архітектурі будь-який запит може бути не лише некоректним, а й навмисно маніпулятивним — і стандартні AI-safety рішення виявляються значно менш надійними, ніж у лабораторних бенчмарках. У цій доповіді я розповім, як ми будували власний guardrail-модуль для Дія.AI після того, як зіткнулися з обмеженнями готових фільтрів і високою вартістю підходу LLM-as-a-Judge. Замість перевірки кожного запиту великою моделлю ми спроєктували каскадну архітектуру безпеки: швидкі ML-класифікатори відсікають більшість трафіку, а LLM підключається лише там, де справді потрібен глибокий аналіз контексту. Це доповідь не про ідеальні моделі, а про компроміси, обмеження і практичні рішення, які доводиться приймати, коли AI-система працює не в ноутбуці, а в національному сервісі.

Ця презентація призначена для інженерів, архітекторів та технічних лідерів, які хочуть не просто користуватись великими мовними моделями, але й розуміти, як вони працюють, як працювати через API, які є проблеми при створенні RAG-систем і як їх розв'язувати.