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

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

Багаторічний автор колонок на DOU Сергій Немчинський за тридцять років карʼєри в IT був у ролі тимліда, техліда й засновника кількох компаній. Нині він — фаундер і CEO школи IT-професій FoxmindEd.

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

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

«Ви не навчитеся самостійно». Як змінились вимоги до початківців

— З огляду на ваш досвід, яка нині ситуація з джунами на ринку праці?

Вимоги до IT-фахівців відчутно змінилися, і, звісно, найбільше це вплинуло на новачків. Раніше джун або навіть Trainee приходив на роботу, повільно (бо інакше не міг) виконував якесь завдання і віддавав на ревʼю старшим товаришам. Це було нормально, тому що старші товариші витрачали 10 хвилин раз на два дні, щоб перевірити, що колега натворив. Це не вимагало багато ресурсу, тому компанія, яка брала джуна, майже не страждала.

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

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

Ситуація, коли є 500–700 охочих на місце і жодну людину не взяли, цілком типова

Галузь подорослішала, і компанії хочуть платити гроші за вміння, а не витрачати час на навчання «під себе». Бо жодна людина не задовольняє вимоги. Головною вимогою до новачка зараз є вміння працювати з інструментами AI. Тобто не просто писати промпти, а видавати за їхньої допомоги production-ready код.

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

Я кільканадцять років веду YouTube-канал і постійно наголошував: «Так, можна самостійно вчитися, це буде довше, дорожче, але ви все одно зможете». Зараз я кажу: «Фіг там, ви не вивчитеся самостійно. Ви не досягнете того рівня, який потрібен компанії, щоб вас взяли». Бо потрібен зворотний звʼязок від живої людини.

— Як сьогодні вчитися так, щоб отримати перший офер?

Треба обирати ту професію, яка подобається, навіть якщо там величезна конкуренція. Конкуренція — це ні про що. Якщо є 700 людей, які не відповідають вимогам, візьмуть саме вас, бо ви релевантний.

Ви конкуруєте не з іншими, а з вимогами ринку

Не треба зважати на ринкові хвилі. Завжди один рік девопси у попиті, в інший рік ML-інженери, потім хтось іще. Якщо ви скакатимете між посадами, не встигнете нічого опанувати на достатньому рівні.

Якщо ми беремо будь-яку із мейнстримних професій, там різниця в зарплаті — 200–300 доларів на сумі в 4000. За різницю у 200 доларів ви готові працювати на роботі, яка вам не подобається?

Щодо того, який варіант навчання обрати: найголовніше отримувати фідбек. Бо теорію можна опанувати будь-де. Лекції й навчальні матеріали не мають сенсу, тому що можна звернутися до Claude Code, ChatGPT чи Codex і про все розпитати. Такі формати, як відеолекції, як на мене, віджили своє.

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

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

В Україні дуже високі вимоги до розробників. Ми завжди були однією з найкращих країн у світі в якості розробки. Людину, яка буде більш-менш задовольняти вимоги до початкового рівня в тій самій Індії, у нас просто не візьмуть. Якщо ви будете на їхньому коді навчатися, матимете проблеми.

— Нещодавно ви писали про кризу менторства в IT. Чи треба зараз шукати собі ментора до входу в професію, чи краще дочекатися, коли прийдеш у компанію і тобі там як джуну призначать наставника?

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

Вам потрібен досвідчений ментор, який перевірятиме ваш код. Це мінімум мідл, скоріше сеньйор-розробник із зарплатою хоча б 3500–4000 доларів на місяць. Навіть якщо такий ментор бере 20–50 людей, все одно це не може коштувати 1000 гривень на місяць.

Ще початківцям варто опановувати AI-агентів. Хоч це і не зовсім просто, людина тоді втричі швидше вчиться і пише ліпший код.

— Якщо вчитися разом із ШІ, наскільки швидшим може бути опанування професії?

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

— Чи може code review під час навчання робити AI? У деяких колективах мідли і вище пишуть код лише за допомогою штучного інтелекту.

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

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

— Якби ви починали шлях в IT зараз, чим би він відрізнявся?

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

У студентські роки

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

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

Дуже багато початківців потрапляють у «пастку трьох місяців»

Людина починає вивчати першу-ліпшу мову, яку порадив знайомий. Зазвичай це чомусь Рython, хоча це смаківщина: комусь подобається, а мені, наприклад, — ні.

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

«Далі не „безліміт кар’єри“, а дуже вузька воронка». Чи варто переходити в тимліди

— Ви писали нещодавно про тимлідів, які душать команду, бо звикли все робити самостійно. Чому це явище виникає і як його уникнути?

Коли мене вперше призначили керівником розробників, тобто тимлідом, мене спеціально ніхто не навчав. Я не розумів своїх обовʼязків, які документи мені потрібні, перед ким відповідаю, який маю скоуп роботи.

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

Або інколи тимліди беруть нізвідки уявлення про стандарти спілкування з підлеглими. Прочитають книжку «Вовк з Волл-стріт» і намагаються її втілити в життя. А розробники ображаються, коли з ними спілкуються, як вовк з Волл-стріт.

