Від еволюції архітектур до production-ready ШІ-систем: ключові висновки з QCon London 2026

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Особисті роздуми про корпоративний ШІ (enterprise AI), context engineering, еволюцію архітектури та про те, чому справжня робота починається вже після демо.

Мене звати Олег Цаль-Цалько, я технічний директор в EPAM Ukraine з 15-річним досвідом в IT та архітектурі. Зараз я займаюся цифровою трансформацією державного сектору та впровадженням ШІ. Нещодавно, під час робочого відрядження, я мав нагоду відвідати QCon London 2026 — одну з найавторитетніших глобальних конференцій для архітекторів та техлідів. Для мене було важливо використати цю можливість, щоб з перших вуст почути: що сьогодні реально будують у світі, з якими викликами стикаються інші компанії та експерти. Це дозволило звірити наші очікування з реальністю, порівняти власні спостереження з глобальними трендами і зрозуміти, де справжній сигнал, а де поки що більше хайпу.

Менше «блискучих» інновацій, більше реальних складних проблем та рішень

Я їхав на QCon з очікуванням почути топових спікерів, які розповідають про передові технології, нові фреймворки та протоколи, а також про найсучасніші рішення. Натомість значна частина виступів, які я відвідав, нагадувала радше історії «виживання» та відверті кейси компаній, що намагаються вирішувати практичні проблеми під жорстким тиском бізнесу.

На перший погляд, це звучить не так ефектно. Але насправді такий формат виявився доволі корисним. В EPAM ми співпрацюємо з багатьма клієнтами з різних індустрій, тому важливо розуміти, з чим стикаються інші компанії, де вони експериментують, а також які рішення зараз намагаються вивести на ринок стартапи. У цьому сенсі QCon нагадував не стільки вітрину красивих і блискучих технологій, а скоріше майданчик, де фахівці відверто ділилися тим, що насправді є складним на практиці.

Інший очевидний тренд — абсолютне домінування теми ШІ. Близько 80% доповідей, на яких я побував, так чи інакше стосувалися штучного інтелекту. Не берусь судити, добре це чи погано, мабуть, це цілком очікувано в епоху стрімкого розвитку ЩІ-екосистем. Проте не помітити цього було просто неможливо.

Також кидалося в очі те, що попри всю цю шалену динаміку інновацій, є багато невизначеності. У багатьох доповідях я чув, як команди відверто сумнівалися, чи правильний підхід вони обрали і чого варто очікувати далі. І це звучало дуже чесно, адже ми все ще перебуваємо на тому етапі, коли екосистема розвивається настільки швидко, що «золотих стандартів» просто не існує. Усі експерементують. Усі навчаються. Усі намагаються зрозуміти, що працює, а що ні.

Чого мені особисто трохи не вистачило на цій конференції, так це live demos. Останнім часом я часто бачу багато live coding sessions і hands-on демонстрацій того, як конкретний інструмент чи підхід реально працює на практиці. На QCon, принаймні в тих сесіях, де я був, такого було небагато. Конференція значно більше тяжіла до рефлексії та lessons learned, ніж до живих demo.

У компаній більше немає проблеми з ШІ-ідеями. У них є проблеми з інженерією ШI

Мій головний висновок із QCon London можна сформулювати одним реченням: найскладніше з ШI — це не вразити людей неймовірними можливостями штучного інтелекту під час Demo. Найскладніше — навчитися будувати production-ready AI-системи, які є надійними, відкритими, керованими й яким справді можна довіряти.

Ця тема звучала знову і знову у різних виступах: від ШІ-помічників для написання коду та систем оцінки якості до автономного code review та історій про впровадження ЩІ в корпоративному середовищі.

Ми вже явно виходимо з фази, коли головне завдання полягало в тому, щоб показати, що ШІ може генерувати код, відповідати на запитання або працювати як Copilot. Це вже зрозуміли усі. Тепер головне питання в іншому: чи можуть ці системи працювати в реальних бізнес-середовищах без компромісів, коли мова йде про якість, контроль, безпеку та зменшення витрат.

