Під час New York Tech Week в офісі IBM One Madison у межах подкасту Mixture of Experts керівники IBM, які відповідають за платформи ШІ, автоматизацію та консалтинг, обговорили, як штучний інтелект змінює саму природу програмної інженерії. Замість класичної картини «людина пише код, машина виконує» вимальовується інша: програмне забезпечення як сукупність агентів ШІ, а розробники й тестувальники — як їхні архітектори, оркестратори та аудитори.
Ця розмова дає досить чіткий контур того, як виглядатимуть Software 3.0 і Software 4.0, чому базові задачі кодування стрімко автоматизуються і які навички стають критичними для інженерів наступного покоління.
Від Software 2.0 до 4.0: коли кодом стають дані й агенти
Щоб зрозуміти, чому змінюється роль інженера, варто подивитися на те, як змінюється саме поняття «програмне забезпечення».
Кілька років тому ідея Software 2.0, популяризована Андреєм Карпаті, запропонувала просту, але радикальну думку: частини коду можна замінити даними плюс модель машинного навчання. Замість тисяч жорстко прописаних правил — градієнтний спуск, який вчиться на масивах даних.
Класичний приклад — автопілот у автомобілях. Раніше це були сотні тисяч правил: що робити на стоп-лінії, як реагувати на велосипедиста, як поводитися на перехресті. Software 2.0 дозволив замінити ці правила моделлю, натренованою на лідарах, відео та інших сенсорних даних. Логіка стала не детерміністичною, а ймовірнісною: рішення приймає не жорсткий if-else, а модель, якій «пояснили світ» через дані.
Це був перехід від коду як набору логічних конструкцій до коду як поєднання даних і моделей. Але на цьому еволюція не зупинилася.
Software 3.0 — це епоха foundation models, великих та малих мовних моделей, які містять «загальні знання» й можуть бути адаптовані до конкретних задач. У цьому світі GPT-подібні системи, спеціалізовані моделі та доменно-орієнтовані LLM стають базовими будівельними блоками. Вони вже не просто замінюють окремі модулі, а стають універсальними «двигунами» для тексту, коду, аналізу, інтеграції.
Наступний крок — Software 4.0. Тут IBM бачить програмні системи як колекції агентних систем, які взаємодіють між собою та з людьми. Замість монолітних застосунків — ансамблі агентів, кожен з яких має власну «інтелектуальність», доступ до моделей і здатність діяти автономно в межах заданих правил.
Людська мова сьогодні — основний протокол взаємодії між людиною та агентами, а також між самими агентами. У майбутньому це може змінитися, але принцип залишається: система — це не один великий застосунок, а мережа спеціалізованих, координованих агентів.
У такій архітектурі питання вже не в тому, хто напише більше рядків коду. Ключовим стає те, хто спроєктує правильну конфігурацію агентів, визначить їхні ролі, обмеження, канали комунікації та способи контролю.
Коли код пише AI: кінець епохи «junior-кодерів» у старому сенсі
Паралельно з еволюцією архітектур відбувається інша — не менш радикальна — трансформація: автоматизація самого процесу написання коду.
IBM вже використовує низку кодогенераторів — від власного асистента Bob до інструментів на кшталт Codex та інших популярних систем. Поверх цих «двигунів коду» компанія побудувала оркеструвальний шар, який дозволяє автоматизувати не лише написання функцій, а практично весь життєвий цикл розробки.
У консалтингових проєктах для клієнтів IBM описує сценарій, який ще кілька років тому виглядав би фантастично: завдяки поєднанню кодогенераторів, контекстної інженерії та керування пам’яттю системи здатні:
– збирати й формалізувати вимоги,
– генерувати високорівневий і детальний дизайн,
– писати код «від і до»,
– створювати тести,
– готувати й виконувати деплоймент, включно з вибором середовища — Azure, AWS чи IBM Cloud.
Те, що раніше займало шість-вісім місяців, стискається до приблизно одного місяця, і, за словами учасників дискусії, цей горизонт продовжує скорочуватися. Скепсис розробників щодо якості такого коду поступово змінюється усвідомленням: можливості систем за два роки стрибнули настільки, що те, чого не існувало в кінці 2024-го, у другому кварталі 2026-го вже стало робочим інструментом для кастомної розробки.
Цей зсув має прямий наслідок для ринку праці. Рутинні задачі початкового рівня — написання шаблонного коду, реалізація типових CRUD-операцій, створення нескладних сервісів за специфікацією — дедалі частіше виконують генеративні моделі. Те, що раніше було «входом у професію» для джуніорів, тепер автоматизується.
Це не означає, що потреба в людях зникає. Але означає, що попит зміщується з «людей, які можуть написати код за ТЗ», до «людей, які можуть поставити правильне завдання агентам, перевірити результат, оптимізувати систему та гарантувати її безпеку й ефективність».
Розробник як оркестратор агентів: нова інженерна ідентичність
У світі Software 4.0 розробник перестає бути насамперед «людиною, яка пише код руками». Його роль зміщується до проєктування та оркестрації агентів ШІ.
По-перше, змінюється точка входу в проєктування. Якщо раніше архітектор розбивав систему на сервіси, модулі й компоненти, то тепер він одразу мислить агентами: які агентні системи потрібні, які моделі лежатимуть під кожною з них, як вони взаємодіятимуть між собою та з людьми.
По-друге, зростає значення системної архітектури. Не йдеться лише про мікросервіси чи API-дизайн. Потрібно розуміти, як поєднати foundation models, спеціалізовані LLM, класичні сервіси, бази даних і зовнішні API в єдину, керовану, безпечну екосистему агентів.
По-третє, розробник стає «дизайнером поведінки» для агентів. Він визначає:
– які правила й обмеження застосовуються до агента,
– які джерела даних той може використовувати,
– які дії має право виконувати,
– як і де фіксується його контекст і пам’ять,
– як відбувається ескалація до людини у разі невизначеності.
Учасники дискусії прямо формулюють цю трансформацію: розробники стають «agent builders» та «orchestrators». Їхня робота — не в тому, щоб власноруч реалізувати кожну функцію, а в тому, щоб правильно визначити, що має робити агент, як він має це робити, з ким і як взаємодіяти.
Це не зменшує складність професії, а радше піднімає її на інший рівень абстракції. Замість боротьби з синтаксисом — боротьба з системною складністю, ризиками, продуктивністю та інтеграцією.
Тестувальник як аудитор агентів: чому валідація важливіша за редагування коду
Якщо розробники стають оркестраторами, то тестувальники — аудиторами. І це не просто зміна назви.
У класичній моделі QA-фахівець міг:
– аналізувати вимоги,
– писати тест-кейси,
– запускати тести,
– знаходити дефекти,
– у деяких випадках — пропонувати або навіть вносити зміни в код.
У світі, де код генерує ШІ, останній пункт практично зникає. Коли великі моделі створюють значні обсяги коду, ручне «підправлення» кожної ділянки стає не лише неефективним, а й концептуально неправильним: будь-яка зміна може бути перезаписана наступною генерацією, а логіка, що стоїть за кодом, живе в параметрах моделі, а не в окремих файлах.
Тому роль тестувальника зміщується до аудиту:
– перевірки вихідних результатів,
– валідації того, що система дотримується заданих правил,
– аналізу, які саме правила й політики були застосовані агентом для отримання результату,
– виявлення системних збоїв, упереджень, небезпечних сценаріїв.
Фактично, тестувальник стає «контролером якості поведінки агентів». Він не стільки виправляє код, скільки перевіряє, чи правильно працює вся система правил, обмежень і моделей, які цей код породжують.
Це вимагає іншого набору навичок. Потрібно розуміти, як працюють LLM, які в них типові помилки, як будувати тестові сценарії для ймовірнісних систем, як інтерпретувати їхні рішення й як формулювати вимоги до прозорості та трасованості.
Верифікація, оптимізація, безпека: навички, які стають дефіцитом
Автоматизація базового кодування не робить інженерну роботу простішою — вона робить її іншою. Учасники панелі наголошують: попит зміщується до навичок вищого рівня, з якими LLM поки що справляються погано або нестабільно.
По-перше, це верифікація. У ймовірнісних системах, де код генерується на льоту, критично важливо мати людей, здатних оцінити коректність поведінки системи, а не лише окремих функцій. Потрібні фахівці, які можуть поставити питання: чи відповідає ця поведінка вимогам, регуляціям, етичним нормам, бізнес-цілям?
По-друге, оптимізація. LLM добре генерують робочий код, але не обов’язково — оптимальний. Питання продуктивності, ефективності використання ресурсів, енергоспоживання, latency, масштабованості — все це потребує глибокого системного розуміння. Особливо в умовах, коли агентні системи працюють поверх складної інфраструктури й взаємодіють з безліччю сервісів.
По-третє, безпека. Автоматично згенерований код може містити вразливості, які важко виявити без спеціалізованих знань. Крім того, самі агенти можуть стати вектором атак — через prompt injection, маніпуляцію контекстом, некоректну роботу з правами доступу. Інженери безпеки мають навчитися мислити не лише категоріями «патчів» і «сканерів», а й категоріями «політик для агентів» і «захисту ланцюжків оркестрації».
По-четверте, апаратно-програмна ко-дизайн. Зі зростанням ролі спеціалізованих чипів, прискорювачів і розподілених систем важливо вміти проєктувати програму з урахуванням апаратних обмежень і можливостей. LLM поки що не здатні повноцінно враховувати всі нюанси продуктивності, кешування, мережевих затримок та енергоспоживання на рівні системного дизайну.
Нарешті, інтеграція. Коли системи стають агентними й багатокомпонентними, інтеграція перестає бути «останнім етапом» і стає постійною задачею. Потрібні інженери, які вміють бачити всю картину: як пов’язані між собою сервіси, моделі, дані, агенти, які є вузькі місця, де виникають конфлікти політик чи дублювання функцій.
Вибух коду і технічний борг: темна сторона швидкої генерації
Одним із найменш обговорюваних, але критично важливих наслідків масового впровадження кодогенерації є різке зростання обсягів коду й складності систем.
Коли написати новий модуль, сервіс чи навіть цілий застосунок стає справою годин, а не тижнів, виникає спокуса просто генерувати більше. Більше фіч, більше інтеграцій, більше «тимчасових рішень», які так і залишаються в продакшені.
Учасники дискусії прямо говорять про це: швидке створення коду й «повністю автоматизованих end-to-end пайплайнів» веде до:
– збільшення кількості систем і підсистем,
– зростання обсягів кодової бази,
– ускладнення архітектури,
– накопичення технічного боргу.
Постає низка незручних запитань, на які тепер мають відповідати інженери:
Чи потрібен увесь цей згенерований код?
Чи можна скоротити кодову базу без втрати функціональності?
Як керувати версіями, залежностями й конфігураціями в світі, де код з’являється й змінюється набагато швидше, ніж раніше?
Як забезпечити спостережуваність і керованість системи, яка складається з десятків або сотень агентів і сервісів?
Відповіді на ці питання вимагають глибокого розуміння системи в цілому. Це ще один аргумент на користь того, що роль інженера зміщується від «локального виконавця задач» до «системного мислителя», здатного бачити й керувати загальною складністю.
Цей вибух технічного боргу також підштовхує до переосмислення практик розробки. Класичні підходи до рефакторингу, рев’ю коду, управління залежностями можуть виявитися недостатніми, коли значна частина коду створюється й оновлюється автоматично. Потрібні нові інструменти й методології, орієнтовані на аудит і оптимізацію саме агентних систем і згенерованих кодових баз.
Освіта та онбординг: коли «пісочниця для джунів» зникає
Окрема проблема, на яку звертають увагу в IBM, — це онбординг нових інженерів і підготовка студентів.
Традиційно початківці отримували відносно прості задачі: написати модуль, реалізувати фічу, виправити баг. Це була своєрідна «пісочниця», де можна було вчитися на практиці, не ризикуючи критичною частиною системи.
Сьогодні значна частина таких задач автоматизується кодогенераторами. Це означає, що:
– класичні entry-level ролі в їхньому старому вигляді скорочуються,
– очікування до новачків зростають — від них одразу хочуть більш системного мислення,
– компаніям складніше будувати траєкторії розвитку «з нуля», коли базові задачі виконують моделі.
Це створює виклик і для університетів, і для бізнесу. Якщо «пісочниця» зникає, потрібно створювати нові формати навчання й практики, які готуватимуть студентів до ролей оркестраторів і аудиторів, а не лише до ролей «кодерів».
Учасники панелі прямо говорять: освіта й тренінги для інженерів мають змінитися, щоб встигати за світом AI-генерованого коду. Потрібно вчити не тільки синтаксис і алгоритми, а й:
– системну архітектуру в умовах агентних систем,
– верифікацію й аудит AI,
– безпеку й етику в роботі з моделями,
– оптимізацію й апаратно-програмну ко-дизайн,
– управління технічним боргом у швидко змінних системах.
Без цього ризик розриву між можливостями інструментів і компетенціями людей лише зростатиме.
Висновок: інженерія ПЗ не зникає — вона стає складнішою
Дискусія в IBM малює не апокаліптичну, а радше складну й багатовимірну картину майбутнього програмної інженерії.
З одного боку, базові задачі кодування дедалі частіше виконують генеративні моделі. Entry-level ролі в їхньому традиційному вигляді скорочуються, а обсяги коду й складність систем стрімко зростають. Це створює нові ризики технічного боргу й керованості.
З іншого боку, з’являється цілий пласт нових ролей і задач: проєктування агентних систем, оркестрація моделей і сервісів, аудит поведінки агентів, верифікація, оптимізація, безпека, ко-дизайн з апаратурою. Розробники стають оркестраторами, тестувальники — аудиторами, а програмне забезпечення — мережею взаємодіючих агентів.
У цьому світі виграють не ті, хто пише більше рядків коду, а ті, хто краще розуміє системи, ризики й поведінку агентів. Інженерія ПЗ не зникає — вона стає більш стратегічною, міждисциплінарною й відповідальною. І саме від того, як швидко освіта, бізнес і самі інженери адаптуються до ролі «будівельників і аудиторів агентів», залежатиме, наскільки керованим і безпечним буде перехід до Software 4.0.
Джерело
The future of software engineering, tokenmaxxing and AI in higher education — IBM Technology