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

У цій доповіді Владислав розповість про його шлях приборкання AI: від простого Plan Mode в Cursor/Claude до складних систем документування. Він розбере, чому GitHub Spec Kit виявився занадто важким, як ADR (Architecture Decision Records) допомагають агентам не «губити» контекст між сесіями і чому OpenSpec від Y Combinator (Fission-AI, W26) став золотою серединою. Ключова теза: якість коду на виході = якість специфікації на вході. Разом поміркуємо про трансформацію ролі розробника — від «кодера» до «архітектора специфікацій».

Багато хто вважає архітектуру на фронтенді мемом. І, чесно, підстави для цього є. Але ми все одно її будуємо — на реальному продукті, в реальній міграції. Ця доповідь про те, як ми переводимо великий e-commerce з Clojure-моноліту на окремий frontend: тонкий клієнт, React як UI бібліотека, а Next.js як деталь системи — не ядро. Наскільки це виходить насправді, де реальність розходиться зі схемами та початковими планами. Без канонічних рецептів — живий досвід із живого продукту.

Ця доповідь демонструє практичні підходи до unified observability, де метрики, логи, траси та профілі інтегровані для швидкої діагностики проблем у розподілених системах. Розглянемо техніки кореляції даних через traceId та лейбли для миттєвого переходу від помилок до конкретних span'ів, налаштування continuous profiling для preview-середовищ, використання flame charts для аналізу продуктивності, dependency maps і service graphs для візуалізації архітектури. Окрема увага приділена AI-специфічним аспектам: застосування AI-асистентів для автоматизації root cause analysis та впровадження AI Evals для систематичного оцінювання якості, коректності та надійності AI-систем.

Low Latency в High-Load: шлях від Redis Pub/Sub до In-Memory Runtime — іграшка, яка зайшла надто далеко У доповіді розглянемо практичний досвід побудови low-latency системи для міжбіржових операцій, де географія не менш важлива, ніж алгоритми. Поговоримо про те, чому message brokers і класичні мікросервіси не є вдалим рішенням для HFT (High-Frequency Trading)-подібних сценаріїв, як in-memory state у поєднанні з регіональними runtime-вузлами забезпечує прогнозовану затримку, і де проходить межа між швидкістю та consistency.

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

Коли система складається з десятків незалежних репозиторіїв, класична monorepo не завжди підходить. Дмитро розповість, як meta-repo з git submodules та AI-інструментами дозволяє зберегти автономність сервісів, але працювати з ними як з єдиною екосистемою. Ви побачите реальні сценарії, де AI: • з’єднує код, контракти та документацію • допомагає з автотестами та інтеграціями • спрощує роботу для девелоперів, QA та продукту • пришвидшує прототипування та delivery

Знати SOLID та патерни GoF — це як знати правила дорожнього руху: можна здати іспит і все одно потрапити в аварію. Бо між «знаю, що існує Single Responsibility» і «розумію, навіщо він потрібен саме тут» — прірва. І в цій прірві живуть God-класи, незамінювані залежності та інтерфейси, які неможливо імплементувати. На прикладах реальних помилок великого проєкту поговоримо про різницю між знанням і розумінням, про те, як фреймворки можуть маскувати архітектурні проблеми, і чому єдиний спосіб писати підтримуваний код — це зрозуміти «навіщо», а не завчити «як».

Як за лічені години побудувати власне середовище для генеративного ШІ — від ідеї до робочого рішення? Під час виступу команда De Novo поділиться практичним досвідом створення керованого середовища для GenAI, розповість про архітектуру, підхід до безпеки та реальні сценарії використання в українських компаніях.

Доповідь присвячена підходу масштабування бізнесу через продуктовий архітектурний принцип (Product-Oriented Architecture) — перехід від одного рішення до повноцінної екосистеми з 10+ незалежних продуктів протягом трьох років.