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

«Так, дякую, ви абсолютно праві! ? Зараз перепишу так, щоб читалося, наче це написала людина. Ось оновлена версія — жива, з людською інтонацією, без канцеляриту». Задовбало таке читати? Мене — так. Вода, вода, водюська. Якісь висновки до питань, які не були поставлені. Читаєш і не розумієш: чи то ти тупий, чи то AI-шка писала. У цій доповіді, написаній самостійно, я розбиратиму набір AI-політик, які ми впровадили у своїй організації, і розповідатиму, як ми використовуємо AI, щоб спрощувати комунікацію, а не ускладнювати її.

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

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

Я хочу поговорити про справжнє впровадження AI — проблеми, про які рідко пишуть у LinkedIn-історіях успіху, — спираючись на досвід Temabit з розгортання AI в delivery-процесі. Поговоримо про проблеми на землі — не в презентаціях, а в роботі команд: як команди опираються змінам, що нарешті веде до прийняття нового підходу, і яку ціну це справді має — у часі, процесах і культурі. Пояснимо, чому видачі розробникам ліцензії на Claude Code недостатньо — і чому AI SDLC важливий, коли мета — масштабувати впровадження далі одного «power user» на весь delivery process. Розглянемо шлях Temabit від хаотичного застосування агентів до SDD, а потім до AI SDLC, з ключовими проблемами на кожному кроці. Завершимо розмову наступними кроками і проблемами, які досі вирішуються.

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

Аgentic PDLC - агент більше не просто пише або переглядає код — він висуває гіпотези та тестує їх в production. Як переорієнтувати архітектуру для автономних агентських циклів, які працюють 24/7 на системах з мільйонами користувачів? Використовуючи досвід Ентерпрайз компанії, розберемо, як перейти від людського контролю до event-driven governance та явних guardrails для агентів.

Агентна інженерія дорослішає: від «попроси агента написати код» ми переходимо до фабрик — конвеєрів, де команда AI-агентів проводить проєкт повним циклом: вимоги → специфікації → тести → імплементація → адверсарне рев'ю → докази якості. У доповіді розберемо, з чого така фабрика складається насправді: оркестратор і спеціалізовані субагенти, детерміновані quality gates, ланцюг трасування від вимоги до тесту, петлі верифікації замість «здається, працює». Головний виклик автономної розробки — не змусити агентів писати код, а не дати фабриці впевнено рапортувати успіх там, де його немає. Розберемо типові механізми самообману конвеєра: «м'які» правила в промптах, що зникають під тиском реального проєкту; перевірки, які тихо пропускають відсутні докази; вимоги, чий метод приймання ніколи не існував у вигляді коду. Ілюструватиму живим матеріалом — зокрема кейсом, де фабрика пройшла всі гейти «на зелено» й видала продукт, що не відповідав ключовій вимозі, і тим, що знадобилося, аби той самий прогін став чесно червоним. Окрема частина — про самовдосконалення: як побудувати цикл, у якому кожен виявлений провал стає новим гейтом, який наступний проєкт вже не зможе оминути. Три-значна семантика перевірок (PASS / NOT-EARNED / FAIL), реєстр процес-дефектів, бібліотека «уроків», що успадковується кожним новим проєктом. Все — на реальних артефактах: коміти, метрики, вимірювані результати. Про що поговоримо: Анатомія agentic-фабрики: оркестратор, субагенти, детерміновані гейти, ланцюг трасування Механізми самообману конвеєра — і форензика реального «фальшивого done» Maker ≠ checker на практиці: адверсарне рев'ю, яке реально ловить дефекти Цикл самовдосконалення: correction → retro → новий гейт → урок для наступного проєкту Скільки це коштує: про токени, час і де фабрика (поки) програє людині Кому буде корисно: інженерам і тимлідам, які вже використовують AI-агентів у розробці й хочуть перейти від «іноді спрацьовує» до передбачуваного конвеєра з доказами якості.

Нову стратегію підтримали не всі. AI-ініціативу саботують. Архітектор просить ще два квартали. Маркетинг хоче запуск уже наступного тижня. Знайомо? Проблема в тому, що ми часто очікуємо від інших людей тієї ж логіки, яку маємо самі. Але у продуктовому бізнесі поруч працюють різні “види”: ті, хто захищають людей; ті, хто захищають експерименти; ті, хто захищають стабільність; ті, хто захищають результат. І поки ми не навчимося бачити ці відмінності, будь-яка стратегія ризикує залишитися красивим слайдом. На прикладах із продуктових команд та AI-трансформацій розберемо, як працює фреймворк конкуруючих цінностей і як використовувати його для впливу, переговорів та управління змінами. 📌 Ключові тези: Кожен стейкхолдер захищає раціональну для себе цінність. “Кожен правий — але частково”. Як читати мотиви за словами та запереченнями. Чому найсильніші продакти вміють перемикати мови впливу. Як зменшувати опір змінам без тиску. Як створювати підтримку навколо продуктових рішень.

AI уже став частиною сучасної engineering-реальності, але в production highload-системах усе значно складніше. GenAI добре працює в демо та copilots, проте чи готовий він до real-time processing, великих навантажень і критичних production-сценаріїв? На панельній дискусії поговоримо про те, чому AI досі майже не став стандартом для highload-архітектур, де проходить межа між ML та GenAI, чому inference коштує дорого, а FinOps стає новим болем engineering-команд. Обговоримо on-prem vs cloud для AI workloads, реальні production-обмеження.