Код AI містить більше помилок, але QA врятують світ?

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до QA спільноти!

У популярних фантастичних фільмах трапляється повстання машин. І світ рятують вони, прості супергерої-розробники, Джон Коннор, що з підліткового віку мав ноутбук ціною в половину місячної зарплати розробника в США, або Нео (Томас Андерсон), що розробляв вдень якісь банківські штуки а вночі «хакав» — вбивав безліч сайтів, проникав у захищені системи, «зламував» програми і продавав вкрадені/змінені програми.

Сьогдні ж у реальному світі з появою ШІ софтверні гіганти стали скорочувати розробників. Більш того, активно впроваджується думка, що за допомогою ШІ розробники можуть тепер писати більше коду. Частково це правда, однак найновіші дослідження показують зворотний бік медалі.

Звіт CodeRabbit (2025) проаналізував 470 open-source pull request’ів: AI-код має в середньому 10.83 issues на PR проти 6.45 у людському коді (1.7x більше), з вищою частотою критичних (1.4x) та major issues (1.7x). Це призводить до довших рев’ю та більшого ризику дефектів у продакшені.(ПОСИЛАННЯ1, Посилання2)

Додаткові дані з Of Ash and Fire (2026) фіксують зростання інцидентів на 23.5% на PR попри 20% збільшення продуктивності через ШІ. Аналогічні патерни: логічні помилки (1.75x), проблеми з безпекою (1.57x), продуктивністю (1.42x) та читабельністю (3x).

Один з найновіших звітів, розміщених 17 днів тому каже:

на 9% збільшення кількості помилок на одного розробника з моменту впровадження інструментів штучного інтелекту

на 154% більший середній розмір PR

Відповідно довші цикли перевірки коду, незважаючи на швидшу генерацію коду

Математика:

50-рядковий PR: Можливо, 5-10 потенційних граничних випадків для розгляду 400-рядковий PR, згенерований штучним інтелектом: 50+ потенційних граничних випадків

Рецензенти були перевантажені. Втома від рецензування призвела до однозначного схвалення замість глибокого рецензування.

(ПОСИЛАННЯ)

Загалом, це все можна описати як «замкнене коло зростання багів з ШІ»:

1. ШІ пише більше коду
2. в коді ШІ більше помилок
3. люди «виснажуються» або довіряють ШІ
4. код віш ШІ отримує менше перевірки
5. більше помилок у коді що потрапляє коритувачу
6. треба писати додатковий код або перевірки і ми повертаємося на крок #1.

Мало яка з сучасних статей про ШІ не вказує на цю проблему, як на зростання «технічного боргу».

Хто тестує цей район?

Раніше якість коду забезпечувалася тестовим покриттям, що створювалося (1) розробниками і (2) тестувальниками. Однак з кодом від ШІ може бути таке:

1. юніт-тестів немає
2. юніт-тести писав сам ші і вони часто хибнопозитивні або не враховують всі випадки
3. API або інтеграційних тестів немає, бо довіра до ШІ або брак часу
4. API або інтеграційні тести згенеровані ШІ — часто хибнопозитивні або не враховують всі випадки.

При тому, за аналізом статистики складається стійке враження, що тестування програмного забезпечення раптом стало непотрібним (ну бо ШІ ж не помиляється, так?)

Так за даними платформи herohunt вакансії AI/ML Engineer зросли на 143% у 2025 (порівняно з 2024)(LinkedIn), до 49 200 у США, та на 334% глобально (Indeed). В Україні кількість AI-спеціалістів зросла в 5 разів за 10 років, з фокусом на розробників (6 100 спеціалістів)

В той же час AI QA ролі ростуть на 48% (порівняно з 2024)

І я навіть омину увагою гіганський зарплатний розрив.

Просто задумайтеся, з врахуванням того, що код ШІ потребує більше тестування кількість AI QA повинна зростати так само як AI Developer або й випереджати їх, а ми спостерігаємо картину фактичного зменшення і скорочення тестування.

Що уже є і що буде

Комбінація більшого обсягу ШІ-коду з вищою частотою помилок та меншою кількістю тестувальників створює ризик «лавини багів» (bug explosion), що вже фіксується в дослідженнях 2025-2026 рр.

Наслідки для якості

Без адаптації QA (shift-left testing, AI-автотести) дефекти поширюються швидше: flaky tests, integration failures та регресії досягають продакшену. Дослідження LinearB (8.1M PR) фіксують 7.2% падіння стабільності систем та довший дебагінг, що нівелює продуктивність.

Рекомендації

Команди впроваджують AI-QA інструменти (знижують час тестів на 35-50%, false positives на 25%), але потрібні спеціалізовані практики для AI-коду.

Ну і світ врятують не розробники. Світ врятує тестування коду, згенерованого ШІ (або ні, і уже надто пізно)