Більшість використовує штучний інтелект насамперед як інструмент підвищення продуктивності — щоб виконувати задачі швидше та якісніше. Однак чи можемо ми розвиватися швидше та якісніше завдяки ШІ? З одного боку, ШІ як дизайнер планів допомагає визначати кроки для досягнення особистих цілей. ШІ як рефлексивний партнер аналізує твій голосовий щоденник (структурує хаотичні думки, виявляє патерни, відкриває несподівані інсайти), дозволяє глибше розмірковувати над статтями, книжками, відеороликами. ШІ як спаринг-партнер створює безпечний простір для відпрацювання навичок у симуляціях — від інтерв’ю і складних розмов до практикування англійської. ШІ як тьютор дозволяє опановувати нові знання та навички у зручному для вас темпі. З іншого боку, виникає ризик ілюзії компетентності — як ви зрозумієте, що якісно опанували знання та навички за допомогою ШІ, якщо не є експертом у цій сфері? Ба більше, деякі дослідження показують когнітивну атрофію у людей через аутсорсинг мислення і використання ШІ як милиці для розмірковувань. Тож, використання ШІ — це про прискорений розвиток чи про поступову деградацію? Під час виступу спікер представить результати практичного експерименту з кейсами — чи може використання ШІ допомогти стати кращою версією себе.

Дизайн — це те, що доходить до людей, а не те, що лежить у файлах чи обговорюється на внутрішніх мітингах. Щоб дизайн справді запрацював, його потрібно презентувати й “продати”. Клієнт, стейкхолдери, команда розробки — усі, хто буде його реалізовувати, мають повірити в рішення. Я поділюся тим, чого навчився, працюючи з продуктовими компаніями, студіями, агенціями, підприємцями та людьми, які ухвалюють рішення. У доповіді розглянемо: • чому гарний і логічний дизайн сам по собі не гарантує, що його погодять і реалізують • як структурувати презентацію, щоб її справді зрозуміли • коли демонстрація екрана у Figma працює добре, а коли вбиває атмосферу • як думати про аудиторію презентації — хто перед вами, що їм потрібно і чому — щоб менше переробляти й швидше релізити продукт

Про різні етапи розвитку дизайнерської карʼєри та виклики, з якими ми стикаємося на кожному з них. Відповіді на запитання: що робить дизайнера справді крутим; яка освіта потрібна дизайнеру і чи можна без неї; навіщо дизайнеру політика та як презентувати свій дизайн; як працювати в команді; як нетоксично критикувати; як пізнати себе й віднайти своє «кунг-фу» — і багато іншого.

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

Партнерство з AWS майже завжди стартує з опору: “це бюрократія”, “немає часу”, “не дає цінності продукту”. У доповіді покажемо, як ми перетворили AWS програми (FTR, Ready, Delivery, Competencies) на керовану систему роботи з портфелем проєктів. Розберемо, як отримували підтримку бізнесу та команд, як домовлялись про пріоритети, і як переводили очікування в чіткі артефакти: evidence packs, шаблони, KPI-формати, business outcomes, enablement. Пояснимо, як працюють ролі та ownership, ритми, quality gates і правила відбору кейсів, а також як ми реагуємо на фідбек Amazon на кшталт “be more specific”, щоб наступна подача була сильнішою та швидшою.

Коли система партнерських подач уже працює, головний виклик - стабільно конвертувати findings у зміни в проді та доводити ефект метриками. У доповіді покажу наш практичний цикл: finding => виправлення => перевірка ефекту => тиражування патерну на багато команд. Ми зробили фокус - на метриках, які перетворюють SRE на керовану систему: ми вимірюємо швидкість, стабільність і вартість змін так, щоб рішення приймались не інтуїтивно, а на даних з врахуванням безпеки яка стала частиною цього патерну. Розберемо, як уникати “локальних” фіксів, як робити зміни відтворюваними, і як підтримувати прогрес не разово, а постійно.

Це історія про реальний біль і дорослішання системи логування. Ми подивимось, як відсутність стандартів ламають observability. Я покажу, чому Kubernetes став точкою неповернення і змусив нас переглянути підхід до логів. Розберемо вимоги та архітектурні рішення, які дозволили повернути контроль. Поділюсь практичним досвідом побудови керованих лог-пайплайнів без магії і “чарівних інструментів”. Це чесна історія з продакшну.

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

У межах ініціативи Security Hardening ми впровадили підхід Access as Code для керування доступами в AWS. Для кожного репозиторію створюється окрема IAM-роль з permissions відповідно до принципу Least Privilege. Управління ролями винесене в централізований репозиторій, де кожен сервіс описується одним YAML-файлом. Усі зміни проходять через Pull Requests та approvals, а за допомогою Terraform і Atlantis ролі автоматично створюються або оновлюються. У результаті ми отримали масштабоване, аудитоване та безпечне керування доступами без прямого доступу команд до AWS.