97% команд розробників використовують ШІ-помічників — лише 30% ними керують

Менш ніж за два роки ШІ-помічники для кодування пройшли шлях від експериментальної цікавинки до стандартної практики. Звіт Black Duck «Стан розробки програмного забезпечення з використанням ШІ» за 2026 рік наводить приголомшливу цифру: 97% команд розробників активно використовують ШІ-інструменти для написання коду . Але за цим заголовком криється значно неприємніший висновок — інфраструктура для перевірки, захисту та управління всім цим кодом просто не встигає.

Лише 30% організацій застосовують повноцінний підхід до управління використанням ШІ . Для решти 70% ШІ генерує код із такою швидкістю, яку наявні робочі процеси не можуть перетравити. Результат — те, що Black Duck називає «зростаючим дефіцитом управління», який непомітно поглинає ті самі переваги в продуктивності, які ці інструменти мали б забезпечити .

Три головні вузькі місця, що знищують виграш від генерації коду

Звіт визначає чітку закономірність: ШІ-інструменти прискорюють написання коду, але ця швидкість створює проблеми скрізь. Дев'ять із десяти команд повідомили про проблеми зі згенерованим ШІ кодом у своїх робочих процесах . Ці проблеми концентруються у трьох ключових етапах, які разом поглинають час, зекономлений раніше:

• Ручна перевірка коду (52%) — рецензенти тепер обробляють більший обсяг коду від ШІ, ніж написаного людьми, і цей обсяг зростає .
• Тестування безпеки (51%) — код від ШІ привносить нові класи вразливостей, відсутні в рукописному еквіваленті. Особливо це стосується ін'єкцій залежностей, жорстко закодованих секретів і застарілих бібліотек .
• Переробка згенерованого коду (48%) — майже половина команд витрачає значний час на виправлення, рефакторинг або переписування результатів роботи ШІ перед тим, як код можна буде використовувати .

Ця тенденція вже отримала назву: зсув рутини. Замість усунення роботи, ШІ переміщує її з фази створення на фази верифікації, тестування та виправлення . Black Duck формулює це відверто: «Більшість організацій генерують ШІ-код швидше, ніж можуть його перевірити, захистити або керувати ним» .

Управління: головний мультиплікатор рентабельності інвестицій

Якщо і є один висновок зі звіту, на який варто звернути увагу технічним керівникам, то це такий: управління є тим самим мультиплікатором ROI . Різниця між командами, які контролюють використання ШІ, і тими, хто ні, не є незначною — це різниця між отриманням приросту ефективності та спостереженням, як він витікає крізь пальці.

Black Duck виявили, що організації з повноцінними рамками управління повідомили про 90% значного підвищення ефективності від ШІ-інструментів. Для команд без структурованого нагляду цей показник падає до 44% .

Управління в цьому контексті — це не бюрократія. Це наявність чітких політик щодо того, які інструменти використовуються, як перевіряється згенерований код, які безпекові перевірки він має пройти і хто несе відповідальність за результат. Це різниця між «розробники використовують усе, що хочуть» і «розробники використовують затверджені інструменти в структурованому, перевірюваному процесі».

Проблема тіньового ШІ

Ускладнює управління поширення Тіньового ШІ — коли розробники використовують інструменти всупереч або поза межами політики компанії. Black Duck виявили, що 18% організацій вважають тіньовий ШІ значним некерованим ризиком . Коли такі інструменти, як Cursor, Windsurf чи Claude Code, впроваджуються на рівні окремого розробника без проходження закупівель чи безпекової перевірки, організація втрачає видимість своєї поверхні атаки .

Ризики ланцюга постачання: що успадковує код, згенерований ШІ

Наслідки для ланцюга постачання — це те місце, де прогалини в управлінні стають конкретними вразливостями. Робота Black Duck, включно з пов'язаним звітом 2026 OSSRA, виявляє три взаємопов'язані ризики, характерні саме для ШІ-помічників:

«Відмивання» ліцензій. ШІ-помічники, навчені на репозиторіях з відкритим кодом, можуть генерувати фрагменти коду з джерел із жорсткими авторськими правами (copyleft), не зберігаючи оригінальну ліцензійну інформацію . Звіт OSSRA за 2026 рік показав, що дві третини перевірених кодових баз містять ліцензійні конфлікти — найвищий показник в історії звіту . Організації можуть постачати код, на використання якого вони не мають прав, навіть не підозрюючи про це.

