Останні місяці ми будували один із піддоменів нашого проєкту з кредитування, більшість коду в якому писав ШІ під архітектурним наглядом: 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-компонентів та їх інтеграції у державні продукти. Покажемо, як поєднати обмеження з сучасними підходами і при цьому зберегти здатність швидко створювати та масштабувати цифрові сервіси.

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

Що насправді відбувається з аутсорс-компанією в еру AI? Клієнти перестали питати «скільки це займе» — вони приходять з власною оцінкою. Вони переоцінили нас без нашої обіцянки й без нашої згоди. Довгострокове планування зламалось, а з ним — фінансова модель і ієрархія позицій. Доповідь про те, як ми через це проходимо — на двох конкретних кейсах. Перший: клієнт попросив ×10 продуктивності з наступного спринту. Ми не пообіцяли, що ручна робота зникне — пообіцяв інший вендор. Клієнт зняв 6 із 10 наших інженерів і замінив їх «рієм агентів». Розберемо, як той рій влаштований, чому фічі не доїжджали до продакшену і чому інженерів зараз повертають. Другий: ми поставили ту саму ставку самі — максимальний AI у власному експерименті. 2.5 місяця замість одного, одна з чотирьох фіч переписана після релізу, сотні багів. І те, що з цього вийшло корисного: як ми знайшли, що реальний блокер делівері — це піари, як влаштований наш PR-класифаєр, у якому порядку працюють Claude, класифаєр і розробники, і правило 80%. Плюс відповідь на питання, яке стосується кожної аутсорс-компанії: та сама фіча — менше годин при схожому рейті. Клієнт платить менше, а ми маємо частіше не помилятись.

Створити AI-агента — лише половина задачі. Треба ще зрозуміти, наскільки добре він працює і чи не став гіршим після зміни моделі, запиту, інструментів або даних. У доповіді на практичному прикладі розберемо, як створювати Evals для AI-агентів: формувати тестові сценарії, визначати критерії та метрики якості, використовувати автоматичні перевірки, LLM-as-a-Judge і ручне оцінювання, порівнювати версії агента та вбудовувати Evals у процес розробки й тестування.

Розповідь про шлях створення та розвитку найбільшого військового застосунку, особливості айтішної служби і погляд на плюси, мінуси і підводні камені процесу