ШІ-сміття атакує open source: чому розробники опинилися на межі

Генеративний ШІ мав зробити програмування швидшим, але для багатьох open source-розробників він перетворився на машину з виробництва зайвої роботи. Матеріал New Scientist описує нову кризу: мейнтейнери відкритого коду дедалі частіше отримують переконливо написані, але хибні баг-репорти, pull request-и й “вразливості”, які виглядають серйозно лише доти, доки людина не витратить час на перевірку.

Що відомо коротко

• Проблема стосується open source-проєктів, які підтримують інфраструктуру інтернету, мов програмування, бібліотек, фреймворків і застосунків.
• Низькоякісні ШІ-згенеровані внески називають AI slop — “ШІ-сміттям” або “ШІ-шлаком”.
• Найбільше навантаження створюють фальшиві звіти про вразливості, дублікати багів, поверхневі pull request-и та автоматично згенеровані пояснення без перевірки.
• Про проблему вже публічно говорили мейнтейнери curl, Python, Godot, Linux та інших великих проєктів.
• Ключовий висновок: ШІ знизив ціну створення заявок, але не знизив ціну їхньої перевірки — і саме це б’є по людях, які підтримують відкритий код.

Чому open source такий вразливий до ШІ-сміття

Open source працює на довірі. Людина знаходить баг, відкриває issue, пропонує виправлення або надсилає звіт про безпекову проблему. Мейнтейнер читає, перевіряє, відповідає, просить уточнення, тестує патч і вирішує, чи приймати зміни.

Ця система тримається не лише на коді, а й на людській увазі. І саме увага стала новою точкою атаки.

Раніше створити переконливий технічний звіт було складно. Треба було розуміти код, прочитати документацію, відтворити помилку, знайти правильний файл і пояснити проблему. Тепер достатньо попросити чатбота написати “security report” або “pull request description”, і результат часто виглядає професійно.

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

На Cikavosti вже писали, що до 30% коду Microsoft може генерувати штучний інтелект, і це показує масштаб трансформації. Але у великих компаніях є оплачувані команди рев’ю, тестування й безпеки. У open source часто є кілька волонтерів після роботи.

AI slop: чому це не просто “поганий код”

AI slop — це не обов’язково зловмисний код. Часто це щось гірше з погляду мейнтейнера: текст або патч, який достатньо правдоподібний, щоб його не можна було одразу викинути, але достатньо хибний, щоб він нікуди не вів.

Це може бути баг-репорт, де ШІ описує помилку в рядку, якого вже немає. Це може бути pull request, який “покращує” код, але ламає сумісність. Це може бути звіт про CVE, де модель бачить SQL-ін’єкцію там, де дані взагалі не йдуть у SQL.

Головна шкода тут — не один конкретний поганий патч. Головна шкода — вартість перевірки. Людина мусить прочитати, зрозуміти, знайти контекст, запустити тести, пояснити автору, що не так, і часто отримати у відповідь мовчання.

У дослідженні “An Endless Stream of AI Slop” автори проаналізували понад тисячу дописів із Reddit і Hacker News та описали три головні групи проблем: тертя під час рев’ю, деградацію якості й системні наслідки для спільнот розробників. Вони назвали це “трагедією спільного ресурсу”: одна людина економить час завдяки ШІ, але перекладає витрати на інших.

Як це виглядає на практиці: curl, Python, Linux і Godot

Один із найвідоміших прикладів — curl, інструмент і бібліотека, якими користуються мільйони серверів, застосунків і пристроїв. Його автор Даніель Стенберг ще у 2025 році описував хвилю AI slop у звітах про безпеку в дописі “Death by a thousand slops”, пояснюючи, що такі заявки виснажують команду, бо кожну потенційну вразливість треба перевіряти серйозно.

Згодом curl закрив свою bug bounty-програму. За даними The Register, рішення було пов’язане з тим, що команда витрачала надто багато часу на низькоякісні або ШІ-згенеровані звіти, а частка реальних вразливостей була дуже малою.

