Кілька років тому ми почали будувати 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, відповідає реальному стану системи.

Вимоги ринку до розробників стрімко зростають: сьогодні замовникам потрібне не лише базове вміння писати промпти, а й практичний досвід роботи з Model Context Protocol (MCP). На цій доповіді ми доведемо, що в MCP немає нічого складного: ми пройдемо шлях від звичайного REST API до готового MCP-сервера. Ви дізнаєтесь про ключові особливості протоколу, необхідні бібліотеки та аспекти безпеки, щоб навчити штучний інтелект самостійно користуватися вашим бекендом.

Поговоримо про long running процеси в PHP, чи є життя із API демонами в продакшені, які є best practices та чому вони не завжди best та як саме працювати і на що звертати увагу при розробці.

Розкажу про Computer/Browser/Mobile Use агентів. Почнемо з API, які надають нам OpenAI та Claude під задачі Computer Use. Згадаємо, як тренуються LLM/VLM, що таке RL і як його тут можна застосувати. Розберемо свіжі open-source модельки та поговоримо про evaluation таких агентів.

Багато розробників створюють окремий шар для роботи з API, але Нікіта вважає, що це неефективно — краще генерувати код із контракту вашого API. У доповіді будуть розглянуті такі питання: чим відрізняється SDK від API та чому SDK є кращим варіантом для розробки? Як автоматично згенерувати SDK для Swagger та GraphQL? Що робити, якщо у вас немає контракту API? І, нарешті, чому бекенд-розробникам теж важливо розуміти React? Доповідь допоможе оптимізувати процеси розробки та спростити взаємодію між командами, роблячи роботу з API більш передбачуваною та зручною.

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

Performance оптимізація Laravel додатків