Ойкумена і фронтир: карта майбутнього Software Engineering та як не заблукати

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

Привіт! Я — Микита Берегуля , Lead Software Engineer у компанії EPAM. Спеціалізуюсь на team leadership, backend та data engineering. В компанії я допомагаю організовувати менторинг джуніорів та технічне ком’юніті (ресерчі, мітапи, статті). За останні два роки я також поглибив академічні знання, закінчивши магістерську програму Data Science в УКУ.

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

Основна моя думка — навички, пов’язані з простим накопиченням знань та відтворенням рішень, «дешевшатимуть». Причому швидше, ніж раніше. Водночас здатність досліджувати невідоме та знаходити рішення залишатиметься цінною. Щоб розгорнути цю ідею, я пропоную дві метафори — ойкумени та фронтиру.

Ойкумена знань

Ойкумена — це давньогрецьке слово, що означає частину світу, відому людству. На старих картах за межами досліджених територій залишалася порожнеча. Ми постійно намагалися її зменшити: вирушали за її межі, описували нові землі й домальовували території.

* Всі зображення згенеровані ChatGPT 5.6 Sol

Так само людство збільшує ойкумену знань. Це така собі уявна глобальна «Вікіпедія», яка постійно стає детальнішою, доступнішою та краще структурованою. Мільйони людей із різною мотивацією безперервно генерують і тестують нові ідеї.

Стартапи шукають інновації, щоб закріпитися на ринку. Університетські дослідники намагаються перевершити результати SoTA у певному бенчмарку. Подинокі open-source ентузіасти створюють проєкти для розв’язання загальної проблеми, котра, як вони вважають, не має належного рішення. Усі вони працюють на межі відомого — на фронтирі.

Фронтир знань

Фронтир — це територія не сформованого кордону. Територія, де немає правил, інфраструктури й маршрутів. Найвідоміший історичний приклад — Дикий Захід США за часів його освоєння.

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

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

Технологічні прориви

У певний момент накопичений результат спричиняє прорив (можливо, це ще можна назвати досягненням, але в мене в голові англ. слово breakthrough). Це не обов’язково винахід із чистого аркуша. Часто проривом стає нова комбінація вже відомих ідей. Таких прикладів безліч — це може бути не лише Software Engineering, а й будь-що: від конвеєра для виробництва автомобілів до кас самообслуговування в супермаркеті. Візьмемо щось ближче до нашої галузі. Як приклад, мікросервісна архітектура.

Одним із піонерів у цій галузі була компанія Netflix разом з її хмарним архітектором Adrian Cockcroft. На початку 2010-х років вони робили дуже технічно навантажені речі, та наявних підходів не вистачало — вони почали шукати нові. На той час інженери Netflix були одними з найбільш високооплачуваних у галузі, бо вони робили речі, котрі ніхто не робив і не знав, як їх робити, і найголовніше, у них це виходило. Хоча вони не були єдиними, хто стикався зі схожими проблемами, успіх їхніх продуктів призвів до того, що їх почали копіювати інші.

Люди почали переносити цей підхід у інші галузі. Мікросервіси пробували використовувати всюди, де треба і не треба. Накопичувалися знання. Почали з’являтися статті та книги. У березні 2014 року Martin Fowler опублікував фундаментальну статтю «Microservices: a definition of this new architectural term». У 2018 році виходить книга Microservices Patterns за авторством Chris Richardson, а також запускається сайт microservices.io. Якщо Netflix спрямував імпульс назовні від центру ойкумени, то інші почали перевикористовувати цю ідею, посилюючи прорив у бічній площині.

У 2026 році це вже надзвичайно досліджений підхід. Вже зроблено таку велику кількість помилок і структуровано таку велику кількість інформації, що будь-хто, кому потрібно імплементувати мікросервіси, матиме відповіді на більшість своїх питань (хоча це не гарантує адекватної імплементації, але точно збільшує шанси не зробити очевидних помилок). Тепер ці знання має не маленька група провідних інженерів з Netflix, а величезна кількість людей з усього світу, що девальвує їхню цінність. Це, з одного боку, робить їх більш доступними для бізнесу, з іншого — інженерам доведеться доводити, що ті компенсації, які вони отримують, є обґрунтованими. Адже суттєво збільшилася густина ойкумени у тій області, де вони працюють.

Густина ойкумени