Вибухове зростання залежностей. Кількість компонентів з відкритим кодом у кодових базах зросла на 30% у річному вимірі, а середня кількість вразливостей підскочила на 107% . ШІ-помічники прискорюють цю тенденцію, оскільки вони компонують рішення швидше і з ширших навчальних масивів — тобто кожна згенерована функція може потягнути за собою залежності, які розробник не обирав свідомо.

Прогалина у відповідності. Лише 24% організацій проводять комплексну оцінку згенерованого ШІ коду на предмет інтелектуальної власності, ліцензій, безпеки та якості . Це означає, що три чверті компаній не можуть надійно відповісти на питання: «Які юридичні та безпекові зобов'язання ми щойно взяли на себе?»

Довіра розробників: впровадження зростає, а впевненість падає

Висновки Black Duck не є поодинокими. Кілька незалежних опитувань, опублікованих приблизно в той самий період, підтверджують і доповнюють картину довіри більш детальними даними:

• Опитування розробників Sonar «Стан коду» за 2026 рік (понад 1 100 розробників) виявило, що 96% розробників не довіряють повністю функціональній точності згенерованого ШІ коду . Проте лише 48% завжди перевіряють його перед внесенням — тобто код, якому самі розробники не довіряють, регулярно потрапляє в продакшн .
• Опитування розробників Stack Overflow за 2025 рік (49 009 респондентів) показало, що довіра до точності ШІ впала з 40% до 29% за один рік. Активна недовіра зросла до 46%, а позитивне ставлення знизилося з 72% до 60% .
• Звіт Harness «Стан релізів ПЗ з використанням ШІ, 2026» (500 технічних керівників) виявив, що 57% все ще вимагають обов'язкової перевірки людиною кожного рядка коду від ШІ, а 29% витрачають на перевірку більше часу, ніж до впровадження помічників .

Консенсус усіх цих опитувань напрочуд послідовний: розробники не можуть працювати без ШІ-інструментів, але й не можуть повністю їм довіряти. Розрив між генерацією та верифікацією став новим вузьким місцем.

Діана Келлі, директорка з інформаційної безпеки в Noma Security, влучно сформулювала головну суперечність: «Швидший код — це не те саме, що безпечніший код» .

Як насправді виглядає управління

Поради Black Duck не є абстрактними. Звіт вказує на набір конкретних заходів, які вирізняють ті 30% з повним управлінням серед решти:

1. Структуровані рамки управління ШІ — не неформальні настанови, а задокументовані, обов'язкові до виконання політики, що охоплюють затвердження інструментів, перевірку результатів і відповідальність
2. Інтегровані в пайплайн етапи перевірки — відхід від ручних черг на тестування безпеки, які досі використовують 46% компаній, у бік автоматизованих перевірок якості та безпеки, що запускаються при кожному коміті, зробленому за допомогою ШІ
3. Постійний моніторинг після розгортання — Black Duck зазначає, що «стратегії лише „shift-left“ більше недостатньо», оскільки ризики виникають, виявляються та мають керуватися протягом усього життєвого циклу розробки програмного забезпечення
4. Раціоналізація інструментів безпеки — понад 71% респондентів назвали розпорошеність інструментів (tool sprawl) головним джерелом тертя, і консолідація на меншій кількості краще інтегрованих інструментів є передумовою для безпечного масштабування ШІ

Підсумок

Звіт Black Duck не виступає проти використання ШІ-помічників. Він стверджує, що використовувати їх без відповідного управління — це стріляти собі в ногу. Коли 97% команд генерують код із безпрецедентною швидкістю, але лише 30% мають інфраструктуру нагляду для керування ним, індустрія колективно виписує чеки, які не може оплатити.

Кореляція між управлінням і приростом ефективності — 90% проти 44% — робить бізнес-обґрунтування однозначним. Організації, які спершу побудують «перила безпеки», отримають ту продуктивність, яку обіцяє ШІ. Ті ж, хто цього не зробить, будуть постійно переконуватися, що час, зекономлений за клавіатурою, витрачається в черзі на перевірку коду.