Сфера розробки програмного забезпечення переживає справжній вибух: штучний інтелект (ШІ) взявся за написання коду. Однак, схоже, галузь наразі пасе задніх, коли йдеться про забезпечення надійності цього коду після його впровадження.
Опитування 200 керівників вищої ланки, відповідальних за надійність систем (site-reliability) та DevOps у великих підприємствах США, Великої Британії та Європейського Союзу, малює похмуру картину прихованих витрат, пов’язаних із бумом програмування за допомогою ШІ. Згідно зі звітом Lightrun “2026 State of AI-Powered Engineering Report”, який ексклюзивно надано VentureBeat до його публічного виходу, 43% змін коду, згенерованих ШІ, потребують ручного виправлення помилок у продакшн-середовищі, навіть після проходження тестів контролю якості та стендових випробувань. Жоден респондент не заявив, що їхня організація може перевірити виправлення, запропоноване ШІ, лише за один цикл розгортання; 88% повідомили про необхідність двох-трьох циклів, тоді як 11% потребували чотирьох-шести.
Ці висновки з’являються в час, коли код, згенерований ШІ, поширюється глобальними підприємствами з блискавичною швидкістю. І генеральний директор Microsoft Сатья Наделла, і генеральний директор Google Сундар Пічаї стверджують, що близько чверті коду їхніх компаній тепер генерується ШІ. Ринок AIOps — екосистема платформ та послуг, призначених для управління та моніторингу цих операцій, керованих ШІ — оцінюється в 18,95 мільярда доларів у 2026 році, і прогнозується, що до 2031 року він досягне 37,79 мільярда доларів.
Однак, звіт свідчить, що інфраструктура, покликана виявляти помилки, згенеровані ШІ, значно відстає від можливостей ШІ щодо їх створення.
“Нульовий показник свідчить про те, що інженерія досягає стіни довіри з впровадженням ШІ”, — заявив Ор Маймон, директор з бізнесу Lightrun, посилаючись на висновок опитування, згідно з яким жоден керівник інженерного відділу не назвав себе “дуже впевненим” у тому, що код, згенерований ШІ, поводитиметься коректно після розгортання. “Хоча акцент галузі на підвищенні продуктивності зробив ШІ необхідністю, ми спостерігаємо прямий негативний вплив. Коли код, згенерований ШІ, потрапляє в систему, він не просто збільшує обсяг; він сповільнює весь конвеєр розгортання”.
Перебої в роботі Amazon у березні продемонстрували, що відбувається, коли код, згенерований ШІ, впроваджується без запобіжних заходів
Небезпеки вже не є теоретичними. На початку березня 2026 року Amazon пережила низку резонансних збоїв, які підкреслили саме той тип збоїв, який описує опитування Lightrun. 2 березня Amazon.com зазнав перебоїв, що тривали майже шість годин, внаслідок чого було втрачено 120 000 замовлень та виникло 1,6 мільйона помилок на вебсайті. Через три дні, 5 березня, більш серйозний збій вразив вітрину магазину — тривав шість годин і спричинив 99% падіння обсягу замовлень у США, з приблизно 6,3 мільйона втрачених замовлень. Обидва інциденти були пов’язані зі змінами коду за допомогою ШІ, впровадженими в продакшн без належного дозволу.
Наслідки були швидкими. Amazon розпочала 90-денний процес відновлення безпеки коду в 335 критичних системах, і тепер зміни коду за допомогою ШІ повинні бути схвалені старшими інженерами перед їх розгортанням.
Маймон прямо вказав на епізоди з Amazon. “Ця невизначеність не ґрунтується на гіпотезі”, — сказав він. “Нам достатньо озирнутися на початок березня, коли Amazon.com у Північній Америці не працював через зміну, керовану ШІ, реалізовану без встановлених запобіжних заходів”.
Інциденти з Amazon ілюструють основну напругу, яку звіт Lightrun кількісно визначає в даних опитування: інструменти ШІ можуть генерувати код з безпрецедентною швидкістю, але системи, розроблені для перевірки, моніторингу та довіри до цього коду в реальних середовищах, не встигають за темпом. Власний звіт Google DORA за 2025 рік підтверджує цю динаміку, виявивши, що впровадження ШІ корелює зі збільшенням нестабільності коду, і що 30% розробників висловлюють малу або жодної довіри до коду, згенерованого ШІ.
Маймон навів це дослідження безпосередньо: “Звіт Google DORA за 2025 рік виявив, що впровадження ШІ корелює зі збільшенням нестабільності коду майже на 10%. Наші процеси валідації були створені для масштабу людської інженерії, але сьогодні інженери стали аудиторами величезних обсягів незнайомого коду”.
Розробники витрачають два дні на тиждень на налагодження коду, згенерованого ШІ, який вони не писали
Одним із найвражаючих висновків звіту є масштаб людського капіталу, який поглинається роботою з верифікації, пов’язаною з ШІ. Розробники тепер витрачають у середньому 38% свого робочого тижня — приблизно два повні дні — на налагодження, верифікацію та специфічне для середовища усунення несправностей, згідно з опитуванням. Для 88% опитаних компаній цей “податок на надійність” поглинає від 26% до 50% щотижневої спроможності їхніх розробників.
Це не той дивіденд продуктивності, якого очікували керівники підприємств, інвестуючи в помічників з кодування на базі ШІ. Натомість, вузьке місце в інженерії просто перемістилося. Код пишеться швидше, але його перевірка займає набагато більше часу.
“У певному сенсі ШІ погіршив проблему налагодження”, — сказав Маймон. “Обсяг змін перевантажує людську верифікацію, тоді як сам згенерований код часто поводиться не так, як очікувалося, під час розгортання в продакшні. Агенти з кодування на базі ШІ не можуть бачити, як їхній код поводиться в робочих середовищах”.
Проблема повторного розгортання посилює відтік часу. Кожна опитана організація вимагає багаторазових циклів розгортання для перевірки одного виправлення, запропонованого ШІ, — і, згідно зі звітом Google DORA за 2025 рік, один цикл повторного розгортання займає від дня до тижня в середньому. У регульованих галузях, таких як охорона здоров’я та фінанси, вікна розгортання часто є вузькими, регулюються обов’язковими замороженнями коду та суворими протоколами управління змінами. Вимога трьох або більше циклів для перевірки одного виправлення ШІ може перенести терміни вирішення з днів на тижні.
Маймон відкинув ідею, що ці багаторазові цикли є результатом обачної інженерної дисципліни. “Це не дисципліна, а дорогий вузький прохід і симптом того, що виправлення, згенеровані ШІ, часто ненадійні”, — сказав він. “Якщо ми зможемо перейти від трьох циклів до одного, ми повернемо значну частину цих 38% втраченої інженерної спроможності”.
Інструменти моніторингу ШІ не можуть бачити, що відбувається всередині запущених програм — і це справжня проблема
Якщо відтік продуктивності є найбільш помітною витратою, то звіт Lightrun стверджує, що глибшою структурною проблемою є те, що він називає “пробілом видимості в реальному часі” — нездатність інструментів ШІ та існуючих систем моніторингу спостерігати за тим, що насправді відбувається всередині запущених програм.
Шістдесят відсотків респондентів опитування визначили брак видимості поведінки живої системи як основне вузьке місце у вирішенні інцидентів продакшну. У 44% випадків, коли інструменти SRE ШІ або моніторингу продуктивності додатків намагалися дослідити проблеми продакшну, вони зазнавали невдачі, оскільки дані виконання, необхідні для аналізу — стани змінних, використання пам’яті, потік запитів — взагалі не були зібрані.
Звіт малює картину інструментів ШІ, що працюють, по суті, наосліп у найважливіших середовищах. Дев’яносто сім відсотків керівників інженерних відділів заявили, що їхні агенти SRE ШІ працюють без значної видимості того, що насправді відбувається в продакшні. Приблизно половина всіх компаній (49%) повідомили, що їхні агенти ШІ мають лише обмежену видимість станів виконання в реальному часі. Лише 1% повідомили про широку видимість, і жоден респондент не заявив про повну видимість.
Це той пробіл, який перетворює незначну програмну помилку на дорогу аварію. Коли виправлення, запропоноване ШІ, зазнає невдачі в продакшні — як це трапляється з 43% — інженери не можуть покладатися на свої інструменти ШІ для діагностики проблеми, оскільки ці інструменти не можуть спостерігати за поведінкою коду в реальному часі. Натомість команди повертаються до того, що звіт називає “племінним знанням”: інституційною пам’яттю старших інженерів, які бачили подібні проблеми раніше і можуть інтуїтивно визначити першопричину з досвіду, а не з даних. Опитування показало, що 54% вирішень інцидентів високої серйозності покладаються на “племінне знання”, а не на діагностичні дані від SRE ШІ або APM.
У фінансовому секторі 74% інженерних команд довіряють людській інтуїції більше, ніж діагностиці ШІ під час серйозних інцидентів
Дефіцит довіри проявляється особливо інтенсивно у фінансовому секторі. У галузі, де одна помилка програми може призвести до збитків у мільйони доларів за хвилину, опитування показало, що 74% інженерних команд фінансових послуг покладаються на “племінне знання” замість автоматизованих діагностичних даних під час серйозних інцидентів — значно вище, ніж 44% у технологічному секторі.
“Фінанси — це сильно регульоване середовище з високими ставками, де одна помилка програми може коштувати мільйони доларів за хвилину”, — сказав Маймон. “Дані показують, що ці команди просто не довіряють ШІ, що він не зробить небезпечної помилки в їхніх продакшн-середовищах. Це раціональна реакція на збій інструменту”.
Недовіра поширюється за межі фінансів. Можливо, найпоказовішою статистикою в усьому звіті є те, що жодна з опитаних організацій — у будь-якій галузі — не перевела свої інструменти SRE ШІ в реальні робочі процеси. Дев’яносто відсотків залишаються на експериментальному або пілотному рівні. Решта 10% оцінили інструменти SRE ШІ і вирішили їх не впроваджувати. Це становить надзвичайний розрив між ринковим ентузіазмом та операційною реальністю: підприємства агресивно витрачають кошти на ШІ для ІТ-операцій, але інструменти, які вони купують, залишаються ізольованими від середовищ, де вони принесли б найбільшу користь.
Маймон описав це як одне з найзначніших одкровень звіту. “Керівники прагнуть впроваджувати ці нові інструменти ШІ, але вони не довіряють ШІ працювати в реальних середовищах”, — сказав він. “Брак довіри показаний у даних: 98% мають меншу довіру до ШІ, що працює в продакшні, ніж до помічників з кодування”.
Індустрія спостережливості, побудована для інженерії зі швидкістю людини, не справляється в епоху ШІ
Висновки ставлять гострі питання до поточного покоління інструментів спостережливості від таких великих постачальників, як Datadog, Dynatrace та Splunk. Сімдесят сім відсотків опитаних керівників інженерних відділів повідомили про низьку або нульову впевненість у тому, що їхній поточний стек спостережливості надає достатньо інформації для підтримки автономного аналізу першопричин або автоматизованого усунення інцидентів.
Маймон не ухилявся від називання структурної проблеми. “Великі постачальники часто будують екосистеми з “замкненим садом”, де їхні SRE ШІ можуть аналізувати лише дані, зібрані їхніми власними пропрієтарними агентами”, — сказав він. “У сучасному підприємстві команди зазвичай мають стек з багатьох інструментів для повного покриття. Примушуючи команду до одного постачальника, ці інструменти створюють незручну залежність та стратегічний ризик: якщо дані постачальника відсутні для певного рівня, ШІ, по суті, сліпий до першопричини”.
Друга проблема, стверджував Маймон, полягає в тому, що поточні рішення SRE ШІ, що базуються на спостережливості, пропонують лише часткову видимість — визначену тим, що інженери подумали записати на момент розгортання. Оскільки збої рідко йдуть за визначеними шляхами, автономний аналіз першопричин, що використовує лише ці інструменти, часто пропускатиме ключові діагностичні докази. “Щоб рухатися до справжнього автономного усунення”, — сказав він, — “галузь повинна перейти до SRE ШІ без прив’язки до постачальника; SRE ШІ повинні бути активним учасником, який може з’єднуватися з усім стеком і запитувати код у реальному часі, щоб отримати справжні дані про збій під час його виникнення”.
На запитання, що потрібно для довіри до SRE ШІ, респонденти опитування одностайно зійшлися на видимості в реальному часі. П’ятдесят вісім відсотків заявили, що їм потрібна можливість надавати “сліди доказів” змінних у момент збою, а 42% згадали можливість перевірити запропоноване виправлення перед його фактичним розгортанням. Жоден з респондентів не обрав можливість отримувати дані з кількох джерел журналів або надавати кращі пояснення природною мовою — це свідчить про те, що керівники інженерних відділів хочуть не ШІ, який краще говорить, а ШІ, який краще бачить.
Питання вже не в тому, чи використовувати ШІ для кодування — питання в тому, чи може хтось довіряти тому, що він виробляє
Опитування проводилося незалежною фірмою Global Surveyz Research, і в ньому брали участь директори, віце-президенти та керівники вищої ланки, які займають посади SRE та DevOps у підприємствах з 1500 або більше співробітниками у фінансовому, технологічному та інформаційному секторах. Відповіді збиралися протягом січня та лютого 2026 року, запитання були рандомізовані для запобігання упередженості порядку.
Lightrun, яка має підтримку у розмірі 110 мільйонів доларів від Accel та Insight Partners і серед своїх корпоративних клієнтів нараховує AT&T, Citi, Microsoft, Salesforce та UnitedHealth Group, має чіткий комерційний інтерес до проблеми, описаної у звіті: компанія продає платформу спостережливості в реальному часі, призначену для надання агентам ШІ та людським інженерам видимості виконання живого коду в реальному часі. Її продукт SRE ШІ використовує з’єднання за протоколом Model Context Protocol для генерації діагностичних доказів у реальному часі в точці збою без необхідності повторного розгортання. Цей комерційний інтерес не зменшує висновків опитування, які тісно узгоджуються з незалежними дослідженнями Google DORA та реальними доказами збоїв Amazon.
Разом вони описують галузь, що стикається з незручним парадоксом. ШІ вирішив найповільнішу частину розробки програмного забезпечення — написання коду — лише для того, щоб виявити, що написання ніколи не було найскладнішою частиною. Найскладнішою частиною завжди було знати, чи це працює. І щодо цього питання, інженери, найближчі до проблеми, не налаштовані оптимістично.
“Якщо пробіл видимості в реальному часі не буде закрито, то команди, по суті, лише посилюватимуть нестабільність через своє впровадження ШІ”, — сказав Маймон. “Організації, які не подолають цей розрив, опиняться в глухому куті з довгими циклами повторного розгортання для вирішення все більш складних проблем. Вони втратять свою конкурентну швидкість через ті самі інструменти ШІ, які мали б її забезпечити”.
Машини навчилися писати код. Ніхто не навчив їх спостерігати за його виконанням.
Прогноз ІТ-Блогу: Очікується, що найближчі 1-2 роки будуть присвячені розробці більш досконалих механізмів валідації та моніторингу для коду, згенерованого ШІ. Це призведе до появи нових рішень, які інтегруватимуться глибше в процес розробки, а не лише на етапі розгортання, щоби подолати поточний дефіцит довіри.
За матеріалами: venturebeat.com