AI пише патчі швидше, ніж їх можуть перевірити: Linux зіткнувся з новою кризою open source

Linux зіткнувся не з дефіцитом багів, а з дефіцитом людської уваги

Коли AI почав знаходити помилки у великих codebases, це виглядало як очевидна перемога: більше перевірок, швидше виявлення вразливостей, менше шансів, що старий небезпечний код роками залишатиметься непоміченим. У 2026 році ця логіка вперлася в нове обмеження. Модель може створити звіт або patch за хвилини, але людина все одно повинна довести, що проблема реальна, виправлення коректне і не створює regression.

Особливо яскраво це видно в Linux kernel. У networking pull request мейнтейнер Якуб Кіцінскі навів 632 патчі для net і 648 для net-next. За його оцінкою, приблизно від третини до половини net-next потоку виглядали як AI-driven low-priority fixes, cleanup та clarifications. Далі прозвучало формулювання, яке й стало суттю історії: команда “completely overwhelmed”.

Це не означає, що AI знайшов 2000 багів Linux. Загальна кількість CVE на реліз у вторинних оцінках справді наближається до такого рівня, але CVE походять із різних джерел і мають різну важливість. Коректніша історія цікавіша: автоматизований discovery та generation масштабуються швидше, ніж open-source спільнота може масштабувати review.

Чому Linux ідеально підходить для AI bug hunting

Ядро Linux — це десятки мільйонів рядків C-коду, тисячі драйверів, архітектур, мережевих протоколів і підсистем, частина яких живе десятиліттями. Тут багато “рідкісних шляхів”: PCIe error handling, таймаути, recovery після hardware failure, race conditions, старі драйвери та код, який мейнтейнер може роками не бачити в реальній експлуатації.

Для людини перевіряти все це вручну економічно майже неможливо. Для LLM, static analyzer або fuzzing pipeline пройти тисячі файлів — нормальна автоматизована задача. Кіцінскі окремо звернув увагу, що APIs для рідкісних events історично могли бути racy саме тому, що майже не потрапляли в “гарячий” шлях розробки. LLM змушують дивитися туди, куди раніше просто не вистачало часу.

Але дешеве сканування не робить дешевою перевірку. Report може містити правильні назви функцій, переконливе пояснення і готовий diff — і все одно описувати path, який неможливий у реальному control flow, або виправляти косметичну неточність ціною нового regression.

Новий bottleneck — verification, а не discovery

У традиційному security research дорогим був пошук: дослідник витрачав години або дні, щоб знайти execution path, відтворити crash, побудувати proof of concept і підготувати fix. AI змінює співвідношення. Вартість кандидата на проблему падає швидше, ніж вартість надійної верифікації.

OpenAI у Patch the Planet прямо формулює цю проблему: discovery itself does not protect users. Якщо мейнтейнер отримує сотні сирих findings, а значна частина — false positive, низький пріоритет або hallucination, результатом може стати не безпечніший проєкт, а довша черга.

Тому в Patch the Planet findings проходять ручну експертну перевірку до передачі maintainer. Це правильний дизайн: AI не повинен безкоштовно перекладати свою невизначеність на людей, які підтримують open source.

Парадокс: Linux уже використовує AI, щоб захищатися від AI-потоку

У тому ж повідомленні networking maintainers сказано, що вони отримали достатній LLM budget та доступ до кількох frontier models для review вхідних змін. Це допомагає відсіювати частину hallucinations і очевидних проблем, хоча моделі “can only do so much”.

Виникає новий pipeline: одна модель знаходить підозрілий код, друга генерує patch, третя аналізує diff, а людина приймає фінальне рішення. Це вже не проста історія “AI пише код замість програміста”. Людина стає арбітром між агентами, які виробляють дедалі більше взаємно суперечливих сигналів.

Чому число CVE саме по собі може обманювати

Велике число CVE легко подати як доказ, що Linux став небезпечнішим. Але CVE count вимірює не тільки якість коду. Він відображає інтенсивність пошуку, coverage, disclosure policy, здатність знаходити edge cases і те, які дефекти отримують ідентифікатор.

Якщо AI різко збільшує coverage, кількість зафіксованих проблем може зрости навіть без зростання фактичного ризику. Тому важливіші severity, exploitable path, affected versions, time-to-triage, time-to-fix і частка accepted upstream patches. Офіційна Linux security documentation теж підкреслює точне визначення affected versions та повний disclosure/fix process.

Daybreak показує різницю між “знайти” і “виправити”

На публічній сторінці OpenAI Daybreak вказані 41 codebase, 858 identified issues, 263 produced patches і 143 patches accepted upstream. Саме ця різниця між 858 і 143 є важливішою за красиве число findings.

Між “знайшли” та “прийняли upstream” лежить reproduction, severity assessment, tests, compatibility, project style, feedback maintainer та повторні версії patch. AI може прискорити кожен етап, але не може просто скасувати вимогу correctness.

Найгірший сценарій — виснаження мейнтейнерів

False positive можна закрити. Значно складніше повернути час і концентрацію ключового maintainer. Open-source інфраструктура тримається на невеликій кількості людей, які знають контекст підсистеми краще за будь-яку модель. Якщо тисячі зовні “якісних” AI-патчів змушують їх витрачати день на triage замість architecture, regression fixes і складних bugs, система програє навіть без злого наміру.

