Линус Торвальдс тридцать пять лет был главным консерватором Linux: ядро принимает изменения медленно, каждую строку смотрит человек, никакой магии. В октябре 2026-го этот образ треснул окончательно. Торвальдс опубликовал в списке рассылки LKML ветку с ускорением чтений из page cache, и первое, что бросается в глаза в его письме, это признание: код, тесты, ревью и черновик самого письма написал Claude Code под его руководством.

Это не утечка и не слух. Создатель Linux сам и без всякого стеснения применил вайб-кодинг к одному из самых чувствительных участков ядра. А статистика вокруг говорит, что происходит не разовый эксперимент, а смена нормы: LLM-патчи в ядре Linux уже несколько месяцев бьют рекорды.

Что именно сделал Торвальдс

Page cache это кэш страниц, через который проходит почти любой файловый ввод-вывод в системе. Каждый раз, когда процесс читает файл, ядро сначала смотрит в этот кэш. От скорости такой операции зависит ощущаемая производительность всего: сборки, базы данных, компиляторы, браузеры. Ускорять чтения из page cache это как раз тот случай, когда даже небольшой выигрыш даёт эффект на всю систему.

В новой ветке Торвальдса чтения стали заметно быстрее, во всяком случае по первым бенчмаркам. Но ещё интереснее побочный результат: по ходу работы ИИ-ассистент нашёл несколько настоящих багов и починил их. То есть ускорение и стабильность ядра пришли не вопреки вайб-кодингу, а благодаря ему.

Вот фрагмент из описания патча в переводе с английского: «Код, тестовые программы, ревью за списком изменений выше и первый черновик этого текста сделаны с LLM-ассистентом (Claude Code) под моим руководством».

В цитате важен акцент: под моим руководством. Торвальдс нигде не отдаёт ИИ авторство. Модель делает черновик, человек проверяет и отвечает за результат. Это принципиальная разница между рабочим вайб-кодингом и безответственностью, о которой так любят спорить мейнтейнеры.

Рекорд за рекордом: масштаб явления

LLM-патчи в ядре Linux это изменения, которые целиком или частично сгенерированы большими языковыми моделями и отправлены в основной репозиторий через обычный процесс ревью. По данным обзора The Lunduke Journal, каждый месяц 2026 года, кроме июля, число таких патчей ставило новый исторический рекорд. Июль рекорд не побил, но и провала не случилось: рост просто приостановился.

Речь идёт о тысячах патчей ежемесячно, и приходят они не только от новичков, а от контрибьюторов всех уровней, включая людей, которые пишут для ядра годами. В commit-нотах смешаны все основные инструменты эпохи: много Claude, много Codex, плюс другие модели и агенты. Это уже не про эксперименты одиночек: ИИ-код приходит в драйверы, файловые системы и подсистемы ядра, и приходит постоянно.

Курс задаёт не только Торвальдс. С весны 2026-го Linux Foundation открыто сделал ставку на ИИ-разработку вокруг Linux, а мейнтейнер стабильной ветки ядра Грег Кроа-Хартман давно и плотно использует ИИ-ассистентов в своей работе. Сам Торвальдс годами повторял, что ИИ для него просто ещё один инструмент, вроде компилятора. Теперь он доказал это делом: с помощью модели он генерирует не только код, но и commit-сообщения, и тексты писем в рассылку.

Второй лагерь: кому ИИ в коде не нужен

Пока ядро движется в одну сторону, заметная часть опенсорса бежит в противоположную. Дистрибутивы, десктоп-окружения и языки программирования один за другим вводят запреты на ИИ-вклады. Elementary OS запретила любые изменения, написанные с помощью LLM. GNOME и KDE обсуждают ограничения. В сообществе Python спор идёт не первый месяц. Некоторые дистрибутивы, по выражению Люндуке, балансируют на грани гражданской войны.

Самый громкий пример мы уже разбирали: язык Zig полностью запретил ИИ-код в контрибуциях. Требования у запретительного лагеря примерно одинаковые: если патч написан с помощью модели, его удаляют, а автора могут забанить.

Причины здесь серьёзные, и они не сводятся к страху перед технологиями. Мейнтейнеры устали от «слопа»: рассылки заваливают мусорные отчёты об ошибках и патчи, которые выглядят правдоподобно, а на деле не работают. Каждый такой случай съедает время живых ревьюеров, а ревью и так узкое место любого крупного проекта. Отдельная головная боль это авторство: кто отвечает за баг в сгенерированном коде, человек, который нажал «отправить», или разработчик модели? Плюс юридический слой: вопросы к лицензиям обучающих данных, патентные риски и требования DCO-подписей, которые подпись бота закрыть не может.

Парадокс: нельзя запретить ИИ и одновременно шипать Linux

Главное наблюдение Люндуке в том, что запретительный путь в Linux-мире внутренне противоречив. Дистрибутив может запретить ИИ-вклады в свои пакеты, но он всё равно собирается из ядра, которое, как показывают рекорды выше, всё больше пишется с помощью ИИ. Запрещать ИИ и поставлять современный Linux одновременно это позиция, которую невозможно удержать долго.

По его формулировке, «этот корабль уже уплыл». Единственный способ получить ядро совсем без ИИ-кода это откатиться примерно на год назад, форкнуть его и закрыть для новых патчей, а потом сидеть на этой версии. По-настоящему таких форков в экосистеме нет: пользователи хотят свежие ядра и работающее железо, а не идеологически чистую временную капсулу.

Почему спорят: аргументы обеих сторон

