«Ринку джунів у DevOps гайки»: DOU Live про AI, професію та майбутнє початківців

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

Чи варто у 2026 році заходити в DevOps, якщо ви тільки починаєте кар’єру? І що взагалі тепер означає Junior DevOps, коли частину задач, на яких раніше вчилися молодші спеціалісти, уже можна віддати AI?

Про це 9 серпня говорили на нашому DOU Live з Артемом Гречаниченком, Юрієм Рочняком, Миколою Аврамуком, Всеволодом Поляковим і Денисом Васильєвим.

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

Модерував дискусію та готував питання — Артем Гречаниченко.

Публікуємо текстову версію основних тез дискусії.

«Я не вірю в класичних Junior DevOps»

— Чи наймали ви протягом останнього року Junior DevOps? І чи може людина без попереднього досвіду взагалі зайти в цей напрям?

Всеволод Поляков Head of Engineering у Let’s Enhance

«Я не вірю в класичних Junior DevOps. Ніколи особливо не вірив і зараз не вірю.

Я наймав джунів, які до цього були сеньйорами або лідами в інших компаніях чи напрямах. Якщо людина була senior developer або, наприклад, senior DevOps в іншому контексті, вона може змінити напрям і впевнено бути junior чи middle у новій для себе сфері.

А от взяти trainee, людину взагалі без досвіду, і закинути її в DevOps — це зовсім інша історія.

Я зараз багато співбесідую людей з різних країн і бачу, як кандидати намагаються заходити без знань, але з AI. Людина може написати, що знає Advanced Python чи Advanced Scripting, а потім не знати, що таке цикли або умовні конструкції. AI дуже спростив можливість імітувати роботу, а не робити її.

Але світчитися в DevOps цілком реально. Часто люди переходять із розробки, системного адміністрування, networking. Наприклад, senior developer може захотіти перейти в infrastructure або platform engineering просто тому, що йому це цікавіше.

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

Артем Гречаниченко Founder & Mentor у DevOps01, Team Lead SRE у Temabit

«Я теж не вважаю DevOps entry-level позицією.

Коли до мене приходять на консультацію і питають: „Скільки часу мені потрібно, щоб стати Junior DevOps?“, я спочатку питаю: „А навіщо ти взагалі хочеш іти в цей напрям? І чи готовий ти витратити два-три роки, щоб отримати базу?“»

Юрій Рочняк звернув увагу ще на одну проблему: єдиного стандарту тайтлів немає. Те, що в одній компанії називається Junior, в іншій може бути Middle, а senior в одному напрямі після переходу в інший формально може стати junior.

Та й сам DevOps — дуже широкий тайтл. В одній компанії це може бути робота майже software engineer із внутрішнім інструментарієм, в іншій — переважно Terraform, Kubernetes та інфраструктура.

«А що ми будемо робити через п’ять-десять років?»

— Якщо компаніям зараз не дуже вигідно наймати джунів, звідки тоді братимуться майбутні мідли та сеньйори?

Юрій Рочняк CatOps Engineer

«Оце якраз велика структурна проблема.

На короткому горизонті з точки зору компанії може справді не бути сенсу брати junior. Є досвідчені кандидати, ринок звузився, частину простої роботи можна автоматизувати. Але що ми будемо робити через п’ять-десять років? Цього зараз ніхто не знає».

Артем Гречаниченко Founder & Mentor у DevOps01, Team Lead SRE у Temabit

«Senior не з’являється з повітря. Людина в певний момент усе одно має побути junior, вчитися, робити помилки, накопичувати досвід. Раніше був доволі зрозумілий шлях. Є задачі, якими middle і senior не дуже хочуть займатися: якийсь технічний борг, оновлення модуля, дебаг сервісу, читання логів, документації. Junior отримує ці задачі й поступово набиває руку.

А тепер якраз значну частину такої роботи дуже легко скинути на AI.

Тому питання навіть не лише в тому, чи AI забрав вакансії у джунів. Питання в тому, де тепер джун має отримати той досвід, завдяки якому він стане middle».

«Ринку джунів у DevOps і так було нелегко, а зараз йому взагалі гайки»

Втім, це не означає, що зайти в професію неможливо.

Спікери радили не зациклюватися лише на вакансіях зі словом Junior. Через різницю в грейдах позиція, яку одна компанія називає Middle, за вимогами цілком може відповідати junior-рівню в іншій.

Так само важливо мати можливість показати щось більше, ніж список технологій у CV.