Ойкумена знань зростає не тільки в об’ємі, а й у своїй «густині». Пригадайте умовну технологію, що щойно з’явилася та почала набирати популярність. Наприклад, Serverless. Це була дивина на початку, котру небагато людей знали, як готувати (чого тільки варті Spring Boot застосунки, котрі портувалися as-is, коли AWS Lambda тільки з’явилася, та мали холодний старт під 10 секунд), але сьогодні вона має рецепти на будь-який випадок. Ті, хто починають із нею працювати зараз, за декілька гайдів та відео на YouTube отримають інформацію й уникнуть шишок, котрі люди набивали місяцями в production-середовищах. Звісно, ті, хто тільки починає працювати з FaaS, не матимуть усього того практичного досвіду, але найбільш критичні та необхідні знання доволі швидко стануть частиною спільного досвіду.

В якийсь момент густина певної частини ойкумени стає настільки великою, що ці знання самі по собі не дають конкурентної переваги. Як історичний приклад, професія HTML-кодера. У 2016 році вона розглядалася як точка входу в індустрію — ось стаття на DOU того часу: https://dou.ua/lenta/articles/html-coder-position/. Очікування на той час були такі, що людина візьме макет сайту в Photoshop і зробить HTML і CSS для сторінки. У 2026 році це може зробити така велика кількість людей, а базові знання веб-розробки настільки розповсюджені, що професія просто зникла, та була поглинута іншими, які охоплюють ширші області ойкумени. Потрібно також зауважити, що саме завдяки тому, що у нас є приклад мільйонів веб-сторінок та мільйонів вкладених людино-годин, ці знання стають надпровідником для АІ-інструментів.

AI надпровідник

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

Висока ймовірність, що модель зможе відтворити це рішення, а навіть якщо ні — спрямувати людину у правильному напрямку. Я пам’ятаю свою роботу із джуніорами декілька років тому. Потрібно вирішити проблему, використовуючи нову бібліотеку. Ми відкриваємо Javadocs. Переходимо між класами. Порівнюємо перевантажені версії методу. З’ясовуємо, у якій версії з’явився потрібний параметр. Потім відкриваємо source JAR, оскільки документація не пояснює його поведінку. Далі знаходимо issue на GitHub, де хтось випадково залишив єдиний корисний коментар. Сьогодні до мене джуніори вже не підходять із такими питаннями. Я вже не можу прийти та порадити використати маловідомий додатковий CLI-флаг або JPA-анотацію, яка круто покращить рішення проблеми, над якою працює людина, та викличе в неї вау-ефект: «А що так можна було?», бо всі ці флаги їй порадить LLM краще за мене. «Ексклюзивність» цих знань суттєво впала, бо отримати їх стало легше.

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

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

Циклічність проривів

Протягом усього існування людство робить відкриття та досягає наукових успіхів. Ситуація з девальвацією цінності певних знань через зростання їхньої доступності відбувалася завжди. Колись уміння читати й писати було рідкісною цінною навичкою. Тобто ми доволі довго жили у парадигмі: з’являються нові наукові досягнення, ці знання необхідно операціонізувати, для цього не вистачає людей, створюється дефіцит пропозиції, зростає вартість цих знань, через це все більше людей фокусуються на їх отриманні, що робить ці знання більш доступними, поки ми не дійдемо до певної нижньої межі їх «ціни», яка часто пов’язана із кількістю середнього витраченого часу на навчання.

Нові виклики, до яких потрібно приготуватися, — це те, що ці цикли траплятимуться частіше. Ми суттєво швидше пройшли шлях від появи електричної лампочки до атомного реактора, ніж від уміння розводити багаття до тієї самої лампочки. Ми зростаємо експоненціально, і це вимагає від нас швидко й постійно навчатися, щоб залишатися актуальними на ринку праці. На форумі часто можна почути невдоволення тим, що зараз у джуніор-вакансіях вимагають те саме, що й 5 років тому від сеньйора. З появою АІ це лише загострилося. Багато людей скаржаться на те, що вони не встигають заглибитися і в те, що роблять, і, на мою думку, тут необхідно шукати шляхи адаптації, бо потяг не зупиниться та швидкість буде зростати й далі. Для цього в навчанні та роботі я раджу чітко окреслити яку область ойкумени ви зараз опрацьовуєте.

Області ойкумени

