А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 і складних користувацьких сценаріїв

Нещодавно Superhuman (раніше Grammarly) запустила Superhuman Go — AI-асистента, який працює поруч із вами на кожній платформі. Щоб його створити, нам було потрібне масштабоване рішення, яке підтримує необмежену кількість агентів, динамічно формує інтерфейс користувача та виглядає однаково на всіх підтримуваних десктопних і мобільних платформах. Приєднуйтеся, щоб дізнатися, як ми знайшли рішення для цього інноваційного продукту

Про що: - Які growth-челенджі визначатимуть 2026 рік. - Як AI змінює швидкість запуску MVP і продуктових експериментів — і чому швидкість без стратегічного фокуса не створює sustainable growth. - Чому для масштабування вже недостатньо CRO та performance-маркетингу. - Як використовувати AI для research, прототипування, продуктових драфтів і швидшого запуску рішень.

У цій доповіді Владислав розповість про його шлях приборкання AI: від простого Plan Mode в Cursor/Claude до складних систем документування. Він розбере, чому GitHub Spec Kit виявився занадто важким, як ADR (Architecture Decision Records) допомагають агентам не «губити» контекст між сесіями і чому OpenSpec від Y Combinator (Fission-AI, W26) став золотою серединою. Ключова теза: якість коду на виході = якість специфікації на вході. Разом поміркуємо про трансформацію ролі розробника — від «кодера» до «архітектора специфікацій».