Артем Гречаниченко Founder & Mentor у DevOps01, Team Lead SRE у Temabit

«У мене самого перед DevOps був бекграунд у телекомунікаціях, системному адмініструванні, автоматизації тестування. Мені потім треба було довчити тільки cloud — і перехід був значно простішим.

Тому якщо в тайтлі написано Junior DevOps, це ще не означає, що туди можна зайти зовсім без досвіду».

Всеволод Поляков Head of Engineering у Let’s Enhance

«Я б дивився на практичні сертифікації, Kubernetes, Terraform, Linux — будь-що, що може показати людині на іншому боці співбесіди, що ви справді щось робили й щось знаєте.

А далі найважливіше — постійно вчитися.

Я часто питаю на співбесідах: „Що ви вивчили за останні шість місяців?“ Якщо компанія бере людину на рівень, який де-факто близький до junior, їй передусім потрібен хтось, хто продовжуватиме розвиватися. Не можна рік тому отримати сертифікацію, потім рік форматувати YAML і вважати, що цього достатньо.

І ще важливо думати та аналізувати те, що ви робите. Не просто: „Мені сказали підняти Kafka — я підняв Kafka“. А навіщо тут Kafka? Яку проблему ми розв’язуємо? Чому прийняли саме таке рішення? Чи потрібна вона нам узагалі?»

«Кіт уже вибіг з мішка. Забороняти AI немає сенсу»

— Ви взяли на роботу молодого спеціаліста. Не нульового, світчера з технічним бекграундом. Як тоді його навчати? Забороняти використовувати AI на перших етапах?

Юрій Рочняк CatOps Engineer

«Не думаю, що заборона має сенс. Кіт уже вибіг з мішка.

Для мене AI — це tooling. Головне — не сприймати його як магію. Людина отримує відповідь і може бігати з нею зі словами: „Машина сказала, що треба так“. Але іноді справді треба так, а іноді машина сказала повну дурню. Треба вміти це відрізняти.

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

Оце, мені здається, і є цікавою зміною».

Всеволод Поляков Head of Engineering у Let’s Enhance

«А я б сказав, що seniority зараз особливо добре видно через знання інструментів.

AI погано вибирає інструмент. Він може на початку припустити: „Зробімо це через RabbitMQ“, а потім мучити RabbitMQ до останнього, хоча давно треба було перейти на Kafka чи NATS. Він не завжди добре ухвалює архітектурні й проєктувальні рішення. Тому seniority — це значною мірою знання того, які інструменти існують, як вони працюють, у чому їхні обмеження і коли який використовувати.

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

Якщо людина питає: „Що краще — RabbitMQ чи Kafka?“, я можу сказати: „Іди спочатку запитай AI“».

Денис Васильєв DeadOps

«Якщо говорити про складні реальні проєкти, то межі AI дуже швидко стають помітними.

Код він пише плюс-мінус нормально. Але коли доходиш до складних алгоритмів, архітектури, проєктування — без людського досвіду воно поки нормально не летить».

«Щоб чогось навчитися, це все ще треба простраждати»

— Але якщо AI одразу дає рішення, чи не зникає сам процес навчання?

Юрій Рочняк CatOps Engineer

«Тут треба розділяти desired outcome і desired output.

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

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

Можна робити homelab, recreational coding, якісь канонічні задачі, LeetCode. Для співбесіди LeetCode, можливо, вже не настільки потрібен. У нас, наприклад, є співбесіди, де людина може використовувати AI й розв’язувати задачу разом із ним. Але для навчання такі задачі можуть залишатися дуже корисними. Береш нову мову і ввечері сам проходиш кілька задач. Простраждав і щось у голові залишилося.

А ще я помітив, що втрачаю терпіння.

Раніше, якщо я чогось не розумів, міг довго сидіти, шукати, читати, гуглити. Зараз я намагаюся спочатку сам піти в пошуковик, щось знайти, але проходить 10–20 хвилин — і я вже такий: „Claude, давай, що там?“».

«Агент не зацікавлений у тому, щоб я став сеньйором»

Микола Аврамук AIOps Engineer

«Я якраз доволі серйозно задумувався над цією проблемою.

Я middle engineer, який рухається до senior. Моя мета — мати достатньо досвіду й упевненості, щоб самостійно розв’язувати складні проблеми. Коли ти починаєш працювати з агентом, він у цьому взагалі не зацікавлений. У нього немає мети зробити так, щоб я став senior.

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

