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 ставится в конец дорогого фильтра как самый ценный ресурс.

↗