Програмісти більше не потрібні? Що насправді робить ШІ з ІТ-ринком
Напевно, ніщо так не б'є по людині, як момент, коли те, чим вона пишалася все професійне життя, раптом перестає мати значення. Програміст, який роками відточував уміння писати код на C++, або розробник, здатний розібратися в будь-якій архітектурі, будували свою професійну ідентичність навколо конкретних навичок. Саме ці вміння формували їхню цінність, їхнє его і, зрештою, робили їх одними з найоплачуваніших фахівців в Україні та світі.
Однак з появою штучного інтелекту (ШІ) ситуація почала змінюватися. Те, що ще донедавна було їх ключовою компетенцією, поступово втрачає свою винятковість. У центрі цього процесу – особистісний конфлікт, адже технологія, створена людьми, змінює їхнє уявлення про власну професію. Вона змушує переосмислювати свою роль та цінність і саме це стає одним із найболючіших аспектів трансформації IT-індустрії останніх років.
Парадокс у тому, що ці зміни зачіпають усіх: і тих, хто десятиліттями працює в індустрії, і тих, хто лише входить у неї, і навіть тих, хто закріпився і вважав своє місце стабільним.
Назвати це поганими часами складно – будь-які зміни відкривають нові можливості. Проте вони завжди несуть невизначеність. Особливо для українських розробників, які з 2022 року і без того працюють у складних умовах. У цьому контексті те, що ШІ стає для них новим викликом, виглядає цілком закономірно.
Як ШІ та автономні системи змінюють роботу програмістів? Чому написання коду перестає бути головною навичкою? Як знайти себе в новій реальності, де значну частину того, що вміли розробники, бере на себе алгоритм?
Роль айтівців стрімко змінюється
"Ми, можливо, за 6-12 місяців від того, щоб моделі виконували більшість, а можливо, і весь обсяг роботи, який роблять розробники від початку до кінця", – заявив CEO Anthropic Даріо Амодей під час дискусії зі своїм колегою Демісом Хассабісом із Google DeepMind на цьогорічному Всесвітньому економічному форумі.
Його слова можна трактувати по-різному: від чергової гучної заяви, покликаної привернути увагу до нових розробок компанії, до реалістичної оцінки того, як ШІ, зокрема агентні системи, змінюють підходи до створення програмного забезпечення.
Це підтверджує дослідження української ІТ-компанії SoftServe, проведене спільно з MIT Technology Review. У ньому йдеться, що в найближчі два роки розробка програмного забезпечення може досягти рівня автоматизації, який можна порівняти з безпілотними таксі.
Наразі більшість команд використовують ШІ як допоміжний інструмент для написання коду, тестування чи аналізу. Однак з розвитком агентних систем підхід змінюється: компанії поступово переходять до повноцінної агентної інженерії в межах усього етапу розробки. Зокрема, 72% опитаних очікують, що в найближчі два роки ШІ-системи керуватимуть більшістю або навіть усіма етапами життєвого циклу продукту, а 41% прогнозує, що це станеться впродовж 18 місяців.
У SoftServe кажуть, що ситуація в індустрії змінюється настільки швидко, що частину цих оцінок уже можна вважати застарілими. "Ми почали цей репорт у грудні, а у квітні він частково застарів, оскільки світ за цей час зробив ще один ривок. Те, що ми прогнозували на два роки вперед, може стати реальністю вже до кінця 2026 року", – каже CTO напряму Advanced Technologies у SoftServe Серж Газієв.
Ідеться про те, що ШІ-агенти керуватимуть більшістю етапів життєвого циклу продукту. У галузі це явище називають Dark Software Factory – підходом, коли достатньо описати вимоги до продукту, а система самостійно створює готовий, протестований софт, який можна одразу використовувати.
Такий сценарій уже зараз частково стає реальністю. Один із софтвер-інженерів розповів ЕП, що вже зараз близько 80% його завдань – це не написання коду, а формулювання запитів і постановка завдань для моделі. Далі ШІ самостійно генерує код, а його роль зводиться переважно до перевірки результату.
Як наслідок великі компанії активно використовують нові інструменти, запускають платні рішення, а розробники отримують доступ до дедалі потужніших моделей. Водночас, за словами Газієва, поки що це не повністю реалізована модель, але індустрія швидко до неї рухається.
Попри це частина ринку зберігає обережний оптимізм. Наприклад, CEO компанії DevRain Олександр Краковецький погоджується, що напрямок розвитку, про який говорять дослідження і великі технологічні компанії, правильний, але трансформація йтиме повільніше, ніж це іноді подають у гучних заявах.
"Поки що це досить фрагментований процес. Здається, що всі вже перейшли на агенти, але на практиці це все ще відносно невелика частка ринку. Хоча вона, очевидно, ростиме", – каже Краковецький.
Що це означає для інженерів і команд
Головна дискусія в індустрії ведеться не про те, чи зміниться робота інженерів, а про те, наскільки швидко це станеться. Факт змін майже ні в кого не викликає сумнівів.
У цих умовах ключовим викликом стає здатність адаптуватися до нової реальності, де важливішими стають постановка завдань, формулювання вимог та оцінка результату.
Якщо уявити, що розробник – це кухар у ресторані, то раніше його робота виглядала так: він стояв біля плити і готував страви власноруч. Нарізав, смажив, перемішував, пробував, виправляв. Це вимагало років навчання, точних рухів і постійної уваги. Більшість часу йшла на технічне виконання.
Тепер агентний ШІ – це як команда помічників на кухні. Їм достатньо пояснити, що потрібно зробити, і вони самі виконують завдання. Інженер, тобто кухар, більше не стоїть біля плити, його роль змінюється. Тепер цінність програміста в тому, що машини не вміють: розуміти потребу, вигадувати рішення, контролювати якість і ухвалювати рішення в складних ситуаціях.
У цьому і складність. Якщо кухар усе життя навчався стояти біля плити і пишається своєю технікою смаження стейків, йому важко прийняти, що тепер його професійна цінність формується довкола інших навичок.
"Ключовий виклик – це зміна мислення. Частина інженерів усе ще тримається за свою професійну ідентичність, пов'язану з конкретними мовами програмування чи підходами, і не встигає адаптуватися до нової моделі роботи зі штучним інтелектом", – зазначає Газієв.
Попри розмови про "кінець програмування", Краковецький пропонує дивитися на це не як на революцію, а як на черговий етап еволюції індустрії. "Це справді виглядає як зміна парадигми. Раніше ми працювали на рівні деталей реалізації: писали код, керували пам'яттю, будували системи вручну. Зараз ми піднялися вище й описуємо бізнес-сценарії, а технічну реалізацію значною мірою бере на себе система", – пояснює він.
Значна частина простих завдань уже зараз може виконуватися без участі технічних спеціалістів. На думку Газієва, для завдань середньої складності програміст тепер не завжди потрібен у звичному розумінні: частину роботи можуть виконувати продакт-менеджери, бізнес-аналітики і тестувальники. Як колись для створення простого сайту перестала бути обов'язковою участь розробника, так і зараз частина розробки стає доступнішою без глибоких технічних знань.
При цьому автоматизації піддаються не всі завдання. У складних проєктах із старими системами, які роками будувалися і на яких тримається бізнес чи інфраструктура, не вийде швидко все переписати або "перегенерити" через ШІ.
За даними досліджень SoftServe, якщо раніше ключовими були DevOps, cloud і full-stack-фахівці, то тепер найбільш затребуваними стають ШІ-інженери (про це говорить 51% опитаних). Так, професор Університету Гаваїв Рік Казман вважає, що широке використання агентного ШІ стане основою базових інженерних процесів. У написанні коду, тестуванні, рефакторингу та деплої цей зсув буде найбільш відчутним.
Використання ШІ змінює структуру команди, яка працює над конкретним проєктом. Великі команди стають менш потрібними, а швидкість розробки різко зростає. "Ми називаємо цю модель one pizza team. Це коли команду можна нагодувати однією піцою – чотири-п'ять людей. На відміну від підходу з більшими командами, такі групи стають майже вдвічі меншими, але працюють продуктивніше", – пояснює Газієв.
Використання ШІ різко скорочує тривалість розробки. Якщо раніше за кілька тижнів команда могла підготувати лише прототип, то тепер за той самий час отримує першу повноцінну робочу версію продукту і часто силами значно меншої команди.
Як зазначає директор "ЕРАМ України" Вадим Власенко, таких випадків у компанії стає більше. "Якщо рік-півтора тому ми говорили про прискорення "до 20%", то зараз упевнено кажемо "від 20%". Моделі суттєво покращилися, інструменти стали потужнішими, а команди навчилися ними правильно користуватися", – додає він.
Як це змінює бізнес-моделі IT-компаній
Традиційно аутсорсингова модель ІТ-компаній будувалася на продажу людино-годин: "продажу часу" або "продажу команди" для конкретного проєкту. Тепер ця логіка змінюється.
За словами CTO Advanced Technologies у SoftServe, сервісна модель поступово відходить від оплати за години роботи і переходить до підходу, де клієнт платить за результат. Проєкти дедалі частіше ділять на етапи з чіткими цілями та вартістю, іноді з бонусами за швидкість або ризиками для виконавця в разі затримок.
В ЕРАМ зазначають, що ідея платити за результат, а не за час, не нова, але раніше вона розбивалася об неможливість точно передбачити, скільки часу це займе. "Тепер ШІ робить таке прогнозування набагато точнішим, а клієнти приходять не з розмитим технічним завданням, а з готовим прототипом, зробленим власноруч, і просять доробити його до готового продукту або створити лише потрібну частину функціоналу замість купівлі дорогих готових рішень", – каже Власенко.
Він наголошує, що це поступовий зсув, оскільки частка таких угод значно менша за традиційну модель Time&Materials (T&M).
Співрозмовники ЕП в ІТ-секторі припускають, ситуація на ринку може розвиватися кількома шляхами.
З одного боку, послуги можуть суттєво подешевшати: менші команди і швидша розробка означають нижчу вартість.
З іншого – можливий ефект, схожий на економічний парадокс Джевонса: коли технології стають дешевшими і простішими, люди починають активніше їх використовувати і загальне споживання зростає. Класичний приклад: парові двигуни стали економнішими і вугілля почали спалювати більше, бо двигуни поширилися скрізь. У випадку з ІТ-компаніями клієнтів стане більше і ринок розшириться.
Ще один сценарій – перерозподіл кадрів. Частина інженерів може перейти з аутсорсу в продуктові компанії або великі українські бізнеси, де потрібні більш спеціалізовані рішення і глибше розуміння домену.
За словами Краковецького, межа між інхаус-розробкою та аутсорсингом поступово розмивається: навіть нетехнічні компанії можуть виконувати більшість завдань власними невеликими командами з використанням ШІ. Тобто аутсорс-компанії втрачають клієнтів не тому, що погано працюють, а тому, що клієнти потребують менше зовнішньої допомоги.
Паралельно великі компанії дедалі частіше будують власні внутрішні IT-структури і цей тренд лише посилюватиметься. Крім того, трансформується взаємодія з клієнтом. "Зміняться вимоги до постачальників послуг: вибір партнера стане набагато прискіпливішим", – прогнозує Власенко.
Що буде з професією і входом у неї
Однозначної відповіді, чи постраждають інженери, немає. Уже зараз видно, що частина компаній скорочує команди завдяки автоматизації. Це стосується не лише програмістів, а й інших спеціалістів, які виконували рутинні завдання.
Водночас говорити про зникнення професії рано – ідеться про її трансформацію. Найбільше питань виникає щодо початківців, адже саме їхні завдання в компаніях починає виконувати ШІ. Однак це не означає, що вони зникнуть – просто змінюється точка входу.
Замість звичайного знання конкретної мови програмування важливішими стають фундаментальні навички: розуміння завдань, логіки систем і вміння працювати з інструментами ШІ.
На переконання Газієва, роль Junior-розробника зміщується до етапу фінального доопрацювання продукту, коли потрібно перевірити результат, знайти помилки і довести рішення до робочого стану. Знання мов програмування залишається важливим на рівні розуміння, а не на рівні синтаксису.
Крім того, з'являється новий тип спеціаліста – умовно "AI-native-інженер". Це не обов'язково найсильніший програміст у класичному розумінні, а людина, яка вміє ефективно використовувати інструменти ШІ і досягати результату.
Саме ця навичка стає важливою для майбутнього програміста. За словами Краковецького, позиція Junior залишиться, але працюватимуть вони разом із ШІ-інструментами та агентами.
Складні завдання, як і раніше, виконуватимуть Senior – передусім архітектуру та системні рішення. Тобто процес змінюється, але поділ на складні та прості завдання зберігається.
Водночас межа між позиціями в компаніях може почати розмиватися через появу super-junior – людей без великого досвіду, але з правильним мисленням і вмінням працювати з ШІ. У 18-20 років вони можуть показувати результат рівня спеціалістів із багаторічним досвідом. Попит на них зростатиме. Ключове тут – не інструменти, а підхід: гнучкість і відсутність прив'язки до конкретного стеку.
"Інженер більше не мислить себе як backend.NET developer чи Java developer. Така спеціалізація звужує. Натомість він працює як software engineer, який обирає інструменти: сьогодні – одна технологія, завтра – інша, далі – робота з агентами. Важливим стає не знання конкретної мови, а здатність виконувати завдання", – пояснює Краковецький.
Саме тому молодшим спеціалістам легше адаптуватися: у них немає прив'язаності до конкретних технологій. Вони сприймають інструменти як засіб, а не як частину ідентичності.
Це підтверджують і зміни попиту на ринку. Якщо в останні роки лідирували DevOps engineer (41%), Cloud engineer (37%) і Full-stack engineer (36%), то в найближчі два роки на перший план вийдуть AI engineer (51%), Software architect (32%) та Data engineer (29%). Це показує зсув від виконання до проєктування, даних і роботи з ШІ.
Власенко підтверджує цю тезу: "Найціннішим активом стає фахівець, який поєднує глибоку доменну експертизу з умінням системно використовувати ШІ для отримання результату. Це не той, хто просто має Claude Code або Codex у редакторі, а той, хто перебудував свій робочий процес і видає результат у два-три рази швидше. Такі фахівці коштують дорожче і клієнти це розуміють".
В ЕРАМ додають, що тепер базова ШІ-грамотність – це не перевага, а базовий мінімум. Клієнти готові платити більше тільки за вузьких спеціалістів, зокрема тих, хто будує і тренує моделі, але не бачать сенсу в доплатах за "інженера із звичайним Copilot".