Я намагався знайти хоч один курс в Україні, навіть за кордоном, для тимлідів, який був написаний тимлідом. Не знайшов. Усі вони написані проджект-менеджерами, а це різні посади! Проджект-менеджер — це суто менеджерська посада. А тимлід — і менеджер, і розробник. Це наче курс для медичних сестер, написаний лікарем. Наче лікар крутіший, але він ніколи судно не підставляв, крапельницю не ставив. Я розробив курс для тимлідів, спираючись на власний досвід. Написав його за місяць, але мені знадобились напрацювання за попередні 15 років карʼєри.

Виступ на DOU Day 2026

— Коли краще взагалі не йти з техфахівців у тимліди?

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

Мусите страждати від того, що навколо вашого прекрасного коду відбувається якийсь жах

Коли ти сеньйор, далі не «безліміт кар’єри», а дуже вузька воронка. Варіантів по суті два: або в менеджмент (тимлід), або в технічну вертикаль (техлід/архітектор). І проблема в тому, що таких технічних верхніх ролей банально мало: на 100 розробників зазвичай один архітектор (інколи один на 200) і кілька техлідів. Тобто місць мало, охочих багато.

Staff/principal, техлід, архітектор — це не універсальні титули, а «локальні діалекти» конкретних компаній. В одній компанії це чіткий грейд і реальна зона впливу, в іншій — просто гарний ярлик. Тому дивитися треба не на назву, а на фактичні повноваження: хто реально ухвалює технічні рішення, хто відповідає за впровадження, з кого питають за результат.

В аутсорсі архітектор часто перетворюється на пресейл-роль: поговорив із замовником, намалював схему, продав підхід і побіг далі. Звучить статусно, але часто це про «презентувати», а не про «довести до продакшну і відповідати за наслідки». Щоденна технічна відповідальність при цьому залишається на лідах і команді.

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

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

«Найбільше вимагають софт-скілів, бо їх не має штучний інтелект»

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

Вона давно проявилася, бо немає ніякого окремого українського ринку. Україна — частина світового ринку. Українська IT-галузь найбільш наближена до американської. Ми всі навчалися саме в американських менеджерів, у американських розробників, з ними найбільше працювали. 80% нашого аутсорсу припадало саме на Сполучені Штати.

Культура майже всіх українських компаній — це суто американська культура

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

Тобто стає важливим спілкування, вміння нормально висловлювати думку. Чути інших набагато важливіше, ніж мати хард-скіли. Токсичний упир, який раніше б отримав роботу миттєво, зараз просто нікому не потрібний. Буде ходити і скиглити: «Чого мене не беруть? У мене 15 років у Java». Чувак, ти на себе в дзеркало подивись, ти ж токсичний.

— Як ви ставитеся до вайбкодингу?

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

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

— На вашу думку, у яких сферах AІ не приживеться?

Я не можу уявити сферу, де не буде AI. Але потрібен human in the loop. У нас немає того, що називається General AI, справжнього штучного інтелекту. У нас є large language model. А це статистична форма, яка рахує, які слова будуть наступними. Це математика ймовірності. Все одно залишатиметься ймовірність, що AI помилився.

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

Навіть від розробників, які здавалися всім виключно технічними людьми, зараз найбільше вимагають софт-скілів. Бо їх не має штучний інтелект.

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

«Ми в ситуації відкладеного попиту». Як IT-галузь розвиватиметься далі

— Що далі чекає на український ІТ-ринок, на вашу думку?

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

Навряд чи всі продуктові компанії, які за цей час виникли, зникнуть кудись. Тим більше в miltech. Miltech буде розвиватися й надалі. Україна на найближчі роки буде гегемоном на ринку зброї і на ринку захисту від зброї. Україна — єдина країна, яка взагалі вміє з цим нормально працювати. Є, звісно, ще північні сусіди, але до них навряд чи хтось піде. Як тільки змінять законодавство і дозволять експорт зброї, у цій галузі будуть просто величезні гроші!

— Ви згадували про парадокс українського miltech: він росте гігантськими темпами, але кадрів катастрофічно бракує. Чому фахівці не йдуть у цю сферу?

Там звичайна проблема новонародженої галузі. У класичному IT ви вивчилися на, умовно, фронтенд-розробника, розумієте вимоги. Ви йдете у будь-яку компанію з цими умовами і влаштовуєтесь як частина пазла.

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

Як ми можемо навчити людину, яка знає все? Тому що вони самі не знають. У них немає розподілу на обов’язки. Кожну людину, яка приходить, вони просто кидають в котел. А встановити вимоги для новачків не можуть.

— А кого тоді беруть на роботу?

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

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

— Чи можна говорити зараз, що мілтех-сфера стає привабливішою для розробника, ніж класичне IT?

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

Також зарплати там відчутно нижчі, ніж у великому IT, тому що вони не можуть продавати зброю за кордон. Коли зможуть нарешті, там будуть захмарні гроші. А якщо основний покупець — це українське Міністерство оборони, то там будуть більш-менш нормальні зарплати, але все одно відчутно нижчі, ніж в іншому IT. Ці аспекти стримують від того, щоб туди переходити. Є й суто бізнесова розробка, на кшталт ERP (для військової логістики, керування особовим складом тощо). Водночас вона оперує дуже сенситивними даними, тому на цю роботу можуть потрапити тільки військові. Зарплати ж військових, на жаль, дуже низькі.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU