ШІ не замінює програмістів: він знищує стару модель їхнього зростання

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

Вітаю, друзі. Мене звати Сергій Немчинський. У програмуванні я працюю майже 25 років. За цей час пройшов шлях від рядового розробника до засновника власної компанії. Наразі керую навчальним центром ІТ-професій FoxmindEd.

Хочу поговорити про те, що сьогодні болить усій індустрії, — штучний інтелект. Але не загалом, а з точки зору того, чим займаюся багато років: ІТ-освіти.

Останній рік у професійній спільноті обговорюють дві протилежні тези. Перша — що ШІ ось-ось замінить усіх програмістів. Друга — що хороший розробник завжди буде потрібен.

На мою думку, обидві сторони сперечаються не про те.

Проблема не в тому, чи може LLM написати CRUD, REST API або набір юніт-тестів. Вона вже може. Проблема в тому, що ШІ руйнує економіку вирощування інженерів.

Чому бізнес перестає наймати класичних джунів

Як донедавна виглядала еволюція розробника? Просто та зрозуміло.

Компанія наймала джуна. Перші місяці він закривав дрібну рутину: виправляв баги, писав нескладні інтеграції, верстав інтерфейси, додавав поля до бази даних, покривав код тестами.

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

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

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

Джуніори на ШІ-екскаваторі

Штучний інтелект і численні інструменти швидкої розробки розділили молодих програмістів на дві категорії.

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

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

Я не стверджую, що Copilot, Claude чи ChatGPT пишуть поганий код. Часто вони пишуть його краще за початківця. Але це нічого принципово не змінює.

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

Саме тому навіть ідеально згенерований код не скасовує необхідності Code Review. Він лише переносить вузьке місце з написання коду на його перевірку.

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

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

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

Junior+ розуміє Git, SQL, вміє читати чужий код і бачить, де модель могла помилитися або не врахувати контекст. Такий джуніор відкриває Pull Request лише після того, як сам перевірив, допрацював і зрозумів рішення.

Саме такі люди, на мою думку, сьогодні мають найбільші шанси швидко вирости в сильних інженерів. Але їх мало.

Сеньйори теж плачуть

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

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

Другі — «таксисти». Їм цікавіше не написати черговий клас, а зробити так, щоб наступного разу його взагалі не довелося писати. Вони будують пайплайни, автоматизують CI/CD, інтегрують LLM у внутрішні процеси та прибирають повторювану роботу.

Але ніхто з них не любить день за днем перевіряти чужий код із ШІ-галюцинаціями!

ШІ майже обнулив вартість написання коду, але не здешевив його розуміння. Кожен Pull Request потрібно прочитати, зрозуміти, виправити, довести до робочого стану. Це не просто нецікава робота. Вона виснажує, бісить, демотивує і призводить до професійного вигорання.

У результаті «візники», які вже не пишуть власний код, втрачають інтерес до професії. А «таксисти» починають робити власні проєкти в позаробочий час.

Зникаючий середній клас

Економіка тримається на середньому класі, а розробка — на мідлах. Точніше, трималася.

Розробник середнього рівня — він же мідл — багато років був універсальним солдатом. Він добре писав код, але коштував дешевше за сеньйора.

Але часи змінилися. Якщо Junior+ із ШІ здатний писати код швидше й дешевше, головна конкурентна перевага класичного мідла зникає. Тепер мідлу потрібно розуміти архітектуру, працювати з великим контекстом, комунікувати з командою та наставляти молодших розробників. Ці компетенції найскладніше автоматизувати.

Так частина мідлів стрімко еволюціонує в сеньйорів. Інші сидять без роботи або взагалі залишають розробку.

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

Бізнес-ризики: кадровий вакуум

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

Але економія сьогодні створює дефіцит завтра.

Якщо перестати вирощувати джунів на реальних задачах, через три-п’ять років нізвідки не з’являться нові мідли та сеньйори. Їх не можна «згенерувати», як черговий фрагмент коду.

У результаті компанії самі створять кадровий вакуум. Сеньйорів стане ще менше, мідли майже зникнуть. Натомість ринок заповнять тисячі людей, які чудово вміють оркеструвати ШІ, але не здатні самостійно розібратися, чому серед ночі впав продакшн.

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

Що робити бізнесу

Потрібно перестати використовувати дорогих спеціалістів там, де їхня кваліфікація не потрібна.

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

Рутину потрібно віддавати Junior+. Саме там вони набивають ґулі, вчаться працювати з контекстом і поступово стають самостійними інженерами.

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

Сеньйорам-«візникам» потрібно залишити те, за що їм платять найбільші гроші: архітектуру, складні алгоритми, технічні рішення та критично важливі частини продукту. Їхній час занадто дорогий, щоб витрачати його на нескінченне сортування автоматично згенерованого коду.

Що робити майбутньому розробнику

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

Конкуруйте в тому, чого модель поки що не вміє.

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

Саме тому у FoxmindEd ми давно відмовилися від класичних лекцій як основного формату навчання. Студент із першого дня працює з Git, читає чужий код, проходить жорсткі Code Review від практикуючих сеньйорів і поступово звикає до процесів, з якими зіткнеться на реальному проєкті. Сьогодні це вже не «практика» — це питання виживання в професії.

ШІ не замінить програмістів.

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