Агентному ШІ потрібно більше тестувальників, а не менше

Агентний ШІ змінює спосіб випуску програмного забезпечення. Асистенти готують запити на злиття, агенти запускають міграції, а боти перевірки запевняють, що зміна безпечна, ще до того, як людина доп’є ранкову каву. У галузі це часто подають як шлях до скорочення кількості фахівців із контролю якості. Такий погляд хибний. Що більшу частину кодової бази створюють машини, то важливішою стає не навичка генерувати код, а незалежно його перевіряти.

Опитування розробників Stack Overflow за 2025 рік показало, що 84% респондентів використовують або планують використовувати інструменти ШІ під час розробки, а 51% професійних розробників користуються ними щодня. Частка позитивних оцінок знизилася до 60%, і більше розробників активно не довіряють точності ШІ (46%), ніж довіряють їй (33%). Найбільше розчарування, на яке вказали 66% респондентів, — це рішення, які майже правильні, але все ж неправильні. За даними дослідження DORA, проведеного Google Cloud у 2025 році, рівень упровадження ШІ серед фахівців із розробки програмного забезпечення становив 90%; понад 80% сказали, що ШІ підвищив продуктивність, однак лише 24% повідомили, що довіряють йому значною або дуже великою мірою. Корисність без довіри — саме та умова, що розширює роботу тестувальника, а не скорочує її.

Швидкість — це ще не доказ

Я працюю інженером із якості програмного забезпечення, зосереджуючись на тестуванні агентних систем і контрольних перевірках CI для коду, створеного ШІ. У нашій команді ми випустили засіб перевірки PR і генератор тестових сценаріїв. Обидва інструменти лише готують чернетки. Жоден із них не перевіряє власну роботу. Це правило важливе, адже агенти говорять упевнено. Але впевненість не означає правильності.

Ми засвоїли цей урок дорогою ціною. Під час пілотного випробування засобу перевірки PR, створеного за допомогою ШІ, одна зміна пройшла CI менш ніж за 4 хвилини. Через два дні на інформаційній панелі наступного етапу з’явилися неможливі значення температури. В одному зі шляхів виконання, який набір тестів ніколи не перевіряв, переплутали масштабування під час перетворення градусів Цельсія на градуси Фаренгейта. У конвеєрі все було зеленим. Продукт працював неправильно. Зелений статус CI, отриманий без перевірки справді складного запитання, — це театр.

Цей випадок — частина ширшої тенденції. У звіті CodeRabbit «Звіт про стан генерації коду ШІ та людьми» проаналізовано 470 запитів на злиття у відкритих проєктах GitHub (320 створених спільно з ШІ, 150 — лише людьми). У змінах, створених за допомогою ШІ, загалом було приблизно в 1,7 раза більше проблем; помилки в логіці та правильності траплялися на 75% частіше, а кількість виявлених проблем із безпекою була до 2,74 раза більшою. У звіті Veracode за 2026 рік «Звіт про безпеку коду, згенерованого генеративним ШІ» перевірено моделі на завданнях із безпеки. Середній відсоток успішного проходження перевірок безпеки становив 56% — лише трохи більше за 55% у попередньому звіті. Водночас приблизно 44% завдань із генерації коду за допомогою ШІ призводили до появи відомої вразливості. Синтаксичну проблему майже розв’язано. Але правильна й безпечна поведінка програм — досі ні. Тестувальники не дозволяють плутати ці два поняття.

Галюциновані залежності — це проблема тестування

Генерація коду також призводить до вигадування пакетів. У дослідженні USENIX Security 2025 року «Ми підготували для вас пакет!» оцінили галюцинації пакетів у 16 великих мовних моделей для генерації коду на 576 000 зразках. Комерційні моделі в середньому галюцинували пакети щонайменше у 5,2% випадків; для моделей із відкритим кодом цей показник становив у середньому 21,7%, а кількість унікальних вигаданих назв сягнула 205 474. Фантомні пакети, що залишаються в обігу, створюють зручну ціль для атак із реєстрацією вигаданих назв: зловмисники реєструють вигадану назву й чекають, поки розробник або агент встановить цей пакет.