Перша область — центральна, найбільш цілісна частина ойкумени. Тут потрібно швидко «рухатися», бо для цього є всі необхідні інструменти. Якщо вам потрібно опанувати мову програмування чи основу лінійної алгебри, це має відбуватися максимально швидко. Ці знання вже детально «розжовані». Штучний інтелект може розжувати їх, підлаштовуючись під вас, навести десятки прикладів і знайти сотні типових задач. Деякі люди, і я так само, використовують персоналізовані системи накопичення знань а-ля «second brain» на базі Obsidian, Notion або будь-яких інших інструментів, щоб тримати все це в голові. Ці знання стануть базою, щоб працювати на фронтирі та в суміжних областях. Їх треба швидко поєднувати з наступним рівнем, бо самі по собі вони можуть не мати критичної ваги, як у прикладі з HTML і CSS.

Друга — це розширення фронтиру вбік. Вже існує прорив і відоме базове ключове рішення, яке потрібно адаптувати в багатьох доменах. Цьому рішенню може знадобитися додаткова інфраструктура. Як приклад — агентні системи та супутні технології, які їм необхідні й що зараз швидко розвиваються. Тут важливо добре розумітися на базових концепціях, на яких заснований прорив, та суміжних ідеях, у котрі ви його збираєтеся тягнути. Чудово працює «сила слабких зв’язків». Та сама агент-система у сфері ІТ-підтримки та у медичній сфері — це зовсім різні речі. Круто, якщо є розуміння «віддалених» областей.

Третє та останнє — це ривок фронтиру вперед або у далечінь. Це аналіз і дослідження — пошук ще невідомого рішення. Як приклад академічної роботи, де ставиться питання, пропонуються вектори його атаки, відбуваються серії експериментів із тестами, що його підтверджують або спростовують. Тут варто подумати про академічну освіту та пошук групи, до якої можна приєднатися. Майже усі провідні дослідники AI вийшли з академічного середовища. На досвіді свого навчання в УКУ можу сказати, що такі групи і оточення є і в Україні. Загалом, дотичність до «академії», на мою думку, надаватиме конкуренту перевагу в майбутньому завдяки умінню відстежувати сучасний state-of-the-art і застосовувати дослідницький підхід. В межах нашого технічного ком’юніті всередині компанії ми плануємо запустити серію регулярних івентів, присвячених розбору та аналізу наукових статей у Computer та Data Science, щоб познайомити з цим більше людей.

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

Точки росту

Ретроспективно проаналізувавши Software Engineering як домен, можна окреслити три технологічні кити, на яких він стоїть: комп’ютерні потужності, обсяг даних та ефективність алгоритмів. Всі вони одна за одною тягнуть один одного та створюють для один одного нові завдання. Збільшення комп’ютерної потужності та покращення «заліза» дозволяють обробляти більші дані; для цього потрібні ефективніші алгоритми — і так по колу. Наприклад, у нас були алгоритми для роботи з нейромережами, які з’явилися доволі давно. Але для їх операціоналізації спершу не вистачало даних, потім — обчислювальної потужності. Поява інтернету вирішила перше; поява хмарних обчислень і нове залізо — друге.

Якщо стоїть задача обрати фронтирну область, я би заглиблювався або в ці три самі по собі, або в їх операціоналізацію в якійсь іншій прикладній сфері. Наприклад, ми бачимо цю взаємодію в українському міл-теку, який дає поштовх Computer Vision тим, що в нас є обмежене залізо, унікальні дані та потреба адаптувати алгоритми. Відмічу, що фронтир може бути не лише глобальним. Він також може бути в межах країни (робота над національною LLM-моделлю), компанії (впровадження machine learning-алгоритмів в українському маркетплейсі з метою знаходження кращого розташування точки видачі), команди (створення кастомного MCP-сервера для автоматизації розробницьких задач) або це може бути ваш особистий фронтир.

Мій вибір

Я для себе вирішив сфокусуватися на Data Science та його операціоналізації. Взяти як основу свій досвід у backend-розробці та розширювати його у бік Data Engineering, Machine Learning, MLOps та інших фронтирних областей. Велика частина цього домену доволі довго залишалася прерогативою великих компаній, але, відповідно до того, що я бачу, зараз відбувається стрімке розширення фронтиру в бік — те бічне розростання, про котре я говорив — і на горизонті велика кількість юз-кейсів, котрі можна провалідувати. На цьому хочу завершити та побажати вам рухатися уперед за межі відомого!