На прикладі Awesomic покажу, як повернувся з менеджменту в кодинг і переважно сам перебудував продукт із нуля. Тепер це хмарна платформа для керування software factories та спільної роботи людей і агентів. Поділюся, як впроваджую цей підхід у компанії зі 100 людей: як змінюються процеси й ролі, як зберігати контроль над даними та накопиченими знаннями компанії й уникати vendor lock-in. Усе на прикладі реального воркфлоу, з живим демо та власними скілами для агентів, які ще ніде не публікував.

Що, якби на типове запитання під час онколу першим відповідав не інженер? AI-асистент, створений платформною командою Superhuman, допомагає понад 25 командам і самостійно вирішує 20% запитань. Я розповім, як ми перетворили його на платформний сервіс, а також познайомлю з AI Golden Path — внутрішнім сервісом, який допомагає інженерам використовувати AI-агентів і виконувати типові задачі розробки та роботи з інфраструктурою через готові інструменти й покрокові робочі процеси. Поділюся, як ці сервіси вписуються в платформну стратегію, чого ми навчилися, як ми здобували довіру команд, і що плануємо розвивати далі.

Чому майбутнє автоматизації — не в кількості розробників, а в доступності AI-агентів Традиційна автоматизація вимагає часу, бюджету та залучення IT-команд. Але що, якщо кожен співробітник зможе самостійно автоматизувати власні процеси? Agentic Workforce змінює сам принцип організації роботи. Люди визначають цілі, агенти виконують задачі, а платформа забезпечує інструменти, доступи, безпеку та контроль. Розповім про наш досвід побудови та впровадження Agentic Workforce продукту в ентерпрайз організації, архітектуру агентної платформи, управління цифровими виконавцями та те, як ми бачимо трансформацію корпоративної автоматизації.

Кожна нова хмара в компанії зазвичай означає ще один набір Terraform, ще одну інструкцію з деплою і ще один спосіб зробити все по-своєму. Витрати ростуть швидше, ніж кількість провайдерів. Platform engineering дозволяє розірвати цю залежність: golden path стає інтерфейсом, а конкретна хмара — реалізацією. Розробник описує, що йому потрібно — сервіс і production-база даних — а платформа сама вирішує, як це виглядає у гіперскейлері, а як у локального провайдера. У живому демо розробник створює новий сервіс через портал самообслуговування. Один шаблон, один Kubernetes-маніфест — і застосунок розгортається у двох хмарах одночасно. Однакова заявка на PostgreSQL в одній хмарі стає керованим сервісом бази даних, в іншій — базою під управлінням оператора в Kubernetes. Окремо — про межі підходу: IAM, сторедж і бекапи абстракція не приховує, і я покажу, чому це нормально. Після доповіді ви знатимете, як влаштований патерн «заявка → композиція» для баз даних у різних хмарах, з чого почати свій перший golden path без побудови власного PaaS, і які відмінності між хмарами варто показувати розробникам явно.

Жодна продуктова команда не може встигати за всіма потребами та сценаріями Сил оборони. Водночас військові вже самостійно адаптують наявні цифрові продукти — створюють допоміжні застосунки та власні інструменти, щоб закривати конкретні потреби у своїх бойових end-to-end процесах і пришвидшувати знищення ворога. Як перетворити цю потребу на повноцінну платформенну можливість? Як дати користувачам безпечний і стандартизований спосіб адаптувати цифрові продукти під власні задачі на полі бою? У презентації розберемо наш підхід до цієї проблеми, покажемо реальні кейси та продемонструємо основні можливості, які вже працюють сьогодні. Поговоримо також про те, як розвивати цей підхід далі: від адаптації інтерфейсів до роботи з серверною логікою, даними та AI/Agent можливостями — і зрештою дати користувачам змогу збирати власні end-to-end процеси навколо спільної платформи.