У стороны «за ИИ» сейчас самый весомый аргумент: результаты. Ветка Торвальдса быстрее, найденные баги починены, поддержка нового железа и десктопов растёт быстрее, чем когда-либо. Люндуке говорит, что большинство заметных улучшений в Linux-мире прямо сейчас (производительность, поддержка железа, новые фичи) приходит именно из проектов, которые приняли ИИ. В пример он приводит проект Omarchy: значительная часть свежей поддержки Apple Silicon, по его данным, сделана вайб-кодингом.

У стороны «против» аргумент про качество и системные издержки. Сгенерированный код легче написать, чем проверить, а ИИ-вкладчики увеличивают приток изменений кратно, не увеличивая число ревьюеров. Если к этому добавляются сомнения в юридической чистоте и в мотивации авторов (патч отправляют ради строчки в резюме, а не чтобы решить проблему), получается та самая токсичная смесь, из-за которой проекты и вводят баны.

Сам Люндуке признаёт, что у него смешанные чувства: ему не обязательно нравится то, что происходит, но он фиксирует факт. Направление движения Linux-мира уже определилось, и отрицать это бессмысленно.

Что дальше: как спор разрешится на практике

Главный вопрос в этом споре уже не «можно ли использовать ИИ», а «как учитывать и проверять ИИ-вклады». Механизмы только складываются: раскрытие факта использования модели, человеческое ревью результата и личная ответственность автора. Ядро пока идёт именно этим путём, и выглядит он устойчивее крайностей.

Скептики будут проверять аргумент «результаты» статистикой. Если приток ИИ-патчей растёт кратно, а доля регрессий и откатов не увеличивается, позиция запретов слабеет сама собой. Если качество начнёт проседать, политики ужесточат. Пока данные скорее в пользу ИИ: у Торвальдса ветка ускорилась, а найденные баги починил тот же ассистент.

Отдельная тема это безопасность. Ядро не рядовой проект: ошибка в page cache или сетевой подсистеме способна превратиться в уязвимость масштаба интернета. Поэтому даже энтузиасты ИИ в ядре настаивают на медленном человеческом ревью. Формулировка Торвальдса «под моим руководством» как раз об этом: не автопилот, а ускорение черновой работы под контролем человека.

Прогноз напрашивается сам: гибридная модель станет нормой, а чистые «да» и «нет» останутся маргиналиями. Полные запреты сохранятся в нишах с небольшим потоком вкладов, где легко вручную проверить каждый патч. Крупные проекты с тысячами изменений в месяц будут дрейфовать к модели ядра: разрешено с раскрытием.

Практический вывод для читателя простой. Если вы пользуетесь ИИ-ассистентом в работе над открытым кодом, раскрывайте это в описании изменений и не прячьте. Норма дрейфует в сторону прозрачности, и привычка «пишу руками» больше не главный критерий доверия к патчу.

Что это значит для разработчиков

Если вы контрибьютите в ядро или другой крупный проект, вопрос уже не в том, использовать ли ИИ, а в том, как об этом сообщать. Модель Торвальдса выглядит рабочей: модель делает черновик, человек ревьюит и берёт ответственность, факт использования ИИ фиксируется прямо в описании патча. Это снимает главный страх мейнтейнеров, скрытые ИИ-вклады, которые невозможно отревьюить по-человечески.

Если вы мейнтейнер, политику стоит определить заранее, не дожидаясь первых спорных патчей. Вариантов немного: полный запрет, как в Zig; разрешение с обязательной пометкой и ревью человеком, как в ядре; либо промежуточные схемы с лимитами на размер ИИ-вкладов и ограничениями на генерацию отчётов и документации.

Прогноз Люндуке: через три-шесть месяцев разница между проектами, которые приняли ИИ, и проектами, которые его запретили, станет заметна невооружённым глазом по скорости релизов и качеству. Часть запретительных проектов рискует остаться позади. Но и у принявших есть свои риски: внятного ответа на вопрос ответственности за сгенерированный код нет пока ни у кого, включая ядро.

Часто задаваемые вопросы

Правда ли, что Линус Торвальдс пишет код для ядра через ИИ?

Да. В октябре 2026 года он опубликовал в LKML ветку с ускорением чтений из page cache, где, по его собственному признанию, код, тесты, ревью и черновик описания сделал Claude Code под его руководством. Человек при этом сохраняет роль ревьюера и отвечает за результат.

Насколько выросло число LLM-патчей в ядре Linux?

По данным The Lunduke Journal, каждый месяц 2026 года, кроме июля, ставил новый рекорд по числу патчей, написанных ИИ. Суммарно это тысячи изменений в месяц от самых разных инструментов, в основном Claude и Codex.

Запретят ли ИИ-код в ядре Linux?

Маловероятно. Ключевые фигуры ядра, включая самого Торвальдса и мейнтейнера стабильной ветки, используют ИИ-ассистентов в ежедневной работе. Вместо запрета там выстраивают нормы: пометка об использовании ИИ, ревью человеком и личная ответственность автора за изменения.

Итог

LLM-патчи в ядре Linux вышли на рекордный уровень, а Торвальдс превратил вайб-кодинг из мема в рабочую практику мейнтейнера номер один. Опенсорс раскололся на два лагеря: одни запрещают ИИ и рискуют отстать, другие строят на нём весь свой прогресс и спорят о новых правилах ответственности. Спор решится не манифестами, а результатами ближайших месяцев.

Если у вас свой проект, посмотрите на две полярные политики, ядро Linux и Zig, и сформулируйте свою до того, как первый ИИ-патч постучится в ваш репозиторий.