Під час живого запису подкасту Mixture of Experts в офісі IBM One Madison у Нью-Йорку, в межах New York Tech Week, керівники IBM з напрямів AI‑платформ, автоматизації та консалтингу розповіли, як штучний інтелект уже змінює саму тканину розробки програмного забезпечення. У центрі цієї трансформації — внутрішній AI‑асистент IBM під назвою Bob, який не просто підказує рядки коду, а вбудований у весь життєвий цикл створення програм: від збору вимог до деплойменту.
Це не чергова історія про «Copilot для програмістів». Усередині IBM йдеться про спробу автоматизувати end‑to‑end SDLC, скорочуючи проєкти, які раніше тривали 6–8 місяців, до приблизно одного місяця. І робиться це не в лабораторії, а в реальних командах, де тисячі розробників уже працюють з Bob у рамках одного з підрозділів компанії.
Від генерації коду до автоматизації всього SDLC
Ключова відмінність підходу IBM у тому, що AI‑асистент розглядається не як «розумний редактор коду», а як шар над усім процесом розробки. Bob використовується для підсилення кожного етапу SDLC — від перших розмов про бізнес‑вимоги до вибору хмари для продакшн‑запуску.
У класичній моделі розробки більшість інструментів зосереджені на етапі кодування. Навіть сучасні генератори коду на базі LLM — від GitHub Copilot‑подібних рішень до Codex — в основному допомагають саме на рівні написання функцій, класів, тестів. IBM пішла далі й побудувала над цими «двигунами» окремий «harness» — обв’язку, яка дозволяє залучати AI на кожному кроці.
На вході — контекстна інженерія та керування пам’яттю: системі подається максимум релевантної інформації про домен, бізнес‑процеси, наявні системи, нефункціональні вимоги. Далі AI формує початкові вимоги, створює високорівневий і низькорівневий дизайн, генерує код, будує тести й допомагає з деплойментом. Усе це відбувається в інтерактивному режимі, де інженери можуть переглядати, уточнювати й коригувати артефакти, але вже не виконують левову частку рутинної роботи вручну.
У консалтингових командах IBM, які займаються кастомним розробленням для клієнтів, це вже не теоретична можливість, а робочий інструмент. Там, де раніше типовий проєкт розтягувався на пів року чи більше, зараз компанія експериментує з циклами близько одного місяця. І, за оцінками самих інженерів, можливості, які вони мають у Q2 2026 року, просто не існували ще в Q4 2024‑го.
Швидкість еволюції: два роки, які змінили інструментарій
Фраза про те, що «те, чим ми користуємося зараз, не існувало півтора року тому», у світі AI звучить часто. Але в IBM це не загальне враження, а конкретний досвід команд, які будують кастомні системи для великих клієнтів.
За цей період змінилися не лише окремі моделі, а й сам підхід до інтеграції AI в розробку. Якщо ще наприкінці 2024 року мова йшла переважно про використання окремих кодових моделей — на кшталт Bob, Codex чи хмарних Copilot‑аналогів — то до середини 2026‑го IBM вже оперує зв’язкою з кількох двигунів, об’єднаних у єдину інженерну оболонку.
Ця оболонка дозволяє:
по‑перше, розглядати SDLC як безперервний ланцюжок, де AI присутній з першої зустрічі з бізнес‑замовником, а не «підключається» лише на етапі написання коду;
по‑друге, працювати з контекстом на рівні всієї системи — від бізнес‑процесів до інфраструктурних обмежень — і використовувати його для генерації вимог, дизайну, тестів і сценаріїв деплойменту;
по‑третє, комбінувати різні кодові двигуни залежно від задачі, не змушуючи розробника вручну обирати модель чи сервіс.
Результат — не просто прискорення кодування, а стиснення всього життєвого циклу. Там, де раніше місяці йшли на узгодження вимог, написання документації, ручний дизайн і поетапну реалізацію, значна частина цих кроків тепер відбувається паралельно й напівавтоматично.
Цікаво, що всередині IBM до цього підходу ставилися спочатку з обережним скепсисом. Досвідчені розробники, які починали кар’єру ще на мейнфреймах, звикли довіряти лише тому коду, який написали й перевірили самі. Але саме робота з реальними проєктами — а не демо — поступово змінила ставлення: AI‑асистент виявився здатним не лише генерувати синтаксично коректний код, а й тримати в полі зору цілісну архітектуру системи.
Bob як багатомодельний двигун SDLC, а не просто «Copilot»
Фундамент IBM‑івського підходу — багатомодельність. Усередині компанії Bob — це не одна конкретна LLM, а оркестратор, який вміє працювати з різними типами моделей: від «фронтирних» гігантів до відкритих рішень і власних малих мовних моделей IBM. Для кінцевого користувача ця складність прихована: Bob не показує, яка саме модель використовується в конкретний момент, а самостійно обирає оптимальний варіант «під капотом».
Цей вибір ґрунтується на балансі між вартістю, якістю та продуктивністю, який у компанії описують як підхід у стилі Парето‑фронтиру. Іншими словами, система намагається знайти таку конфігурацію, де неможливо покращити один параметр (наприклад, якість) без помітного погіршення іншого (наприклад, вартості чи затримки).
У практичному вимірі це означає, що:
для простих чи локальних задач Bob може спрямувати запит до малої або навіть локальної моделі, зменшуючи витрати й затримку;
для складних, контекстно насичених кроків SDLC — наприклад, формування архітектурного дизайну чи складних тестових сценаріїв — можуть залучатися потужніші моделі;
для задач, де критичною є конфіденційність або специфіка домену, можуть використовуватися внутрішні моделі IBM.
Над цим шаром моделей і працює згаданий «harness» — інженерна обв’язка, яка пов’язує генерацію вимог, дизайну, коду, тестів і деплойменту в єдиний процес. Саме вона дозволяє Bob бути не просто «ще одним кодовим двигуном», а системою, що підсилює всю інженерну діяльність.
Від шести місяців до одного: експерименти з повною автоматизацією SDLC
Найамбітніша частина стратегії IBM — спроба автоматизувати SDLC від початку до кінця настільки, щоб типові проєкти, які раніше займали 6–8 місяців, вкладалися приблизно в один місяць. Йдеться не про одиничні пілоти, а про системні експерименти з участю тисяч розробників у межах одного з підрозділів.
У цих експериментах Bob використовується як наскрізний асистент:
на етапі збору вимог AI допомагає структурувати інформацію від замовника, формує початкові вимогові документи, які потім уточнюються людьми;
на рівні архітектури система пропонує варіанти високорівневого й низькорівневого дизайну, враховуючи наявні сервіси, обмеження безпеки, вимоги до продуктивності;
на етапі кодування Bob, разом з іншими двигунами, генерує основний код, допоміжні модулі, тести й скрипти міграції;
у фазі тестування AI створює й запускає тестові сценарії, аналізує результати, пропонує виправлення;
на етапі деплойменту система здатна не лише згенерувати інфраструктурний код, а й запропонувати, куди саме краще розгорнути рішення — в Azure, AWS чи IBM Cloud, з огляду на вимоги й контекст.
Ключовий момент — це не «чорна скринька», яка самостійно запускає все в продакшн. Люди залишаються в контурі ухвалення рішень, але їхня роль зміщується з ручного виконання кожного кроку до перевірки, корекції й оркестрації. Саме завдяки цьому поєднанню автоматизації й людського контролю стає можливим радикальне скорочення термінів без повної втрати прозорості процесу.
IBM не подає ці результати як остаточно вирішену задачу. Навпаки, підкреслюється, що йдеться про експерименти, які «стають кращими з кожним днем». Але вже зараз внутрішні дані показують: там, де Bob інтегрований у повний SDLC, команди можуть братися за складніші задачі й швидше проходити через класичні «вузькі місця» — від затяжних узгоджень вимог до затримок на тестуванні й деплойменті.
Тисячі розробників у реальних командах, а не в лабораторії
Ще один важливий аспект — масштаб. Bob не залишається інструментом для невеликої групи ентузіастів. Усередині одного з підрозділів IBM уже запущені експерименти, у яких беруть участь тисячі розробників. Це дозволяє не лише збирати статистику щодо продуктивності, а й бачити, як AI‑асистент поводиться в різних контекстах: від легасі‑систем до нових хмарних застосунків.
Такий масштаб дає IBM можливість вимірювати вплив Bob на реальну інженерну практику: як змінюється час на виконання типових задач, як зсувається розподіл часу між кодуванням, тестуванням, дизайном, як змінюється структура помилок. Водночас це створює зворотний зв’язок для самої системи: на основі реальних кейсів удосконалюються як моделі, так і «harness» навколо них.
Особливо показовими є результати для молодших інженерів. Внутрішні дослідження IBM демонструють, що Bob дозволяє фахівцям початкового рівня братися за задачі, які раніше вважалися «територією сеньйорів». Один із прикладів — підготовка програмного забезпечення до відповідності вимогам FedRAMP, американського стандарту безпеки для хмарних сервісів, який традиційно вимагає глибокого розуміння регуляторики й архітектури.
З Bob молодший інженер може:
отримати структуроване пояснення вимог;
згенерувати початкові конфігурації й політики безпеки;
перевірити, які частини системи потребують змін;
побачити, де саме в коді чи інфраструктурі є потенційні невідповідності.
Це не скасовує потреби в експертизі, але суттєво знижує поріг входу в складні домени. У результаті компанія може швидше «вирощувати» спеціалістів, а не чекати роками, поки вони наберуться досвіду на нескладних задачах.
Що означає ця трансформація для інженерних команд
Те, що IBM робить із Bob, показує, як змінюється саме поняття «інструментів розробника». Якщо раніше основним полем битви були IDE, системи контролю версій і CI/CD, то тепер у центрі опиняється AI‑шар, який пронизує весь SDLC.
Це має кілька наслідків для організації роботи команд.
По‑перше, зменшується частка ручної, рутинної діяльності на всіх етапах. Замість того щоб тижнями писати вимогові документи, дизайн‑специфікації й тести, інженери отримують початкові артефакти від AI й зосереджуються на перевірці, уточненні та інтеграції.
По‑друге, зростає значення системного мислення. Коли код генерується швидко й у великих обсягах, ключовою стає здатність утримувати цілісну картину: чи потрібен узагалі цей код, як він вписується в архітектуру, які ризики створює з точки зору безпеки, продуктивності, технічного боргу.
По‑третє, змінюється динаміка між рівнями досвіду. Bob позиціонується як асистент рівня «сеньйор» для початківців і як «джуніор» для провідних інженерів. Це означає, що молодші фахівці можуть швидше виходити на продуктивний рівень, а досвідчені — делегувати частину роботи, зберігаючи контроль над критичними рішеннями.
Нарешті, по‑четверте, з’являється можливість переосмислити самі процеси. Якщо SDLC можна стиснути до місяця, то змінюється логіка планування, бюджетування, взаємодії з бізнес‑замовниками. Проєкти стають ближчими до безперервного потоку змін, де AI допомагає швидко проходити через повні цикли, а не лише прискорює окремі фази.
Висновок: SDLC як поле для AI‑ревізії
Те, що IBM робить із Bob, показує, що ера AI в розробці ПЗ — це не лише про «розумні підказки в IDE». Йдеться про ревізію всього життєвого циклу створення програм, де AI стає постійним учасником процесу — від перших розмов про бізнес‑цілі до вибору хмари для продакшн‑запуску.
Швидкість, з якою змінюються інструменти — від Q4 2024 до Q2 2026, — змушує компанії переосмислювати не тільки стек технологій, а й самі процеси, ролі й очікування від інженерних команд. Експерименти IBM із тисячами розробників показують, що автоматизація end‑to‑end SDLC — не футуристичний сценарій, а вже поточна робота, яка стискає шестимісячні проєкти до одного місяця й відкриває молодшим інженерам доступ до задач рівня FedRAMP.
Наскільки далеко можна зайти в цій автоматизації, не втративши контроль і якість, — питання, на яке індустрія ще шукає відповідь. Але вже зараз очевидно: майбутнє розробки ПЗ визначатимуть не лише нові мови й фреймворки, а й те, наскільки глибоко компанії зможуть інтегрувати AI в саму структуру свого SDLC.
Джерело
The future of software engineering, tokenmaxxing and AI in higher education — IBM Technology