Аgentic PDLC - агент більше не просто пише або переглядає код — він висуває гіпотези та тестує їх в production. Як переорієнтувати архітектуру для автономних агентських циклів, які працюють 24/7 на системах з мільйонами користувачів? Використовуючи досвід Ентерпрайз компанії, розберемо, як перейти від людського контролю до event-driven governance та явних guardrails для агентів.

Агентна інженерія дорослішає: від «попроси агента написати код» ми переходимо до фабрик — конвеєрів, де команда AI-агентів проводить проєкт повним циклом: вимоги → специфікації → тести → імплементація → адверсарне рев'ю → докази якості. У доповіді розберемо, з чого така фабрика складається насправді: оркестратор і спеціалізовані субагенти, детерміновані quality gates, ланцюг трасування від вимоги до тесту, петлі верифікації замість «здається, працює». Головний виклик автономної розробки — не змусити агентів писати код, а не дати фабриці впевнено рапортувати успіх там, де його немає. Розберемо типові механізми самообману конвеєра: «м'які» правила в промптах, що зникають під тиском реального проєкту; перевірки, які тихо пропускають відсутні докази; вимоги, чий метод приймання ніколи не існував у вигляді коду. Ілюструватиму живим матеріалом — зокрема кейсом, де фабрика пройшла всі гейти «на зелено» й видала продукт, що не відповідав ключовій вимозі, і тим, що знадобилося, аби той самий прогін став чесно червоним. Окрема частина — про самовдосконалення: як побудувати цикл, у якому кожен виявлений провал стає новим гейтом, який наступний проєкт вже не зможе оминути. Три-значна семантика перевірок (PASS / NOT-EARNED / FAIL), реєстр процес-дефектів, бібліотека «уроків», що успадковується кожним новим проєктом. Все — на реальних артефактах: коміти, метрики, вимірювані результати. Про що поговоримо: Анатомія agentic-фабрики: оркестратор, субагенти, детерміновані гейти, ланцюг трасування Механізми самообману конвеєра — і форензика реального «фальшивого done» Maker ≠ checker на практиці: адверсарне рев'ю, яке реально ловить дефекти Цикл самовдосконалення: correction → retro → новий гейт → урок для наступного проєкту Скільки це коштує: про токени, час і де фабрика (поки) програє людині Кому буде корисно: інженерам і тимлідам, які вже використовують AI-агентів у розробці й хочуть перейти від «іноді спрацьовує» до передбачуваного конвеєра з доказами якості.

Нову стратегію підтримали не всі. AI-ініціативу саботують. Архітектор просить ще два квартали. Маркетинг хоче запуск уже наступного тижня. Знайомо? Проблема в тому, що ми часто очікуємо від інших людей тієї ж логіки, яку маємо самі. Але у продуктовому бізнесі поруч працюють різні “види”: ті, хто захищають людей; ті, хто захищають експерименти; ті, хто захищають стабільність; ті, хто захищають результат. І поки ми не навчимося бачити ці відмінності, будь-яка стратегія ризикує залишитися красивим слайдом. На прикладах із продуктових команд та AI-трансформацій розберемо, як працює фреймворк конкуруючих цінностей і як використовувати його для впливу, переговорів та управління змінами. 📌 Ключові тези: Кожен стейкхолдер захищає раціональну для себе цінність. “Кожен правий — але частково”. Як читати мотиви за словами та запереченнями. Чому найсильніші продакти вміють перемикати мови впливу. Як зменшувати опір змінам без тиску. Як створювати підтримку навколо продуктових рішень.

AI уже став частиною сучасної engineering-реальності, але в production highload-системах усе значно складніше. GenAI добре працює в демо та copilots, проте чи готовий він до real-time processing, великих навантажень і критичних production-сценаріїв? На панельній дискусії поговоримо про те, чому AI досі майже не став стандартом для highload-архітектур, де проходить межа між ML та GenAI, чому inference коштує дорого, а FinOps стає новим болем engineering-команд. Обговоримо on-prem vs cloud для AI workloads, реальні production-обмеження.

Практико-орієнтована архітектурна доповідь про інтеграцію AI-агента в операційний workflow highload data pipeline. Розглянемо сценарій каскадного збою: у пайплайн потрапляють пошкоджені дані, зависають черги Kafka, зростає навантаження на storage, тисячі Kubernetes pod’ів починають падати та пересоздаватися, деградує etcd, а PostgreSQL стає додатковою точкою навантаження. Також покажемо, як AI-агент, побудований на базі AWS Bedrock AgentCore, LangChain та MCP/Gateway, може виявляти ранні сигнали інцидентів, ізолювати corrupted messages, пропонувати human-approved remediation steps, захищати стабільність кластера та перетворювати noisy telemetry на конкретні кроки для відновлення системи.