Наступна хвиля tooling повинна оптимізувати не findings/day, а signal-to-human-minute: скільки підтвердженої корисної інформації отримує експерт на хвилину уваги.

Яким має бути контракт AI-generated patch

Для великих open-source проєктів логічно вимагати не тільки diff, а evidence: reproduction, порушений invariant, affected-version range, tests до/після, пояснення side effects і доказ, що patch не розширює attack surface. Далі — machine triage: дедуплікація, clustering схожих reports, cross-model review і rate limits для джерел із високою часткою слабких findings.

Це нагадує spam-фільтрацію. Email зробив надсилання повідомлень майже безкоштовним — довелося захищати увагу одержувача. AI робить майже безкоштовним “інженерно правдоподібний patch”. Тепер software ecosystem потребує свого антиспаму.

Що це означає для програмістів

Історія Linux не показує, що senior engineer стає непотрібним. Навпаки, дефіцитом стає висококваліфікований judgment. Модель може запропонувати сто варіантів, але хтось має розуміти lifetime об'єкта, concurrency, ABI, hardware quirks, release process та соціальний контракт проєкту.

Роль інженера зміщується від виробництва кожного рядка до побудови правил: invariants, tests, review gates, observability, permissions і rollback. Чим більше коду генерує AI, тим дорожчою стає людина, здатна сказати: “цей patch правильний не тому, що виглядає правдоподібно, а тому що ми це довели”.

Висновок RankPoint

Linux не переживає “катастрофу з 2000 AI-багів”. Він показує ранню версію проблеми, яка прийде в усі великі codebases: машини навчилися виробляти security work швидше, ніж організації навчилися його перевіряти.

Це хороший тип проблеми — краще знати про слабкі місця, ніж залишати їх прихованими. Але без evidence-first triage, автоматизованого review та захисту людської уваги користь легко перетворюється на перевантаження. Наступний прорив в AI coding може бути не в генерації ще більшої кількості коду, а в надійному доказі того, який код вартий людського часу.

Масштаб уже не лабораторний: 30 мільйонів commits і 30 тисяч codebases

Щоб зрозуміти, чому Linux-історія не є локальною дивиною однієї mailing list, варто подивитися на масштаб, який уже бачить OpenAI у Codex Security. З моменту research preview система, за даними OpenAI, просканувала понад 30 мільйонів commits у більш ніж 30 000 codebases. Людські reviewers вручну позначили понад 70 000 findings як виправлені, ще понад 500 000 система автоматично визначила як fixed.

Ці числа не можна читати як “пів мільйона нових уразливостей”. Вони описують величезний operational funnel — findings, status checks, remediation tracking та повторну перевірку. Але саме funnel показує нову фізику software security: автоматизоване сканування вже працює в масштабі, де ручна модель triage перестає бути основною.

OpenAI формулює це майже тим самим словником, що й Linux maintainers: bottleneck змістився від finding до patching. Тобто незалежно від конкретного vendor ми бачимо одну й ту саму системну проблему.

Open source особливо вразливий до “успішного” AI

На сторінці Daybreak OpenAI наводить оцінку, що open source лежить в основі приблизно 70–90% сучасного software. При цьому компанія посилається на дослідження Linux Foundation і Harvard: у 94% широко використовуваних проєктів із вибірки менше десяти developers відповідали за понад 90% коду, доданого протягом року.

Це змінює інтерпретацію слова “масштаб”. Для AI мільйон рядків — додатковий compute. Для open-source maintainer сто добре оформлених reports — це сто interruption points. Якщо кожен потребує навіть 20 хвилин, “безкоштовна” допомога AI створює десятки годин людської роботи.

Саме тому правильний defensive workflow має містити buffer між model і maintainer: deduplication, reproduction, severity calibration, test generation, patch validation і тільки потім submission. Не “AI знайшов — негайно відкриваємо issue”, а “AI знайшов — система довела, що це варте людської уваги”.

Фільтр має оцінювати не красу звіту, а доказ

LLM особливо небезпечна для review queue тим, що вміє створювати якісний вигляд інженерної роботи. Красивий technical write-up, правильні function names і впевнений severity label психологічно схиляють reviewer повірити finding ще до reproduction.

Тому RankPoint пропонує простий evidence score для AI security report: reachable path; мінімальний testcase; deterministic reproduction; affected-version proof; regression test; patch verification; independent second-pass review. Чим менше цих пунктів, тим нижче finding має стояти в людській черзі — незалежно від того, наскільки переконливо написаний текст.

Коли AI-патчів стане в десять разів більше, governance стане частиною compiler pipeline

Сьогодні contribution policy часто описує стиль commit message, Signed-off-by і tests. У майбутньому великі проєкти, ймовірно, додадуть machine-origin metadata, provenance model/tool, reproducibility bundle та автоматичний trust score. Це не дискримінація AI-коду — це спосіб зробити його reviewable.

Можливий pipeline виглядатиме так: generator → static checks → second-model critic → fuzz/reproduction → regression suite → duplicate search → risk score → human maintainer. Людина не зникає з процесу; навпаки, її attention ставиться в кінець дорогого фільтра як найцінніший ресурс.

↗