У High-Load системах вартість інфраструктури часто зростає не через саме навантаження, а через неефективні архітектурні рішення: overprovisioning, надмірне використання managed-сервісів, зайвий data movement, неправильні SLA-рішення та відсутність прозорої cost-моделі. На конференції поговоримо, як підходити до cost optimization як до повноцінної архітектурної практики, а не як до разового скорочення ресурсів. Також поговоримо про аналіз workload profile, пошук реальних bottleneck’ів, побудову unit economics для інфраструктури, оптимізацію трафіку, кешування, CDN, observability та контрольовану деградацію сервісів. Окремо розберемо trade-off між performance, reliability та cost: де потрібна максимальна відмовостійкість, де достатньо eventually consistent підходу, а де managed-рішення варто замінити простішою self-hosted архітектурою.

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

Що якщо інженер отримує не задачу, а вже готовий PR з контекстом і пропозицією рішення? У Wix ми будуємо remote agents — автономні агенти, які тригеряться зовнішніми подіями (Jira, Slack), виконують задачу у фоні без участі людини і повертають результат як контекст для розробника. У доповіді я розберу: що таке remote agents, як вони влаштовані архітектурно, і як впровадити такого агента у себе в системі. Поділюсь реальними цифрами — success та failure кейси з нашого досвіду. Окремо — про неочевидне: де агенти ламаються, чому spec-driven підхід критичний для їх роботи, і що змінюється в процесах команди, коли частину роботи робить агент. Доповідь буде корисна тим, хто вже працює з AI-інструментами і думає над наступним кроком — від copilot до автономії.

Ще десять років тому ми тягнули в проєкти бібліотеки та фреймворки не від хорошого життя. Це був єдиний спосіб вижити в часи «бравзерних воєн» і не потонути в спагеті-коді. Фреймворки стали нашим порятунком, і ми до них звикли. З того часу веб змінився, а наші звички — ні. HTML, CSS та JS зробили величезний стрибок вперед, але ми продовжуємо автоматично тягнути мегабайти абстракцій, щоб просто відрендерити список товарів, і гордо називаємо це «сучасним стеком». Настав час поставити собі незручні питання: • Що насправді вирішує фреймворк сьогодні, окрім нашого страху залишитися наодинці з чистим JS? • Де межа, за якою «комфорт розробника» стає безглуздим тягарем для продукту? • Чи не став фреймворк просто зручною ширмою, за якою ми ховаємо небажання знати, як працює платформа? Я не закликаю видалити React завтра (хоча…). Але я прагну розібратися: чи досі фреймворки вирішують реальні технічні проблеми, а чи ми створюємо черговий Hello World на реакті просто тому, що вже не вміємо інакше?

Vibecoding — один із найефективніших інструментів для product-менеджера сьогодні. Він дозволяє не лише використовувати готові сервіси для пришвидшення роботи, а й створювати власні інструменти під конкретні задачі — з урахуванням контексту продукту і процесів. Це зменшує кількість зайвих дій і повернень до одних і тих самих задач вручну. У великих командах це про персональну ефективність і автоматизацію роботи. На етапі R&D — про можливість самостійно зібрати MVP, отримати перший фідбек від користувачів і лише після цього передати рішення в розробку. У доповіді Максим розкаже, як він використовує vibecoding у роботі product-менеджера: від MVP до створення власних інструментів.

У багатьох системах аналітика будується прямо в backend: події, воркери, enrichment через десятки запитів до бази та виклики інших сервісів. У нашому випадку один аналітичний event генерував до 10 звернень у БД, що при масштабі в мільйони подій створювало значне навантаження на production. У цій доповіді я розповім, як ми повністю змінили підхід: - перейшли від application events до CDC через Debezium; - почали віддавати зміни з кожної таблиці напряму в data pipeline; - перенесли enrichment та агрегації в BigQuery; і фактично прибрали аналітичне навантаження з backend-сервісів. У результаті: - ми позбулися мільйонів read-запитів до production бази; - зменшили складність backend-коду; - відокремили OLTP від аналітики; і зробили побудову аналітики значно швидшою. Окремо поговоримо про неочевидний ефект: тепер для побудови нових аналітичних сценаріїв достатньо одного Data Engineer, ERD-схеми та сучасних AI-інструментів — без залучення backend-команди і без змін у продакшн-коді. Також розглянемо: - де CDC реально дає виграш, а де ні; - які проблеми з’являються (lag, дублікати, schema changes); - як змінюється вартість системи; і чому “ті самі дані” в новій архітектурі — це не безкоштовно.

<p></p>

Вимоги ринку до розробників стрімко зростають: сьогодні замовникам потрібне не лише базове вміння писати промпти, а й практичний досвід роботи з Model Context Protocol (MCP). На цій доповіді ми доведемо, що в MCP немає нічого складного: ми пройдемо шлях від звичайного REST API до готового MCP-сервера. Ви дізнаєтесь про ключові особливості протоколу, необхідні бібліотеки та аспекти безпеки, щоб навчити штучний інтелект самостійно користуватися вашим бекендом.

Олексій Мінаков і Вʼячеслав Колдовський зійдуться у видовищному батлі, щоб наживо продемонструвати найяскравіші й найнесподіваніші кейси використання інструментів генеративного штучного інтелекту. На вас чекають нестандартні сценарії, творчі експерименти та вражаючі приклади реального застосування ШІ, які не залишать байдужими ні новачків, ні профі. Мета — не просто здивувати, а розширити уявлення про можливості сучасного штучного інтелекту. Вʼячеслав Колдовський: Agent Skills Superpowers. Пам’ятаєте, як в Матриці Нео навчився Кунг-фу? Йому просто ці знання завантажили в голову. На жаль, поки що з людьми це не працює, але вже доступно для AI-агентів за допомогою Agent Skills. Agent Skills перекладається як “навички агента” і по суті є тим же, що і навички людини – тобто здатність виконувати певні дії, досягати результату або вирішувати конкретні задачі. Але на відміну від людей, агентам ці навички не потрібно роками тренувати – їх можна створювати, комбінувати та перевикористовувати практично миттєво. Фактично, Agent Skills – це модульні блоки поведінки: окремі функції, інструкції або сценарії, які агент може викликати у потрібний момент. Це можуть бути як прості дії (наприклад, обробити текст або знайти інформацію), так і складні процеси (запустити аналіз, взаємодіяти з API, або виконати багатокроковий workflow). Справжня “суперсила” з’являється тоді, коли ці навички починають працювати разом. Агент може динамічно обирати, яку навичку застосувати, комбінувати їх у ланцюжки та адаптувати поведінку під контекст задачі. Мало того, якщо ми опишемо послідовність необхідних дій не у якості детермінованого коду, а як набір навичок агента, то ми по факту “запрограмуємо його”, але зробимо це у зовсім іншій парадигмі недетермінованого програмування, яка, на відміну від звичайних детермінованих програм, може адаптуватися до контексту, приймати рішення в умовах невизначеності, гнучко змінювати свою поведінку в залежності від обставин і навіть автоматично покращуватися. І саме тому Agent Skills – це суперможливості AI агентів, з якими ми познайомимося разом з В'ячеславом Колдовським.