Разработчик ядра Linux Лоренцо Стоукс, отвечающий сразу за четыре направления в подсистеме управления памятью, решил сократить объём стороннего code review. Причина — поток изменений, среди которых всё заметнее AI-патчи для Linux: по словам инженера, они уже составляют примерно половину присылаемых ему работ. Для компаний, завязанных на Linux и open source, это неприятный сигнал: генерация кода удешевляет отправку патчей, но не проверку их качества.
Стоукс работает principal software engineer в Arm и сохраняет все свои обязанности мейнтейнера. Он не уходит из разработки ядра и не передаёт поддерживаемые разделы другим людям. Однако проверять изменения за пределами собственных зон ответственности он больше в общем случае не готов. Об этом он написал в рассылке Linux kernel, объяснив решение нехваткой времени на фоне текущего темпа поступления серий патчей, сгенерированных ИИ. Как сообщает The Register, инженер хочет прежде всего сделать управляемым собственный почтовый ящик.
Нагрузка у Стоукса и без того не символическая. В его ведении находятся memory mapping, блокировки в этой области, интерфейсы madvise и reverse mapping — связка, которая покрывает значительную часть пользовательского API управления памятью и механизмов сопоставления виртуальной и физической памяти. Параллельно он пишет книгу The Linux Memory Manager. Когда такой мейнтейнер сужает круг рецензируемых изменений, проблема не в одной перегруженной inbox-папке: в сообществе становится меньше опытных глаз для проверки кода, который может затронуть миллионы серверов, устройств и контейнерных платформ.
Стоукс описал динамику без особой дипломатии. Сначала материалы, явно подготовленные с помощью ИИ, появлялись примерно раз в неделю, затем — ежедневно, а теперь занимают около половины того, что он видит в review. Волна затрагивает не какую-то одну подсистему, а разработку Linux в целом, включая управление памятью. Генеративная модель может быстро предложить исправление, написать описание серии и оформить патч в привычном для рассылки виде. Но правдоподобный diff ещё не означает, что автор разобрался в блокировках, обратной совместимости, редких гонках или последствиях изменения для архитектур, которых у него нет под рукой.
В ядре Linux проверка — не формальность перед нажатием кнопки merge. Рецензент должен понять контекст изменения, сверить его с соседним кодом, заметить неверные предположения и оценить побочные эффекты. Чем больше «почти правильных» патчей приходит в рассылку, тем больше времени уходит не на улучшение ядра, а на отсеивание шума. Именно здесь AI-патчи для Linux меняют экономику open source: стоимость подготовки очередного предложения падает для отправителя, а цена экспертизы остаётся высокой для мейнтейнера.
Это не первый публичный сигнал о перегреве. На Open Source Summit в прошлом месяце Грег Кроа-Хартман, один из ключевых разработчиков Linux, говорил о наплыве патчей, подготовленных LLM, и дефиците людей, способных их проверять. По его оценке, мейнтейнеры выгорают уже около десяти лет, а новых рецензентов всё равно не хватает. Кроа-Хартман также предложил сократить число одновременно поддерживаемых Long Term Support-веток: двух было бы достаточно, четыре — предел, тогда как шесть он назвал чрезмерной нагрузкой.
Отдельно он критиковал модель длительной поддержки, принятую у корпоративных дистрибутивов вроде Red Hat Enterprise Linux и SUSE Linux Enterprise. Десять лет сопровождения для продукта с конкретной версией ядра означают годы бэкпортов, тестирования и разбора регрессий. Если при этом upstream получает всё больше плохо проверенных предложений, поддержка старых веток не становится проще только потому, что код прислал бот или разработчик с помощником на базе LLM.
Для разработчиков вывод довольно приземлённый: ИИ стоит использовать как инструмент исследования и черновика, а не как фабрику писем в LKML. Перед отправкой патча автору всё равно придётся воспроизвести проблему, прогнать тесты, изучить историю участка кода и быть готовым отвечать на замечания. Компаниям, которые строят продукты на Linux, полезно вкладываться не только в автоматическую генерацию изменений, но и в людей, способных проводить качественный review, тестировать апстрим и сопровождать принятые исправления.
Мейнтейнеры пока не отказываются от работы — Стоукс прямо подчёркивает, что остаётся ответственным за свои подсистемы. Но AI-патчи для Linux уже превращаются из забавного побочного эффекта генеративного ИИ в операционный риск для критической инфраструктуры. Главный вопрос теперь не в том, сможет ли модель написать ещё один патч, а в том, найдётся ли у сообщества достаточно квалифицированных людей, чтобы отличить полезный вклад от убедительно оформленной ошибки.
