Як не дати штучному інтелекту замінити себе? Інструкція від Associate Vice President з AI та Data Science в SoftServe

Чи справді розробники залишаться без роботи 

Кілька місяців тому Марк Цукерберг спрогнозував, що більшість коду скоро писатиме ШІ — і мова не лише про автодоповнення, а про повний цикл: постановку цілей, запуск тестів, виправлення багів і написання коду краще за провідних інженерів.

Ми вже бачимо, як ця зміна відбувається. Large language models (LLMs) перетворюються на автономних агентів, які планують, аналізують, запускають процеси інтегруються з API. Вони починають поводитись як розробники-початківці. Цей зсув водночас захоплює і тривожить. Якщо ваша щоденна робота — це glue code, дашборди чи скрипти для трансформації даних, є велика ймовірність, що агент зробить це швидше за вас. 

У Microsoft вже 30% коду пише ШІ. 91% компаній використовують ШІ-агентів, найчастіше для автоматизації задач, згідно з дослідженням Okta. Ці цифри можуть тривожити, спонукаючи до питання: чи справді розробники лишаться без роботи? 

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

З нашого досвіду в SoftServe, агентний ШІ змінює сам процес розробки. Ми інтегрували агентів для генерації бекенд-логіки, повністю функціональних UI, CI/CD-конфігів (зокрема Terraform). Вони не будують готові системи, але створюють перші варіанти рішень на основі доступних даних, як-от PRD. Результат далекий від ідеалу — і ми цього й не очікуємо. Але цього достатньо, щоб зняти ефект «чистого аркуша» і дати структуру, яку інженери вже допилюють. Тобто роль розробника зміщується з написання коду з нуля до формувавання й покращення результатів роботи ШІ-агентів.

В індустрії зростає кількість інструменти на основі ШІ-агентів. Cursor допомагає розробникам ітерувати прямо в IDE. Lovable та V0 — збирати UI-компоненти. Windsurf досліджує складніші кейси композиції. Кожен інструмент дає часткову автоматизацію, але більшість з них — closed-source і «чорні ящики». Ти не можеш контролювати їхню поведінку чи підлаштовувати під свій стек. Тому багато компаній будують власних внутрішніх агентів: надихаються тим, що вже є, але проєктують їх під свої реалії.

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

Як стати командою з ШІ-агентами

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

У результаті змінюється сама композиція команд. Класична команда зазвичай складається з 8–10 девелоперів, які повний робочий день розробляють функціонал.

За прогнозом World Economic Forum у звіті Future of Jobs 2025, у найближчі п’ять років ШІ та інші технології витіснять близько 9 млн робочих місць. Але водночас ШІ створить і нові: у тому ж звіті сказано, що до 2030 року з’явиться 11 млн нових вакансій. Уже зараз ми бачимо зародження гібридної ролі: інженер з роботи зі ШІ (intelligence engineer). Це людина, яка відповідає за інтерфейс між експертизою людини та тим, що видає агент, керує агентами, перевіряє результати і стежить, щоб усе інтегрувалося правильно.

Як може змінитися робочий процес за участі ШІ-агентів

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

Сьогодні агенти все ще спотикаються на:

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

То що ж працює

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

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

5 рівнів роботи з ШІ-агентами

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

Рівень 1. Асистент. Роль людини — автор

Це вже знайомий нам світ з ШІ-асистентами та автодоповненням коду на кшталт GitHub Copilot. ШІ додає розумне автозавершення у межах контексту, що йому надав розробник. Він підказує рядки чи блоки коду, але людина повністю керує процесом та ухвалює всі рішення.  

Рівень 2. Спеціаліст. Роль людини — делегатор

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

Рівень 3: Колаборатор. Роль людини: рецензент/ архітектор

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

Рівень 4: Автономний член команди. Роль людини: супервайзер

Це рівень, якого зараз намагаються досягнути передові команди. Агент може взяти повноцінний user story чи функцію й керувати її життєвим циклом: самостійно планувати задачі, писати код, створювати тести, консультуватися з документацією через RAG і відправляти pull request для схвалення людиною. Роль людини зміщується до високорівневого огляду і стратегічних архітектурних рішень, як у senior tech lead.

Рівень 5: Агентна команда (Agentic Team).  Роль людини: продуктовий візіонер

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

Щоб досягнути двох останніх рівнів, слід не тільки подолати технічний виклик, а й фундаментально переосмислити ролі, структуру команд і саме поняття створення програмного забезпечення. Але для тих, хто готовий до цього — шлях очевидний.

Як залишатися затребуваним, коли просто писати код — вже недостатньо

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

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

Спиратися на агентів без знання коду — не варіант. Потрібна сильна інженерна база, щоб оцінити й виправити їхній результат. Розробник, який не розуміє систему зсередини, не може безпечно використовувати те, що згенерував агент. Тому ті, хто реально проривається в цій сфері, зазвичай middle+, із доменною експертизою та практичним досвідом.

Стартова точка проста: навчайтеся через практику. Почніть з експериментів — використовуйте агентів для підтримки щоденних задач з написання коду.