Ще вчора AI був просто “помічником”, а сьогодні — впливає на найм, зарплати, кар’єрний ріст і саму роль developer-а. Junior-позиції зникають, code generation стає дешевшим, а компанії все частіше оцінюють не роки досвіду, а швидкість адаптації та вміння працювати з AI. На панельній дискусії поговоримо без рожевих окулярів: чи справді AI забирає роботу, чому senior-досвід більше не гарантує перевагу, хто виграє в новій AI-гонці — engineers чи prompt-native спеціалісти — та чи не перетворюється software engineering на зовсім іншу професію. Обговоримо, що буде цінуватись у developer-а через 2–3 роки, чи стане middle новим junior та чи встигає український IT-ринок адаптуватися до змін швидше за світ.

Що варто делегувати AI вже зараз, а що все ще потребує людини? На прикладі стрімінгового продукту поговоримо, як за допомогою AI-copilots оптимізувати QA-командам технічну рутину, масштабувати тестування, пришвидшувати релізи та залишати людям простір для дослідження продукту, UX і складних користувацьких сценаріїв

Більшість систем починаються з push, бо це здається природним — сервер знає, коли щось змінилось, і одразу повідомляє клієнтів. Але у масштабі push містить прихований множник витрат: підключені користувачі × відкриті об'єкти × частота оновлень. Кожна мілісекунда свіжості даних оплачується кожним підключеним користувачем — навіть тим, хто не дивиться на екран. Доповідь побудована на реальному production-кейсі у DraftKings. Розглянемо, як модель доставки даних визначає форму кривої витрат, а не лише профіль затримок. Пройдемо: — оригінальну push-систему та те, як вона накопичувала складність роками — точки болю при масштабуванні, які зробили її нежиттєздатною під піковим навантаженням — процес оцінки альтернатив, який привів до short polling — стратегію міграції без downtime у чотири фази Результати виявились контрінтуїтивними: pull-архітектура з коротким polling-ом показала кращу актуальність даних під піковим навантаженням при суттєвому зниженні споживання CPU та витрат на інфраструктуру. Доповідь завершується практичним фреймворком: коли обирати push, коли pull, і яке питання поставити першим.

Комунікація - одна з ключових навичок product-менеджера, яка напряму впливає на якість рішень, швидкість команди, довіру стейкхолдерів і карʼєрне зростання. Часто її сприймають як щось очевидне: ми всі щодня пишемо повідомлення, проводимо зустрічі, пояснюємо задачі, даємо фідбек і домовляємося з людьми. Через це багатьом здається, що з комунікацією в них усе добре. На практиці саме в комунікації часто ховаються найбільші втрати: нечіткі очікування, погано сформульований фідбек, зайві конфлікти, розмиті домовленості, рішення без buy-in та відчуття, що команда «не так зрозуміла». Для product-менеджера це особливо критично, бо його робота значною мірою тримається на здатності пояснювати, слухати, узгоджувати, впливати й допомагати іншим рухатися в одному напрямку. У доповіді Рей розбере, як виглядає сильна комунікація в product-менеджменті: як оцінювати власний рівень чесніше, де найчастіше виникають помилки, як говорити складні речі простими словами, та як давати фідбек так, щоб він справді допомагав людині й команді ставати сильнішими.

У цій доповіді ми розглянемо практичний кейс впровадження ефективного автоскейлінгу інфраструктури з використанням HPA, VPA та Cluster Autoscaler. Працюючи зі стандартним VPA, ми зіткнулися з обмеженнями: нестачею гнучкості в налаштуванні інтервалів обчислення та конфліктами при одночасній роботі з HPA. Тому ми вирішили створити власний кастомний VPA-контролер. У новому рішенні ми: - Забезпечили коректну спільну роботу VPA та HPA на одних і тих самих ресурсах. - Реалізували механізм фільтрації короткочасних піків CPU на етапі запуску подів. - Оптимізували архітектуру: об'єднали функціонал трьох стандартних компонентів у єдиний под. - Використали нові можливості In-Place Pod Resize, які з'явилися у Kubernetes 1.33. Головний результат: оптимізація споживання ресурсів та зменшення вартості інфраструктури на 20–40%.