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

Розгортання та оптимізація LLM-інференсу в продакшні на GPU від L4 до 4xH200: вибір інференс-двигунів та конфігурацій, баланс між пропускною здатністю, затримкою та вартістю, а також як «вичавити» максимум із обладнання й уникнути типових помилок тюнінгу

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

Як заповідав класик — «жить нада інтересно». Особливо в інтересні часи. Особливо коли ШІ безпардонно увірвався до нашої затишної бульбашки й почав погрожувати, що забере в нас роботу. Але якщо не можеш здолати — очолюй. Тож я вирішив першим добровільно віддати йому свою роботу. Ну як віддати — передати звання React-абізяни. Але в процесі так захопився, що незчувся, як створив цілу зграю різноманітних абізян із (майже) чіткими ролями, (майже) визначеними обовʼязками й обмеженнями, здатних (майже) одним порухом вирішувати мої задачі. Про це я й хочу розповісти: як із бажання змусити LLM писати рутинний код зʼявилася ціла команда спеціалізованих агентів, як я будував свій agent harness у Claude Code, що виходило, що не виходило і які обхідні шляхи довелося вигадувати. І, зрештою, чого дресирування ШІ-мавп навчило мене про моделі й промпти, та чому "ну будь лаааасочка" в промпті не гарантуватиме вам хорошого результату.

Останні місяці ми будували один із піддоменів нашого проєкту з кредитування, більшість коду в якому писав ШІ під архітектурним наглядом: 100 сторей за 26 днів, 12 репозиторіїв, ≈218 500 рядків коду, 44 ADR, включаючи вимоги PCI DSS і НБУ, де ціна архітектурної помилки доволі висока. Цей досвід змінює погляд на роботу архітектора при плануванні проєктних рішень. Хоча інструменти штучного інтелекту допомагають автоматизувати та прискорити розробку, але фактично відповідальною за результат залишається людина. ШІ за замовчуванням не мислить стратегічно, і часто обирає найпростіший шлях реалізації, що може призводити до негативних результатів в майбутньому, якщо людина явно не опише стратегію при постановці завдання. Тож чим більшої автономності ми хочемо від ШІ, тим вища кваліфікація потрібна людині поруч: залишаються рішення, які не можна делегувати, хоч якою розумною стане наступна модель. Сучасні методології (ADR, quality gates, ATAM, TOGAF) в епоху ШІ трансформуються і дозволяють досягати якіснішого результату з вищою автономією. Про це ми і поговоримо на моїй доповіді. Доповідь для архітекторів, тімлідів і сеньйорів, які вже спробували ШІ та прагнуть підвищити результативність та автономність своїх команд.

Як би ви назвали техліда який читає і перевіряє кожен рядок коду, що написала його команда? Для мене це не риторичне питання: у своїй кар'єрі я мав досвід побудови процесів контрібюшину для одного з найбільших репозиторіїв в Grammarly для сотні інженерів кожного місяця. Сьогодні кожен із нас став тімлідом команди АІ агентів і ми задаємо собі і один одному аналогічне питання: як називати людину що не читає код, який генерують його агенти? Не вдаваючись в усю глибину контроверсійності цього питання, я вважаю що фундаментально відповідь для нього ідентична для команди людей і команди агентів. Правильно побудовані процеси дозволяють ліду уникати мікроменеджменту і рев'ю кожного рядка в пул реквесті. У цій доповіді я покажу прагматичні рецепти побудови АІ розробки, що наблизитимуть вас до довіри до коду, написаного вашими АІ агентами.

Якщо в тебе процес розробки виглядає як "я пишу в Claude Code промпт, а далі разом з своїм улюбленим комплектом скілів робимо справу" - то ви застарілі роки на півтора, що в наших ШІ-реаліях - вічність. Зараз в моді графи та self-improving loops - ви пишете задачу - її розбивають на 100500 окремих блоків, кожен з яких простий, дає вимірюваний результат а отже - ним легко керувати і легко покращувати. Виглядає ідеально? Так, доки тебе не втомлює, що проста задача робиться годинки півтори або поки ти не рахуєш скільки це коштує (в грошах чи токенах - неважливо). За останні півроку я побудував 6 подібних фабрик як консалтер - як під копірку за ідеологією - однак тепер з кожним новим клієнтом я починаю довгу розмову, що скоріше за все вам або воно не треба, або треба - але в інший спосіб. Ми зачепимо три аспекти: технологічний, економічний та культурний, щоб пояснити де власне виникають проблеми і чому я більше не вважаю dark software factory у її графово-блоковому вигляді срібною кулею для всіх.

Кілька років тому ми почали будувати Architecture as Code з доволі простою метою: зробити архітектурні знання доступними, актуальними та зрозумілими для інженерів. C4-діаграми, ADR, OpenAPI, ERD, ownership та інша документація поступово переїхали ближче до коду, стали version-controlled і machine-readable. Ми робили це для людей. А потім прийшли AI-агенти. І несподівано виявилося, що один із найскладніших етапів роботи з AI — передача агенту контексту про систему — у нас уже майже вирішений. У цій доповіді поговоримо про те, чому доступу до репозиторію недостатньо, чим code context відрізняється від system context і як практики Architecture as Code природно перетворюються на Context Engineering. На реальних прикладах розберемо, який контекст потрібен AI-агенту, щоб він не просто писав код, а розумів домени, архітектурні рішення, API-контракти, ownership та обмеження системи. А також поговоримо про наступний виклик: як переконатися, що контекст, на який спирається AI, відповідає реальному стану системи.

Коли ми даємо LLM супутникові дані, результати пошуку об’єктів на цих зображеннях вражають на якісних знімках і повністю розсипаються на безкоштовних супутникових даних, де весь об'єкт займає десь двадцять пікселів. Розповім, як ми шукали несанкціоновані сміттєзвалища на Sentinel-2 і чому шлях до робочого результату пройшов через «взяти даних побільше та закинути у модель ще більшу» — спочатку у просту відмову від LLM та перехід на спеціалізовані детектори, а зрештою — до архітектури, де кожну ознаку об’єкта шукає окремий агент, а підсумкову ймовірність рахує явна математика.

В доповіді розберемо, що відбувається із software engineering, коли твій продукт є частиною державної цифрової інфраструктури. Мільйони громадян, державні реєстри, критична інфраструктура, персональні дані, десятки інтеграцій і високі вимоги до безпеки змінюють звичні правила розробки. Те, що легко працює у приватному секторі, в GovTech може вимагати зовсім іншого підходу. Пройдемо шлях від ідеї до production: принципи побудови SuperApp, product discovery та специфіку SDLC, on-premise та cloud, безпеку і захист інформації. Окремо розберемо AI у GovTech - від збору та підготовки даних для власних моделей до розробки AI-компонентів та їх інтеграції у державні продукти. Покажемо, як поєднати обмеження з сучасними підходами і при цьому зберегти здатність швидко створювати та масштабувати цифрові сервіси.