Перевірки походження залежностей мають бути на одному рівні з функціональними тестами. Якщо агент вигадує пакет NuGet або npm, злиття має бути заблоковано ще до того, як хтось почне сперечатися, чи достатньо ретельно написані модульні тести. Перевірка походження — не необов’язковий захід для підтримання порядку. Це контрольний бар’єр якості для змін, створених ШІ.

Контрольні бар’єри, що масштабуються разом з агентами

Коли за допомогою автоматизації з підтримкою ШІ ми оновлювали .NET 8 до .NET 10 в усій організації приблизно за два тижні, я відповідав за контрольні бар’єри якості. Швидкість була реальною. Так само реальною була потреба в перевірках, які не вірять підсумкам, сформульованим агентом. Для зміненого коду я застосовую такі перевірки:

• Цільовий показник мутаційного тестування для зміненої логіки — у межах від 60% до 70%, щоб набір тестів виявляв справжні мутації, а не просто охоплював рядки коду
• Тести на основі властивостей для логіки високого ризику, поведінку якої не можна належно описати лише прикладами
• Перевірки походження залежностей для захисту від атак із реєстрацією вигаданих назв і галюцинованих пакетів
• Показники дублювання та частоти змін, які виявляють хаотичне копіювання й перероблення коду агентами
• Незалежна перевірка тверджень агентів, як-от «міграцію завершено», адже твердження — це лише гіпотеза, доки її не підтверджено доказами

Показник мутаційного тестування — не декоративна метрика. Він показує, чи помічають ваші тести навмисно внесені помилки. Покриття коду може зростати, а набір тестів однаково не виявить помилку в шляху перетворення градусів Цельсія. Перевірки на основі властивостей змушують модель системи працювати в усьому діапазоні значень, а не лише в одному сприятливому випадку. Перевірка походження закриває комору з пакетами. Аналіз частоти змін і дублювання виявляє звичку агентів переписувати ту саму ідею трьома різними способами. Разом ці заходи формують підхід: вважати агента неправим, доки набір тестів не доведе протилежного. Під час перевірки коду я постійно тримаюся цього принципу.

Усе це не замінює тестування API, автентифікації, базових сценаріїв чи автоматизоване тестування інтерфейсу. FlaUI та PowerShell і далі виявляють те, чого не помічають API. Пакування через NuGet, MSI та MSM так само потребує перевірки встановлення й роботи в тихому режимі. Агентні робочі процеси збільшують обсяг роботи. Але вони не скасовують цих практик.

Більше тестувальників, інша робота

Побоювання полягає в тому, що тести писатимуть агенти, а люди стануть непотрібними. Агенти можуть створювати тестові сценарії. Але засвідчувати правильність власних чернеток вони не повинні. Учасники опитування Stack Overflow, які планують у майбутньому використовувати ШІ для тестування, також вважають недовіру людей до ШІ одним із ключових чинників: коли їм потрібна була б допомога, найчастіше вони звернулися б до іншої людини, бо не довіряють відповідям ШІ. Цей інстинкт — сильна сторона професії.

Тут важливо наймати й підтримувати людей, які прийшли в професію нетрадиційним шляхом. Я перейшла в тестування якості після кар’єри в операційній діяльності HR і роботі з даними, у травні 2024 року здобула ступінь магістра з інформаційних систем в UMBC, а тепер щодня працюю над тим, щоб контрольні механізми для агентних систем були практичними. Агентний ШІ не чекатиме, поки з’являться фахівці лише з одним типом освіти чи досвіду. Йому потрібно більше людей, здатних проєктувати доказову базу, а не менше тих, хто формально схвалює успішні збірки.

Запитання щодо продукту просте. Якщо агенти випускають оновлення швидше, ніж ваша система перевірки встигає їх осмислити, це не підвищення продуктивності. Це інцидент, який лише відклали. Інвестуйте в тестувальників, які ставляться з підозрою до кожного твердження агента, інтегрують мутаційне тестування й відстеження походження в CI та зберігають незалежність суджень саме там, де модель висловлюється найвільніше, але є найменш надійною. Агентному ШІ потрібно більше тестувальників, а не менше.