Практико-орієнтована архітектурна доповідь про інтеграцію AI-агента в операційний workflow highload data pipeline. Розглянемо сценарій каскадного збою: у пайплайн потрапляють пошкоджені дані, зависають черги Kafka, зростає навантаження на storage, тисячі Kubernetes pod’ів починають падати та пересоздаватися, деградує etcd, а PostgreSQL стає додатковою точкою навантаження. Також покажемо, як AI-агент, побудований на базі AWS Bedrock AgentCore, LangChain та MCP/Gateway, може виявляти ранні сигнали інцидентів, ізолювати corrupted messages, пропонувати human-approved remediation steps, захищати стабільність кластера та перетворювати noisy telemetry на конкретні кроки для відновлення системи.

Ще вчора AI був просто “помічником”, а сьогодні — впливає на найм, зарплати, кар’єрний ріст і саму роль developer-а. Junior-позиції зникають, code generation стає дешевшим, а компанії все частіше оцінюють не роки досвіду, а швидкість адаптації та вміння працювати з AI. На панельній дискусії поговоримо без рожевих окулярів: чи справді AI забирає роботу, чому senior-досвід більше не гарантує перевагу, хто виграє в новій AI-гонці — engineers чи prompt-native спеціалісти — та чи не перетворюється software engineering на зовсім іншу професію. Обговоримо, що буде цінуватись у developer-а через 2–3 роки, чи стане middle новим junior та чи встигає український IT-ринок адаптуватися до змін швидше за світ.

Що варто делегувати AI вже зараз, а що все ще потребує людини? На прикладі стрімінгового продукту поговоримо, як за допомогою AI-copilots оптимізувати QA-командам технічну рутину, масштабувати тестування, пришвидшувати релізи та залишати людям простір для дослідження продукту, UX і складних користувацьких сценаріїв

Більшість систем починаються з push, бо це здається природним — сервер знає, коли щось змінилось, і одразу повідомляє клієнтів. Але у масштабі push містить прихований множник витрат: підключені користувачі × відкриті об'єкти × частота оновлень. Кожна мілісекунда свіжості даних оплачується кожним підключеним користувачем — навіть тим, хто не дивиться на екран. Доповідь побудована на реальному production-кейсі у DraftKings. Розглянемо, як модель доставки даних визначає форму кривої витрат, а не лише профіль затримок. Пройдемо: — оригінальну push-систему та те, як вона накопичувала складність роками — точки болю при масштабуванні, які зробили її нежиттєздатною під піковим навантаженням — процес оцінки альтернатив, який привів до short polling — стратегію міграції без downtime у чотири фази Результати виявились контрінтуїтивними: pull-архітектура з коротким polling-ом показала кращу актуальність даних під піковим навантаженням при суттєвому зниженні споживання CPU та витрат на інфраструктуру. Доповідь завершується практичним фреймворком: коли обирати push, коли pull, і яке питання поставити першим.

Комунікація - одна з ключових навичок product-менеджера, яка напряму впливає на якість рішень, швидкість команди, довіру стейкхолдерів і карʼєрне зростання. Часто її сприймають як щось очевидне: ми всі щодня пишемо повідомлення, проводимо зустрічі, пояснюємо задачі, даємо фідбек і домовляємося з людьми. Через це багатьом здається, що з комунікацією в них усе добре. На практиці саме в комунікації часто ховаються найбільші втрати: нечіткі очікування, погано сформульований фідбек, зайві конфлікти, розмиті домовленості, рішення без buy-in та відчуття, що команда «не так зрозуміла». Для product-менеджера це особливо критично, бо його робота значною мірою тримається на здатності пояснювати, слухати, узгоджувати, впливати й допомагати іншим рухатися в одному напрямку. У доповіді Ray розбере, як виглядає сильна комунікація в product-менеджменті: як оцінювати власний рівень чесніше, де найчастіше виникають помилки, як говорити складні речі простими словами, та як давати фідбек так, щоб він справді допомагав людині й команді ставати сильнішими.

У цій доповіді ми розглянемо практичний кейс впровадження ефективного автоскейлінгу інфраструктури з використанням HPA, VPA та Cluster Autoscaler. Працюючи зі стандартним VPA, ми зіткнулися з обмеженнями: нестачею гнучкості в налаштуванні інтервалів обчислення та конфліктами при одночасній роботі з HPA. Тому ми вирішили створити власний кастомний VPA-контролер. У новому рішенні ми: - Забезпечили коректну спільну роботу VPA та HPA на одних і тих самих ресурсах. - Реалізували механізм фільтрації короткочасних піків CPU на етапі запуску подів. - Оптимізували архітектуру: об'єднали функціонал трьох стандартних компонентів у єдиний под. - Використали нові можливості In-Place Pod Resize, які з'явилися у Kubernetes 1.33. Головний результат: оптимізація споживання ресурсів та зменшення вартості інфраструктури на 20–40%.

Нещодавно Superhuman (раніше Grammarly) запустила Superhuman Go — AI-асистента, який працює поруч із вами на кожній платформі. Щоб його створити, нам було потрібне масштабоване рішення, яке підтримує необмежену кількість агентів, динамічно формує інтерфейс користувача та виглядає однаково на всіх підтримуваних десктопних і мобільних платформах. Приєднуйтеся, щоб дізнатися, як ми знайшли рішення для цього інноваційного продукту

Про що: - Які growth-челенджі визначатимуть 2026 рік. - Як AI змінює швидкість запуску MVP і продуктових експериментів — і чому швидкість без стратегічного фокуса не створює sustainable growth. - Чому для масштабування вже недостатньо CRO та performance-маркетингу. - Як використовувати AI для research, прототипування, продуктових драфтів і швидшого запуску рішень.

У 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) став золотою серединою. Ключова теза: якість коду на виході = якість специфікації на вході. Разом поміркуємо про трансформацію ролі розробника — від «кодера» до «архітектора специфікацій».