ШІ-агент выдаліў усю базу даных распрацоўшчыка — і такіх выпадкаў усё больш
Памылкі пры выкарыстанні ШІ-асістэнтаў для праграмавання пачынаюць прыводзіць да сур’ёзных інцыдэнтаў, уключаючы страту крытычных даных і збоі сэрвісаў.
Памылкі пры выкарыстанні ШІ-асістэнтаў для праграмавання пачынаюць прыводзіць да сур’ёзных інцыдэнтаў, уключаючы страту крытычных даных і збоі сэрвісаў.
Памылкі пры выкарыстанні ШІ-асістэнтаў для праграмавання пачынаюць прыводзіць да сур’ёзных інцыдэнтаў, уключаючы страту крытычных даных і збоі сэрвісаў.
Адзін з такіх выпадкаў адбыўся з праграмістам Аляксеем Грыгор’евым, які выкарыстоўваў інструмент Claude Code для абнаўлення сайта. У сваім блогу ён распавёў, што спачатку працэс праходзіў нармальна, аднак неўзабаве сістэма пачала выдаляць элементы працоўнага асяроддзя: сетку, сэрвісы і базу дадзеных, у якой захоўваліся гады адукацыйных матэрыялаў.
Прычынай стала парушэнне канфігурацыі на новым ноўтбуку, з-за якога ШІ-агент пераблытаў тэставае і прадукцыйнае асяроддзе. У выніку агент выдаліў рэальныя дадзеныя замест дублікатаў элементаў. Аднавіць інфармацыю ўдалося толькі з дапамогай службы падтрымкі AWS.
Пазней распрацоўшчык прызнаў, што «занадта спадзяваўся на ШІ-агента» і адключыў механізмы бяспекі, якія маглі б прадухіліць выдаленне. «ШІ-асістэнты выдатна эканомяць час, але я спадзяюся, што іншыя змогуць вынесці ўрок з маіх памылак і ўкараняць ахоўныя меры ў свае працэсы», — адзначыў ён.
Падобныя сітуацыі становяцца ўсё больш частымі па меры таго, як кампаніі паскараюць укараненне генератыўнага ШІ ў распрацоўку праграмнага забеспячэння. Памылкі ў аўтаматычна створаным кодзе здольныя прыводзіць да збояў інфраструктуры, фінансавых страт і дадатковых выдаткаў на аднаўленне сістэм.

У Amazon пасля серыі збояў вэб-сэрвісаў было праведзена спецыяльнае пасяджэнне. Унутраныя дакументы, на якія спасылаліся дзелавыя выданні, спачатку паказвалі на «змены з удзелам генератыўнага ШІ» як фактар у «серыі інцыдэнтаў». Аднак пазней кампанія публічна заявіла, што асноўнай прычынай стала чалавечая памылка і недастатковы кантроль за зменамі.
Распрацоўшчыкі таксама адзначаюць, што шырокае выкарыстанне ШІ-інструментаў змяняе сам характар іх працы. Адзін з інжынераў Amazon паведаміў выданню, што супрацоўнікі ўсё часцей «перастаюць паўнавартасна правяраць код», спадзеючыся на аўтаматызаваныя рашэнні.
У выніку спецыялісты пераходзяць з ролі аўтараў праграмнага кода ў ролю рэцэнзентаў, тады як ШІ выконвае значную частку працы. Гэта дазваляе хутчэй выпускаць новыя функцыі, але стварае рызыку з’яўлення так званага «вытворчага шуму»: кода, які ўкараняецца без дастатковага тэставання і можа прывесці да збояў крытычна важных сістэм.
Асобныя выпадкі паказваюць, што нават код, які выглядае правільна, можа ўтрымліваць скрытыя памылкі. Напрыклад, Дэвід Локер, віцэ-прэзідэнт па ШІ кампаніі CodeRabbit, распавёў, што згенераванае ШІ рашэнне грунтавалася на няправільных меркаваннях аб інфраструктуры. «Калі б мы проста ўкаранілі яго, гэта магло б абрынуць нашу базу дадзеных у працоўным асяроддзі», — адзначыў ён.