І тут виникає небезпека.

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

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

Всеволод Поляков Head of Engineering у Let’s Enhance

«Але я б сказав, що ця проблема існувала й до AI.

Я пам’ятаю джунів 13 років тому, які заходили в Google, брали перше рішення і використовували його. Або людина щось зробила на сервері, все почало працювати — а вона не розуміє чому.

Магічне мислення в DevOps існувало завжди. Просто раніше магією був перший результат із Google чи Stack Overflow, а тепер — відповідь AI. Тому питання не тільки в дисципліні. Треба знайти в собі мотивацію докопатися: чому воно зламалося? Чому тепер працює? Що відбулося всередині?

Якщо тобі це справді цікаво, ти сам створюватимеш собі це додаткове навантаження».

«Homelab, де можна зламати все, а потім відремонтувати, дуже допомагає»

— Як би ти зараз будував навчання, якби тільки заходив у DevOps?

Микола Аврамук AIOps Engineer

«Тут важливо уточнити: я теж не прийшов у DevOps просто з вулиці.

Спочатку працював системним адміністратором на телеканалах, працював із фізичними серверами, ми будували автоматизацію доставки контенту. Потім перейшов у продуктову компанію, яка працювала зі стрімінгом, і кілька років був QA Engineer. Але я знав, що хочу перейти в DevOps, тому постійно приходив до менеджера стабільно раз в тиждень й казав: „Дай мені задачі по DevOps“.

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

І, звісно, дуже багато дала практика.

Homelab, тестовий сервер або стенд, де ти можеш зайти, щось запустити, зламати все, потім полагодити, знести й розгорнути заново. Саме такі „граблі“ дуже допомагають.

Ти починаєш накопичувати власний досвід: тут щось зламав, там забув вимкнути instance на місяць і отримав рахунок, після цього навчився налаштовувати budgets та alerts.

Якби я навчався зараз, просто відкрив би в одному вікні термінал, у другому — AI і пішов би розбиратися».

«Що трохи померло з AI — це спільноти»

— Як на твоє життя вплинув АІ?

Всеволод Поляков Head of Engineering у Let’s Enhance

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

А от що трохи померло з AI — це спільноти.

Раніше було багато технічних питань у чатах. Можна було комусь відповідати, щось обговорювати. Зараз значну частину таких запитань люди просто кидають AI, отримують відповідь і йдуть далі.

І дискусій стає менше.

При цьому мені здається, що люди вже починають сумувати за реальною комунікацією. Я нещодавно запустив маленьку спільноту, ми там сперечалися, яку мову програмування обрати першою — і за вечір було сотні повідомлень, щось близько 600. Тут балістика за вікном літає, а ми обираємо мову.

Це було дуже прикольно.

Тобто інформацію тепер простіше отримати від AI. Але потреба поговорити з іншими людьми нікуди не зникла. Цього мені прям не вистачає».

«Якщо імейл згенерований AI, я його навіть не читаю»

Про комунікацію в командах окремо говорив Денис Васильєв.

Денис Васильєв DeadOps

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

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

При цьому я сам використовую AI для перекладу, корекції англійської, щоб щось сформулювати коротше й чіткіше. Питання не в тому, щоб цього не робити.

Питання в тому, щоб AI покращував комунікацію, а не погіршував її.

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

«Ми всі зараз джуни в роботі з агентами»

Водночас AI створює й абсолютно новий пласт знань, де поки немає десятиліть досвіду ні у джунів, ні у сеньйорів.

Як правильно передавати агенту контекст? Як будувати sandbox? Як поєднувати кількох агентів? Де залишати недетерміновану LLM, а де потрібен звичайний детермінований код? Як не дозволити агенту зациклитися або витратити весь бюджет компанії на токени?

Юрій Рочняк CatOps Engineer

«Не пам’ятаю хто з вас вже це казав, Денис мабуть, що ми у певному сенсі всі зараз джуни. Це абсолютно нові скіли.

Ми всі вчимося будувати multi-agent системи так, щоб вони нормально між собою спілкувалися, не зациклювалися, не вижирало бюджети, не вилазили із sandbox і робили саме те, що потрібно. І це теж може бути точкою входу для нових людей.

Бо тут немає ситуації, де senior має 15 років досвіду, а ти прийшов з нулем. Усі ще намагаються зрозуміти, як це правильно робити».

«Найважливіше — системне мислення»

— А що тоді варто розвивати інженеру, окрім уміння користуватися AI?