Один момент з keynote виступу про ШІ-асистенти для написання коду запам’ятався мені найбільше. Спікерка пояснювала, що більшість гучних історій успіху автономних ШІ-агентів, наприклад, створення C-компілятора, побудова браузера тощо, базується на добре відомих і детально описаних задачах, які мають детерміновані набори тестів та готові інструменти перевірки. Це кардинально відрізняється від хаосу enterprise-реалій і на практиці все виявляється далеко не таким захопливим і простим.

Саме тому я повністю погоджуюся з думкою, що час автономних команд ШІ-агентів для більшості enterprise-кейсів поки що не підходить. Так, технології стрімко розвиваються. Проте індустрія загалом та більшість великих компаній все ще не готові безпечно і надійно застосовувати повністю автономні команди агентів для серйозних бізнес-сценаріїв.

Ще один важливий аспект — це вартість. «Медовий місяць» закінчився. Як згадував у виступі один зі спікерів, на початку розробники могли витрачати лише 12 центів на на базові AI code completions, тоді як зараз при повноцінному AI-driven development cycle ці витрати можуть доходити в середньому до 300 доларів на одного розробника на день. Це величезна різниця. Мова вже не йде про звичайний zero-shot autocomplete. Ми говоримо про довгі та складні воркфлоу, використання різних інструментів , багатоетапне планування, code review та дедалі дорожчі цикли розробки.

Context Engineering стає однією з ключових дисциплін в Agentic AI

Найбільш практичною і водночас найбільш недооціненою темою конференції для мене стала тема Context Engineering.

Тут варто згадати про дві доповіді: «Context Engineering: Building the Knowledge Layer AI Agents Need» та «The Right 300 Tokens Beat 100k Noisy Ones: The Architecture of Context Engineering».

У першій доповіді привернула увагу аналогія з тим, як людина занурюється в контекст на новій роботі. Якщо ви просто дасте їй доступ до всіх внутрішніх систем, документації, чатів та репозиторіїв, це не означатиме, що вона реально зрозуміє всі процеси компанії та як знайти необхідну інформацію. Те саме стосується й ШІ-агентів. Доступ не дорівнює розуміння.

Звучить як щось очевидне, але на практиці багато команд досі діють так, ніби достатньо просто під’єднати якомога більше data sources, tools або MCP servers і проблема буде вирішена. Але це не так.

Один із цікавих моментів цієї доповіді був концепт «satisficing search», коли перший більш-менш прийнятний результат зупиняє агента від глибшого дослідження, яке в деяких випадках насправді потрібно, аби знайти правильну відповідь на питання.

І це саме той неочевидний сценарій збою (failure mode), який стає критичним у продакшені. Агент може здаватися швидким та ефективним, але при цьому принципово помилятися у важливих речах, бо лише поверхнево шукає інформацію.

Спікер також спростував три поширені міфи:

• naive RAG — це і є мій context engine;
• просто підключіть побільше MCP і все запрацює;
• збільшення контекстного вікна вирішить усі проблеми.

І я погоджуюся зі спікером, що всі три тези — це небезпечні спрощення.

Naive RAG зазвичай недостатньо, оскільки він рідко забезпечує ту точність та релевантність, яких насправді вимагають замовники. Підхід «good enough» retrieval може працювати для demo, але багато клієнтів хочуть значно вищий рівень точності та консистентності у відповідях. А це означає, що потрібні більш складні стратегії пошуку релевантних даних.

Більше того, бажання просто «згодувати» моделі якомога більше контексту — теж, як правило, не працює. Це призводить до так званого перенасичення контекстом (context flooding). Коли ви забиваєте контекстне вікно занадто великою кількістю інформації, LLM починає забувати важливе, більше галюцинувати й повільніше відповідати, бо їй потрібно опрацьовувати значно більше токенів. Великі контекстні вікна корисні, але це точно не silver bullet.

Практичний висновок для мене тут простий: потрібен context engine, здатний постачати правильний контекст правильній моделі в правильний момент часу.

Доповідь від Unblocked добре сформувала вимоги до такого context engine :

• Уніфіковані джерела даних — звести розрізнені знання з репозиторіїв, документів, чатів, тікетів та інших систем в один придатний для роботи шар даних;
• Вирішення конфліктів — вміти працювати з суперечливою, застарілою або дубльованою інформацією в різних системах;
• Цільовий пошук — підтягувати тільки найрелевантнішу інформацію під конкретну задачу, а не звалювати в контекст усе підряд;
• Управління даними — гарантувати, що формування контексту враховує права доступу, обмеження й compliance-вимоги;
• Оптимізація токенів — оптимізувати розмір контексту щоб не перевантажувати модель зайвою інформацією;
• Персоналізована релевантність — адаптувати контекст під конкретного користувача, роль, workflow або use case.

Сесія від Baruch Sadogursky та Patrick Debois підсилила той самий меседж, але з трохи іншого ракурсу. Вона була інтерактивною, практичною й дуже вдало підсвітила анти-патерни по роботі з контекстом:

• «Переповнений» промпт — коли в prompt запихають забагато інформації наперед, через що контекст стає роздутим і не масштабується;
• Невідповідний інструмент — коли один retrieval-механізм намагаються використовувати всюди, замість того щоб розумно комбінувати lookups, embeddings, tools, MCPs і memory strategies;
• Агент-«золота рибка» — коли агент або забуває все занадто швидко, або навпаки запам’ятовує все підряд без розбору;
• Оцінка «по вайбу» — коли ефективність пошуку даних оцінюється «по відчуттях», а не через реальні тести та валідації

Мені сподобався цей фреймінг, бо він переводить проблему в дуже конкретну площину. Це не якась абстракція. Це класична інженерна проблема.

Для корпорацій context engineering є особливо складним, тому що дані розкидані по багатьох розрізнених системах, а якість даних дуже часто далека від ідеалу. Правило «garbage in, garbage out» ніхто не відміняв. Тому фраза про те, що «контекст важливий» правильна, але я б додав, що «якість самих даних ще важливіша».

Саме тому доповіді про онтологію, семантичні шари та графи знань (knowledge graphs) видалися мені доволі релевантними. Вони показують більш структурований підхід до того, як перетворювати сирі дані на змістовні знання, з якими агенти реально можуть працювати.

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

ШІ прискорює розробку, але code review та контроль якості стають ще більшим викликом

Ще один чіткий сигнал із QCon: ШІ справді прискорює software development, але водночас виникають нові питання по процесу code review, підтримки коду та відповідальності (code ownership).

Хорошим прикладом цього стала доповідь від Spotify: «Rewriting All of Spotify’s Code Base, All the Time». По суті це була історія про те, як вони намагалися автоматизувати типові задачі розробки софту ще в ті часи, коли не було ні Claude Code, ні інших зрілих ШІ-інструментів, як зараз. У певному сенсі вони просто винаходили свій власний AI SDLC, використовуючи Slack як основний інтерфейс взаємодії з AI-агентами.

Особливо запам’яталася одна цифра: зараз у них близько 1000 AI-generated PRs мерджаться в середньому за 10 днів.

Для когось це звучить вражаючи. У мене ж одразу виникає інше питання: у якому стані опиниться кодова база, якщо мерджити AI-згенеровані зміни в таких масштабах?

І саме тут code review перетворюється на bottle neck. Чому? Тому що кількість AI-generated PRs росте значно швидше, ніж фізична спроможність людей якісно їх перевіряти. І, на відміну від генерації коду, code review досі вимагає критичної оцінки, розуміння контексту та відповідальності. Саме тому я з обережністю ставлюся до дедалі більшої спокуси спростити вимоги до code review заради швидкості.

Так, у кількох доповідях говорили про сценарії, де можливо використовувати більш автономне ревью коду або взагалі auto-approval для менш ризикованих змін у коді. І я дійсно бачу в цьому сенс. Але тільки якщо є сильна модель контролю процесів: усталені інженерні практики, конвенціі, guardrails, детерміновані CI pipelines, етапи контролю якості і чітке оцінювання ризиків.

Саме це було одним із найважливіших меседжів у доповіді Teaching Engineers, Trusting AI: How Education Enabled Autonomous Code Review. Мені сподобався фокус на:

• детермінованих CI quality gates;
• оцінці ризиків для auto-approvals;
• guardrails щодо того, яким PRs взагалі можна робити auto-approve;
• feedback loops для корекції scoring logic з часом.

Оце для мене і є прагматичний підхід. На мій погляд, ефективна модель ревью коду в епоху ШІ має включати:

• risk scoring для PRs;
• AI agent review поруч із human review;
• interactive conversational review process між людиною та AI.

До речі, слухаючи цю доповідь, я зловив себе на думці, що простий чат з ШІ під час ревью коду може бути дуже корисним: швидко уточнити, що саме змінилося, чому саме так, які припущення були зроблені і які ризики варто перевірити. Це може реально прискорити ревью, не знімаючи відповідальності з інженерів.

Бо якщо занадто послабити review, головна небезпека полягає в тому, що розробники можуть почати втрачати ownership над кодом, тоді як відповідальність усе одно залишається на нас.

І це точно не те, яким шляхом ми маємо йти.

Найкращий архітектурний урок узагалі був не про ШІ

Попри те, що більша частина конференції була про ШІ, для мене була дуже корисна доповідь від Netflix From DVDs to Global Streaming: How Netflix’s Commerce Architecture Actually Evolved.

Що зробило її сильною — це не лише масштаб Netflix, а й наочність історії. Їхня архітектура еволюціонувала з часом у відповідь на бізнес-зміни, а не тому, що хтось із самого початку створив ідеальну архітектуру..

Два показові приклади, які вони навели:

• додавання додаткових користувачів до головного акаунту;
• розширення їхнього бізнесу на нові країни з їхніми специфічними вимогами.

Це були не «просто нові фічі». Це були архітектурні зміни. І вони змушували систему еволюціонувати.

Також звернув увагу на один практичний приклад: у різних країнах Netflix показував користувачам опції використання платіжних систем, які ще навіть не були повністю імплементовані. Це робилося для того, щоб зібрати реальну статистику уподобань та отримати дані від користувачів, перш ніж вкладатися в реалізацію. Це гарне нагадування про те, що архітектура та продуктове бачення дуже часто тісно переплетені.

З більш класичних історій там також були:

• breaking monolith into microservices;
• розділення real-time і batch трафіку;
• процесинг сильних сплесків трафіку під час великих подій.

Приклад із боксерським поєдинком Jake Paul vs Mike Tyson дуже добре це ілюстрував: Netflix довелося тримати sign-up traffic spike під час події, який досягнув позначки у 65 мільйонів одночасних стрімів по всьому світу і 38 мільйонів тільки у США.

Але фраза, яка запам’яталася мені найбільше, звучала так:

«Системи пам’ятають ухвалені рішення набагато довше, ніж про них пам’ятає бізнес» (Systems remember decisions much longer after Business forget them)

Це дуже сильна цитата. Кожен, хто працював із довготривалими enterprise-системами, прекрасно розуміє, про що йдеться. Їхній фінальний висновок передав цю суть ще точніше:

«Найкращі системи виживають не тому, що були ідеально спроєктовані, а тому, що здатні еволюціонувати разом зі зміною реальності». (Great systems don’t survive because they were perfectly designed, but because they keep evolving as reality changes)

На мій погляд, це один із найважливіших архітектурних уроків не лише для стрімінг платформ, а й для enterprise систем загалом. Справжня архітектурна майстерність — це не створити ідеальну архітектуру з першого разу. Це побудувати систему, яка здатна адаптуватися, коли бізнес-вимоги постійно змінюються.

Невеликий, але важливий стратегічний месседж: суверенітет сьогодні важливий як ніколи

Ще одна доповідь, яка запам’яталася мені з дещо іншої причини — це виступ Martin Kleppmann «Mitigating Geopolitical Risks with Local-First Software and atproto».

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

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

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

Я б не робив цю тему центральною в статті, але вона точно варта уваги. Не кожна організація буде будувати суверенні системи. Це непросто і не завжди економічно доцільно. Але базовий посил в тому, що сьогодні окрім того, що будь-що в будь-який момент може зламатися, так ще й може стати закритим для використання. І це не повинно зупинити ваш бізнес. План B має бути завжди. І в житті, і в software development.

Він також торкнувся atproto як прикладу децентралізованого незалежного протоколу створеного для соцмереж та порівняно нової концепції local-first software, в якій поєднано найкраще від двох світів: real-time collaboration на кшталт Google Sheets і version control на кшталт Git.

Що досі часто не розуміють бізнес-лідери та інженери

