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

Що якщо інженер отримує не задачу, а вже готовий 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>