Микола Аврамук AIOps Engineer

«Для мене це передусім системне мислення. Погляд зверху.

Розуміння, з яких частин складається система, як вони між собою пов’язані і що потрібно, щоб усе це працювало разом. Я навіть використовую AI, щоб він будував мені Mermaid-діаграми і я міг краще бачити зв’язки між компонентами.

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

«Ми будемо менеджити не людей, а агентів»

— Якою тоді стане робота DevOps-інженера у найближчі роки?

Юрій Рочняк CatOps Engineer

«Мені здається, ми вже фактично стаємо менеджерами. І дедалі більше будемо менеджити не людей, а агентів. Зараз уже видно новий bottleneck — саму людину.

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

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

Ще одна цікава зміна — код може почати ділитися на два дуже різні типи.

Є mission-critical code. Наприклад, прошивка для ABS в автомобілі чи медична система. Там відповідальність зовсім інша. Такий код перевірятиметься багато разів, там залишаться QA, ручне тестування, тестові стенди.

А з іншого боку буде disposable code.

Наприклад, мені для load testing потрібен якийсь простий backend-сервіс. Я кажу Claude: зроби мені маленький сервіс на Rust, Zig чи C, щоб він швидко відповідав. Через десять хвилин сервіс є. Я зробив тест і просто його викинув. Мені не треба його підтримувати наступні п’ять років.

Мені здається, такого software стане значно більше».

«Ми повинні позбуватися operation»

Денис Васильєв DeadOps

«Я б не переживав, що AI просто забере все. Навпаки, я давно кажу, що нам треба позбуватися operation.

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

Якщо AI забрав у тебе Terraform, простий coding чи частину Kubernetes operation і після цього в тебе взагалі нічого не залишилося — тоді проблема не в AI. Треба йти на наступний рівень: review, design, architecture, бізнесова задача, яку ми взагалі намагаємося вирішити».

«Уже не вийде закритися в кімнаті й сказати: я просто пишу код»

У цьому місці ми перейшли від конкретно DevOps до ширшої зміни інженерних ролей.

Рутинного execution стає менше, натомість від інженера дедалі частіше очікують розуміння продукту, бізнесу і всієї системи.

У дискусії прозвучало, що ринок рухається від вузьких тайтлів у бік Software Engineer, Platform Engineer, а подекуди вже Product Engineer.

Тобто людини, яка не суто виконує задачу, а розуміє, чому вона взагалі потрібна. Навіть для DevOps це може означати одночасно роботу з інфраструктурою, security, FinOps, продуктом і пріоритетами бізнесу.

Саме тут AI стає не стільки заміною інженера, скільки способом прибрати нижній шар роботи.

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

І ці питання стають важливішими.

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

«Ти не можеш сказати, що AI — ідіот. Відповідальність все одно твоя»

Логіка тут доволі проста: десять років тому інженер міг скопіювати фрагмент зі Stack Overflow. Сьогодні може отримати його від Claude або іншого агента.

Але після того, як код потрапив у ваш commit, джерело вже не таке важливе. Відповідальність залишається на інженері. Тому здатність перевіряти результат AI може стати важливішою за здатність самостійно написати кожен рядок.

Code review, системне мислення, архітектура, знання контексту, розуміння того, що може піти не так, — усе це нікуди не зникає.

«Класичного DevOps, яким він був 12 років тому, вже немає»

Всеволод Поляков Head of Engineering у Let’s Enhance

«Класичного DevOps, яким він був 12–13 років тому, вже немає.

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

У нас постійно щось забирають. Був Puppet, Chef, Mesos, з’являються інші інструменти. Це нормальна частина роботи.

Не треба будувати навколо одного інструменту фортецю і думати: „Тільки я це знаю, без мене ніхто не розбереться“. Бо завтра прийде щось нове й цю фортецю знесуть. Робота просто переходить на інший рівень.

Тому треба вчитися. Думати й вчитися».

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

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

Суміжний досвід, homelab, власні проєкти, розуміння систем, здатність ставити запитання і перевіряти відповіді AI стають важливішими, ніж просто список технологій у резюме.

А головне відкрите питання залишається іншим: якщо AI забиратиме дедалі більше тієї роботи, на якій раніше вчилися джуни, як ми будемо вирощувати наступне покоління middle та senior інженерів?

Як це працює у ваших командах? Чи наймаєте ви Junior DevOps зараз і які задачі їм даєте? І чи змінив AI ваш підхід до навчання молодших спеціалістів?