Нашою метою на 2026 рік було підвищити ефективність роботи команди на 15–20%... а ми досягли 30–50%. Цикл розробки програмного забезпечення (SDLC) з використанням ШІ перетворився на цикл, повністю заснований на ШІ, де люди працюють разом з агентами з чітким розподілом обов’язків: люди — за логіку та контроль, агенти — за рутинні завдання. Ми використовуємо підхід «human-in-the-loop» та експериментуємо з циклами агентів. Чи можна це розглядати як «фабрику програмного забезпечення на базі ШІ»? Давайте разом поміркуємо... Я продемонструю, як ми працюємо, на прикладі одного з наших найбільших рішень, що складається зі 152 проєктів із 2,5 млн рядків вихідного коду та 18,7 млн токенів для опису спільного контексту. Як ми це підтримуємо? Як ми долаємо обмеження розміру вікна контексту? Побачимося на події!

В епоху, коли AI-агенти стають основою робочих процесів, ми об’єднаємо всі дані ваших проєктів в одному місці та надамо агентам доступ до них. Обговоримо, які проблеми це допоможе вирішити, як правильно збирати й перевіряти дані та підтримувати їх в актуальному стані. А також покажемо, як такий підхід може змінити роботу вашої команди.

Чому з тими самими інструментами одні команди прискорюються, а інші тонуть у слопі? Розберемо типові антипатерни роботи з AI-агентами в розробці: від «згенеруй усе одразу» до сліпої довіри до результату. Покажу, до чого вони призводять на практиці і що робити замість цього.

Кожна нова хмара в компанії зазвичай означає ще один набір 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 у її графово-блоковому вигляді срібною кулею для всіх.