Багато з почутого на QCon лише підтвердило думку: як інженерні, так і бізнес-лідери мають переосмислити свої очікування щодо AI.

Що engineering leaders досі часто недооцінюють

Engineering leaders досі недооцінюють, скільки класичної інженерії насправді потрібно навколо ШІ:

• архітектура
• спостережуваність (observability);
• управління та контроль (governance);
• етапи контролю якості (quality gates);
• оцінювання та валідація результатів (evaluation);
• процеси перевірки та рев’ю.

Водночас вони часто переоцінюють те, що ШІ-агенти вже сьогодні можуть безпечно працювати без контролю у ентерпрайз системах.

Неправильне питання, яке сьогодні часто ставлять: «Як швидко ми можемо розгорнути ШІ по всій організації?»

Набагато краще ставити питання:
«Де саме ШІ може принести вимірювану цінність, з яким рівнем контролю та з яким прийнятним рівнем ризику?»

На мою думку, не можна пропускати ревью, guardrails і тестування у гонитві за швидкістю впровадження ШІ, яке очікує топ-менеджмент і тому що згенерований код «виглядає нормально».

Натомість найцінніша експертиза, яку варто нарощувати всередині компанії — це вміння поєднувати сильні інженерні практики із ШІ-грамотністю, context engineering, чіткими процесами evaluation та governance. Іншими словами: не просто впровадити ШІ-інструменти, а побудувати навколо них надійну операційну модель. Критичне мислення досі важить надзвичайно багато. Завжди вмикайте голову.

Що бізнес-лідери часто недооцінюють

Бізнес-лідери часто очікують, що штучний інтелект швидко забезпечить масштабне зростання продуктивності по всій компанії, і водночас принесе помітне збільшення доходів та маржинальності. Але операційна реальність виявляється значно складнішою. Цінність від впровадження ШІ є неоднорідною і результат тут дуже залежить від use-cases, якості даних, інженерної складності, системи контролю та зрілості процесів.

Один із найбільш недооцінених бізнес-ризиків — це впровадження ШІ у чутливі бізнес-процеси без достатнього рівня контролю, прозорості та відповідальності.

Справжні інвестиції — це не просто купівля ліцензій на нові інструменти. Це також інвестиції в:

• Інженерну експертизу;
• навчання команд;
• система контролю;
• організаційні зміни.

І для оцінки успішного використання ШІ правильні KPIs — це не кількість пілотів, прототипів або ШІ-тулів, які компанія формально «запровадила».

Набагато краще дивитися на конкретний вплив ШІ на певні бізнес-процеси та трансформацію бізнесу в цілому за умови контрольованих ризиків та прогнозованих витрат.

На мою думку, це набагато більш важливі речі.

Підсумки

Виступи на конференції QCon London 2026 ще раз переконали мене в тому, що enterprise та індустрія загалом усе ще перебувають на етапі турбулентності (storming phase). Постійно з’являються нові інструменти, продукти, фреймворки та моделі, і досі немає універсальних патернів чи «золотих стандартів», з якими погоджувалися б усі.

Проте деякі сигнали вже вимальовуються досить чітко:

• Ринок рухається від copilots до agentic AI, хоча цей рух іде не так швидко, як усім хочеться.
• Управління контестом стає однією з найважливіших дисциплін у практичному використанні агентських систем.
• Ревью коду, контроль якості і підтримка коду набувають більшого значення на тлі того, як ШІ прискорює написання коду.
• Онтології, семантичні шари даних і графи стають дедалі більш релевантними, коли enterprise намагається перетворити сирі дані на систематизовані знання для систем на базі ШІ.

І найголовніше: справжня складність на сьогодні — це вже не показати вражаюче DEMO на якійсь новій моделі, а побудувати production-ready АІ-систему із достатнім рівнем якості, надійності і довіри.

Якби мені довелося поставити на одну річ, яка буде найпотрібнішою enterprise найближчим часом, це була б, імовірно, не якась конкретна модель, фреймворк чи інструмент.

Це було б критичне мислення.

Тому що саме зараз, як ніколи, нам потрібні прагматичний підхід, реалістичні очікування і достатній рівень інженерної дисципліни, щоб справді використати ту можливість яка є.