Опубліковано
Оновлено
Програмна індустрія активно впроваджує штучний інтелект (ШІ) для написання коду, проте стикається з серйозними труднощами щодо забезпечення його стабільності після випуску.
Опитування 200 керівників відділів з надійності систем (site reliability) та DevOps у великих підприємствах США, Великої Британії та Європейського Союзу виявило значні приховані витрати, пов’язані з бумом кодування за допомогою ШІ. Згідно зі звітом Lightrun “2026 State of AI-Powered Engineering Report”, який ексклюзивно надано VentureBeat до офіційного випуску, 43% змін коду, згенерованих ШІ, потребують ручного налагодження (debugging) у виробничому середовищі навіть після проходження тестів контролю якості та етапів попереднього розгортання. Жоден респондент не заявив, що їхня організація може перевірити виправлення, запропоноване ШІ, лише за один цикл повторного розгортання; 88% повідомили про необхідність від двох до трьох циклів, тоді як 11% потребували чотирьох-шести циклів.
Ці висновки з’являються в час, коли код, згенерований ШІ, стрімко поширюється у глобальних підприємствах. Керівники Microsoft Сатья Наделла та Google Сундар Пічаї стверджують, що близько чверті коду їхніх компаній тепер генерується ШІ. Ринок AIOps (платформ та послуг для управління та моніторингу операціями, керованими ШІ) у 2026 році оцінюється в 18,95 мільярда доларів США і, за прогнозами, досягне 37,79 мільярда доларів до 2031 року.
Проте звіт свідчить, що інфраструктура, призначена для виявлення помилок, згенерованих ШІ, значно відстає від можливостей ШІ у їх створенні.
“Нульовий показник свідчить про те, що інженерія досягає стіни довіри щодо впровадження ШІ”, – заявив Ор Маймон, директор з бізнесу 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 рік, один цикл повторного розгортання в середньому триває від одного дня до одного тижня. У регульованих галузях, таких як охорона здоров’я та фінанси, вікна розгортання часто обмежені, регулюються обов’язковими “заморозками коду” (code freezes) та суворими протоколами управління змінами. Необхідність трьох або більше циклів для валідації одного виправлення ШІ може розтягнути терміни усунення проблеми з днів до тижнів.
Маймон відкинув ідею, що ці множинні цикли є ознакою обачної інженерної дисципліни. “Це не дисципліна, а дороге вузьке місце та симптом того, що виправлення, згенеровані ШІ, часто ненадійні”, – сказав він. “Якщо ми зможемо перейти від трьох циклів до одного, ми повернемо значну частину цих 38% втраченої інженерної потужності”.
Інструменти моніторингу ШІ не бачать, що відбувається всередині працюючих додатків – і це справжня проблема
Якщо втрата продуктивності є найбільш помітною вартістю, звіт Lightrun стверджує, що глибша структурна проблема полягає в тому, що він називає “прогалиною видимості під час виконання” (runtime visibility gap) – неможливості інструментів ШІ та існуючих систем моніторингу спостерігати за тим, що насправді відбувається всередині працюючих додатків.
Шістдесят відсотків респондентів опитування назвали відсутність видимості поведінки системи в реальному часі основним вузьким місцем у вирішенні виробничих інцидентів. У 44% випадків, коли інструменти SRE на основі ШІ або моніторингу продуктивності додатків (APM) намагалися дослідити виробничі проблеми, вони зазнали невдачі, оскільки необхідні дані рівня виконання – стани змінних, використання пам’яті, потік запитів – взагалі не були захоплені.
Звіт малює картину інструментів ШІ, які працюють практично наосліп у найважливіших середовищах. Дев’яносто сім відсотків інженерних керівників заявили, що їхні ШІ-агенти SRE працюють без значної видимості того, що насправді відбувається у виробничому середовищі. Приблизно половина всіх компаній (49%) повідомила, що їхні ШІ-агенти мають лише обмежену видимість станів виконання в реальному часі. Лише 1% повідомили про широку видимість, і жоден респондент не заявив про повну видимість.
Це та прогалина, яка перетворює незначну програмну помилку на дорогу зупинку роботи. Коли виправлення, запропоноване ШІ, зазнає невдачі у виробничому середовищі – як це відбувається у 43% випадків – інженери не можуть покладатися на свої інструменти ШІ для діагностики проблеми, оскільки ці інструменти не можуть спостерігати за поведінкою коду в реальному часі. Натомість команди повертаються до того, що звіт називає “традиційними знаннями” (tribal knowledge): інституційна пам’ять старших інженерів, які бачили подібні проблеми раніше і можуть інтуїтивно зрозуміти першопричину з досвіду, а не з даних. Опитування виявило, що 54% вирішень інцидентів високої тяжкості покладаються на традиційні знання, а не на діагностичні дані від ШІ SRE або APM.
У фінансовій сфері 74% інженерних команд довіряють людській інтуїції більше, ніж діагностиці ШІ під час серйозних інцидентів
Дефіцит довіри особливо гостро проявляється у фінансовому секторі. У галузі, де одна помилка програми може призвести до втрат у мільйони доларів за хвилину, опитування показало, що 74% інженерних команд фінансових послуг покладаються на традиційні знання, а не на автоматизовані діагностичні дані під час серйозних інцидентів – значно більше, ніж 44% у технологічному секторі.
“Фінансова сфера – це сильно регульоване середовище з високими ставками, де одна помилка програми може коштувати мільйони доларів на хвилину”, – сказав Маймон. “Дані показують, що ці команди просто не довіряють ШІ, що він не зробить небезпечної помилки у їхніх виробничих середовищах. Це раціональна відповідь на збій інструментів”.
Недовіра поширюється і за межі фінансів. Мабуть, найбільш показовим даним у всьому звіті є те, що жодна з опитаних організацій – у будь-якій галузі – не перевела свої ШІ SRE інструменти у фактичні виробничі робочі процеси. Дев’яносто відсотків залишаються в експериментальному або пілотному режимі. Решта 10% оцінили ШІ SRE інструменти і вирішили не впроваджувати їх взагалі. Це становить надзвичайну розбіжність між ентузіазмом ринку та операційною реальністю: підприємства агресивно витрачають кошти на ШІ для ІТ-операцій, але інструменти, які вони купують, залишаються в “карантині” поза середовищами, де вони могли б принести найбільшу користь.
Маймон описав це як одне з найважливіших відкриттів звіту. “Керівники прагнуть впроваджувати ці нові інструменти ШІ, але вони не довіряють ШІ втручатися в робочі середовища”, – сказав він. “Відсутність довіри підтверджується даними: 98% мають меншу довіру до ШІ, що працює у виробництві, ніж до помічників з кодування”.
Індустрія спостережуваності (observability), створена для інженерії людської швидкості, не справляється в епоху ШІ
Висновки ставлять гострі запитання щодо поточного покоління інструментів спостережуваності від таких великих постачальників, як Datadog, Dynatrace та Splunk. Сімдесят сім відсотків опитаних інженерних керівників повідомили про низьку впевненість або її відсутність у тому, що їхній поточний стек спостережуваності надає достатньо інформації для автономного аналізу першопричин або автоматизованого усунення інцидентів.
Маймон не ухилявся від визначення структурної проблеми. “Великі постачальники часто створюють екосистеми з “закритим садом” (closed-garden), де їхні ШІ SRE можуть аналізувати лише дані, зібрані їхніми власними пропрієтарними агентами”, – сказав він. “У сучасному підприємстві команди зазвичай використовують стек з кількох інструментів для повного покриття. Змушуючи команду використовувати єдиного постачальника, ці інструменти створюють незручну залежність та стратегічну вразливість: якщо в покритті даних постачальника відсутній певний рівень, ШІ фактично сліпий до першопричини”.
Друга проблема, як стверджував Маймон, полягає в тому, що поточні рішення SRE на базі ШІ, що підтримуються спостережуваністю, пропонують лише часткову видимість – визначену тим, що інженери вважали за потрібне зареєструвати на момент розгортання. Оскільки збої рідко йдуть за заздалегідь визначеними шляхами, автономний аналіз першопричин за допомогою лише цих інструментів часто пропускає ключові діагностичні докази. “Щоб рухатися до справжнього автономного усунення”, – сказав він, – “індустрія повинна перейти до ШІ SRE без прив’язки до постачальника; ШІ SRE повинні бути активним учасником, який може з’єднуватися через весь стек і запитувати живий код для захоплення істини збою в момент його виникнення”.
На запитання, що необхідно для довіри до ШІ SRE, респонденти опитування одностайно вказали на видимість виконання в реальному часі. П’ятдесят вісім відсотків заявили, що їм потрібна здатність надавати “траси доказів” (evidence traces) змінних у точці збою, а 42% згадали можливість перевірити запропоноване виправлення перед його фактичним розгортанням. Жоден з респондентів не вибрав можливість приймати кілька джерел логів або надавати кращі пояснення природною мовою – це свідчить про те, що інженерні керівники хочуть не ШІ, який краще говорить, а ШІ, який краще бачить.
Питання вже не в тому, чи використовувати ШІ для кодування, а в тому, чи можна довіряти тому, що він виробляє
Опитування проводилося незалежною фірмою Global Surveyz Research, і в ньому взяли участь директори, віце-президенти та керівники вищої ланки (C-level) на посадах SRE та DevOps у підприємствах з 1500 або більше співробітниками у фінансовому, технологічному та інформаційно-технологічному секторах. Відповіді були зібрані в січні та лютому 2026 року, з питаннями, що рандомізувалися для запобігання упередженості порядку.
Lightrun, яка має фінансування в розмірі 110 мільйонів доларів від Accel та Insight Partners і серед своїх корпоративних клієнтів має AT&T, Citi, Microsoft, Salesforce та UnitedHealth Group, має явний комерційний інтерес до проблеми, описаної у звіті: компанія продає платформу спостережуваності під час виконання, розроблену для надання ШІ-агентам та інженерам реального часу видимості виконання живого коду. Її продукт AI SRE використовує з’єднання Model Context Protocol для генерації діагностичних доказів у точці збою без необхідності повторного розгортання. Цей комерційний інтерес не применшує висновків опитування, які тісно узгоджуються з незалежними дослідженнями Google DORA та реальними свідченнями про збої в Amazon.
В сукупності вони описують галузь, яка стикається з незручним парадоксом. ШІ вирішив найповільнішу частину створення програмного забезпечення – написання коду – тільки для того, щоб виявити, що написання ніколи не було найскладнішою частиною. Складною частиною завжди було знати, чи воно працює. І щодо цього питання, інженери, які найближче до проблеми, не налаштовані оптимістично.
“Якщо прогалина видимості виконання не буде закрита, то команди фактично лише посилюють нестабільність через впровадження ШІ”, – сказав Маймон. “Організації, які не подолають цю прогалину, опиняться в пастці довгих циклів повторного розгортання, вирішуючи дедалі складніші виклики. Вони втратять свою конкурентну швидкість через ті самі інструменти ШІ, які мали б її забезпечити”.
Машини навчилися писати код. Ніхто не навчив їх спостерігати за його виконанням.
Як захиститися (Порада ІТ-Блогу): Завжди критично оцінюйте код, згенерований ШІ, і не розгортайте його у виробниче середовище без ретельної перевірки, включаючи ручне тестування та аналіз експертами. Налаштуйте комплексний моніторинг та процеси спостережуваності, які надають детальну інформацію про поведінку вашого застосунку під час виконання.
Джерело новини: venturebeat.com