У цій доповіді Владислав розповість про його шлях приборкання 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+ незалежних продуктів протягом трьох років.

Що може піти не так, якщо дозволити кожному сервісу напряму звертатися до бази даних? У стартапі це здається швидким і зручним рішенням, та з часом система масштабується, і зʼявляються проблеми, про які ніхто не здогадувався. У своїй доповіді я поділюся досвідом Solidgate у трансформації архітектури: від хаосу прямих підключень до сервісної моделі доступу до даних. Розповім про стадії переходу, bottlenecks і про те, як ізоляція вплинула на підтримку інфраструктури. Чесно покажу, що спрацювало, а що — ні. Словом, розберемо всю контроверсійність цієї теми.