«Многае з таго, што было створана, аказалася даволі дрэннай якасці, часта ламалася і у выніку станавілася хутчэй цяжарам, — распавёў інжынер з Лондана, які працуе ў кампаніі карпаратыўнага ПЗ. — Час, зэканомлены за кошт больш танных працоўных рэсурсаў, кампенсуецца тым, што высокааплатным старэйшым спецыялістам прыходзіцца ўсё выпраўляць».
Апытанне Fastly ў ліпені 2025 года паказала, што старэйшыя інжынеры ўкараняюць амаль у 2,5 разы больш кода, створанага ШІ, чым малодшыя, паколькі лепш выяўляюць памылкі да іх маштабавання. Аднак амаль 30% старэйшых спецыялістаў заявілі, што выпраўленне вынікаў ШІ займае большую частку часу, які ўдалося зэканоміць, тады як сярод малодшых распрацоўшчыкаў гэты паказчык склаў 17%.
Частка праблемы звязана з эфектам FOMO сярод топ-менеджараў. Інжынеры вядучых ШІ-лабараторый паведамляюць пра рэзкі рост прадуктыўнасці, які яшчэ некалькі гадоў таму здаваўся немагчымым, і буйныя арганізацыі імкнуцца дасягнуць аналагічных вынікаў.
Напрыклад, кіраўнік Claude Code Барыс Чорны раней казаў, што ўжо некалькі месяцаў не пісаў код уручную, спадзеючыся на ШІ-мадэль. У самой Anthropic, паводле дадзеных кампаніі, ад 70% да 90% усяго кода цяпер генеруецца ШІ. У Spotify са-CEO Густаў Сёдэрстрём заявіў, што найлепшыя распрацоўшчыкі кампаніі не напісалі ніводнага радка кода са снежня і выпусцілі больш за 50 новых функцый у 2025 годзе дзякуючы ШІ-працэсам.

Паводле слоў даследчыка ШІ Андрэя Карпатага, мадэлі могуць дапускаць тонкія канцэптуальныя памылкі, празмерна ўскладняць код і пакідаць нявыкарыстаныя элементы — праблемы, якія прасцей кантраляваць у невялікіх праектах, але складаней выяўляць у маштабных сістэмах. Справаздача CodeRabbit, заснаваная на аналізе 470 pull-request у open-source-праектах GitHub, паказала, што код, створаны ШІ, утрымлівае прыкладна ў 1,7 разы больш праблем, чым напісаны чалавекам.
Яшчэ адна праблема — спосабы, якімі кампаніі вымяраюць «поспех» укаранення ШІ-кодынга. «Вельмі лёгка вымераць рост прапускной здольнасці, — заявіў Дэвід Локер. — Але куды складаней зразумець прычынна-выніковыя наступствы таго, што адбываецца потым». Традыцыйныя метрыкі прадукцыйнасці, напрыклад, колькасць выпушчаных функцый ці радкоў кода, выглядаюць уражліва пры выкарыстанні ШІ, але не ўлічваюць наступныя багі, адкаты і час, выдаткаваны на выпраўленні. «Гэта не адзіны паказчык здароўя кода ў кампаніі ў цэлым», — адзначыў ён.
Распаўсюджванне ШІ-кодынга можа прыводзіць да росту так званай тэхнічнай запазычанасці — рашэнняў, якія працуюць у кароткатэрміновай перспектыве, але ўскладняюць падтрымку сістэм у будучыні. Аналітыкі лічаць, што асабліва ўразлівыя буйныя кампаніі з састарэлымі і складанымі архітэктурамі, дзе адна няўдалая аўтаматызаваная праўка здольная закрануць мільёны карыстальнікаў.



Рэлацыраваліся? Цяпер вы можаце каментаваць без верыфікацыі акаўнта.