Схожа історія сталася навколо Python-екосистеми. Розробник безпеки Seth Larson у дописі “New era of slop security reports” описав, як LLM-згенеровані звіти створюють новий тип навантаження: вони виглядають достатньо технічними, щоб не ігнорувати їх одразу, але часто є галюцинаціями.

Навіть Linux не уникнув проблеми. У травні 2026 року кілька медіа повідомили, що Лінус Торвальдс критикував хвилю дубльованих AI-звітів про вразливості, які зробили приватний security-процес майже некерованим. Тут показовий не лише сам ШІ, а масштаб: коли інструмент робить пошук багів дешевим, багато людей одночасно надсилають однакові або поверхневі результати.

Open source-движок Godot теж зіткнувся з навалою ШІ-згенерованих pull request-ів. За описом PC Gamer, мейнтейнери витрачають час не лише на перевірку коду, а й на з’ясування, чи автор узагалі розуміє власні зміни.

Чому ШІ створює “DDoS людської уваги”

Класична DDoS-атака перевантажує сервер запитами. AI slop перевантажує людей заявками. Сервер можна масштабувати, додати кеш або фільтри. Людську експертизу масштабувати набагато складніше.

Мейнтейнер не може просто “відповісти автоматично” на звіт про вразливість. Якщо він помилиться й відкине реальну проблему, користувачі можуть постраждати. Якщо він перевірятиме все вручну, вигорить. Якщо він закриє доступ для новачків, open source втратить одну зі своїх головних переваг.

Це і є пастка. Open source історично був відкритим для випадкових учасників. Людина могла прийти, виправити дрібну помилку, навчитися, поступово стати частиною спільноти. Але коли потік випадкових внесків заповнюється ШІ-сміттям, мейнтейнери починають підозрювати всіх нових учасників.

Так руйнується найважливіша валюта open source — довіра.

На Cikavosti вже розповідали про витік коду Claude Code, і цей випадок добре показує інший бік тієї ж епохи: ШІ-інструменти для програмування стають складними інфраструктурними системами, але людські процеси контролю, пакування, рев’ю й відповідальності не завжди встигають за ними.

Чому це небезпечно для кібербезпеки

На перший погляд може здатися: більше звітів про вразливості — це добре. Якщо ШІ допомагає знаходити баги, треба просто прийняти нову реальність і радіти. Але кібербезпека не працює за принципом “що більше повідомлень, то краще”.

Добрий звіт про вразливість має містити відтворюваний сценарій, зрозумілий вплив, межі проблеми й часто — патч або хоча б точний технічний аналіз. Поганий звіт створює шум, але не додає знань.

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

OpenSSF уже обговорює цю проблему в межах робочої групи з vulnerability disclosures, де AI slop описують як хвилю низькоякісних ШІ-згенерованих звітів і внесків, які потребують нових практик фільтрації, відповідальності та комунікації.

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

Механізм кризи: хто економить час, а хто платить

Найважливіший механізм тут економічний. Генеративний ШІ різко знизив вартість створення тексту й коду. Але він майже не знизив вартість відповідального прийняття рішення.

Написати “ось вразливість” тепер можна за хвилину. Перевірити, чи це правда, може зайняти годину. Згенерувати pull request можна за кілька секунд. Переконатися, що він не ламає архітектуру, API, продуктивність і безпеку, може зайняти вечір.

Тому ШІ створює асиметрію. Автор заявки витрачає мало часу, а мейнтейнер — багато. Якщо автор помилився, він майже нічого не втрачає. Якщо мейнтейнер помилився, втрачають користувачі, репутація й безпека проєкту.

Саме тому багато мейнтейнерів починають говорити не про “допомогу ШІ”, а про екстерналізацію витрат. Людина використовує інструмент для власної продуктивності, але реальні витрати перекладає на спільноту.

Чому заборонити ШІ не так просто

Деякі проєкти вже вводять суворі правила. Мова Zig, за повідомленнями медіа, заборонила AI-generated contributions, а частина проєктів вимагає розкривати використання ШІ. Інші не забороняють інструменти, але вимагають тестів, відтворення, пояснення та особистої відповідальності автора.

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

Тому реалістичніше не питати “чи використовувався ШІ?”, а питати: “Чи автор розуміє зміну? Чи є тест? Чи є мінімальний відтворюваний приклад? Чи пояснено вплив? Чи не є це дублікатом?”.

На Cikavosti вже писали, що Microsoft створила CoreAI для розвитку ШІ-рішень, і це добре показує загальний напрям індустрії: ШІ стає частиною розробки. Але open source тепер мусить вирішити, як приймати користь ШІ без руйнування людського рев’ю.

Що можуть зробити платформи на кшталт GitHub

GitHub, GitLab та інші платформи для розробки опинилися в центрі проблеми. Вони отримують вигоду від автоматизації, Copilot, агентів і швидшої генерації коду, але витрати часто падають на мейнтейнерів.

Можливі рішення вже обговорюють у спільнотах. Наприклад, проєкти можуть отримати право жорсткіше обмежувати нові pull request-и, вимагати обов’язкових шаблонів, блокувати масові заявки, ставити фільтри на дублікати або позначати AI-assisted внески.

Але фільтри не повинні знищити нормальних новачків. Це тонка межа. Open source потребує нових людей, і занадто суворий режим може перетворити відкриті проєкти на закриті клуби.

Найкраща система, ймовірно, буде багаторівневою: автоматична перевірка дублікатів, обов’язкові тести, репутаційні сигнали, прозоре розкриття використання ШІ, жорсткі правила для security-звітів і можливість мейнтейнера швидко закривати заявки, які не містять перевірюваної інформації.

Цікаві факти

• Open source-проєкти часто підтримують критичні частини інтернету, але багато з них мають дуже маленькі команди мейнтейнерів.
• AI slop може бути небезпечним не тому, що завжди містить шкідливий код, а тому, що забирає час на перевірку.
• Звіти про безпеку складніше фільтрувати, ніж звичайні issue, бо реальну вразливість не можна легковажно відкинути.
• Деякі проєкти вже обговорюють обов’язкове розкриття використання ШІ в pull request-ах.
• Автоматизовані інструменти можуть і створювати проблему, і допомагати її вирішувати — наприклад, знаходити дублікати або перевіряти шаблони заявок.
• Головний дефіцит open source сьогодні — не код, а час досвідчених людей, які можуть оцінити його якість.

Що це означає

Практичне значення цієї кризи в тому, що open source має переосмислити свої правила входу. Епоха, коли кожен issue вважався потенційно добросовісною людською спробою допомогти, закінчується. Тепер частина заявок може бути автоматично згенерованою, неперевіреною й масовою.

Для розробників це означає нову етику використання ШІ. Якщо ви створюєте pull request за допомогою моделі, ви все одно відповідаєте за код. Якщо надсилаєте звіт про вразливість, ви маєте перевірити його самі. Якщо не можете пояснити патч без чатбота, він, імовірно, ще не готовий.

Для платформ це сигнал, що інструменти продуктивності мають супроводжуватися інструментами захисту мейнтейнерів. Не можна лише спрощувати створення заявок; треба також спрощувати їхню якісну фільтрацію.

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

FAQ

Що таке AI slop у програмуванні?

AI slop — це низькоякісний ШІ-згенерований код, баг-репорт, pull request, документація або security-звіт, який виглядає переконливо, але містить помилки, вигадки або неперевірені припущення.

Чому мейнтейнери не можуть просто ігнорувати такі заявки?

Бо частина з них може стосуватися безпеки або реальних багів. Щоб відрізнити справжній сигнал від шуму, потрібен людський аналіз, а він забирає час і сили.

Чи означає це, що ШІ не можна використовувати для open source?

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

Як правильно надсилати AI-assisted pull request?

Потрібно чітко пояснити проблему, показати мінімальний приклад, додати тести, перевірити зміни локально й бути готовим відповідати на технічні запитання без перекладання відповідальності на модель.

Висновок

Найдивніше в цій історії те, що ШІ не обов’язково ламає open source поганим кодом. Він може ламати його переконливим шумом.

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

Потік «сміття» у сфері штучного інтелекту доводить розробників відкритого програмного забезпечення до межі з’явилася спочатку на Цікавості.

cikavosti.com