Linux kernel AI-generated code: правила для ИИ-кода

Linux kernel AI-generated code теперь описан не как запрет и не как безоговорочное разрешение. В официальной документации Linux появился отдельный документ AI Coding Assistants: ИИ-инструменты могут помогать при разработке ядра, но ответственность остаётся на человеке, а участие ассистента нужно раскрывать через отдельный след в истории патча.

По состоянию на 12 апреля 2026 года правило выглядит так: AI-агент не ставит Signed-off-by, потому что не может юридически подтвердить Developer Certificate of Origin. Человек проверяет код, следит за лицензией, добавляет свой Signed-off-by и берёт полную ответственность. Для ИИ-помощника предусмотрен другой маркер: Assisted-by.

Что именно изменилось в Linux kernel AI-generated code

Короткая версия: Linux kernel не говорит “ИИ-код запрещён”. Он говорит: если вы используете AI-assistance, вклад должен проходить обычный процесс разработки ядра. Это значит coding style, правила отправки патчей, совместимость с GPL-2.0-only и прозрачное происхождение изменений.

Отсюда важный сдвиг. Спор “можно ли пользоваться Copilot, Claude Code или другим ассистентом” уходит на второй план. Главный вопрос теперь другой: кто понимает патч, кто может его защищать на ревью и кто юридически подтверждает право отправить этот код в ядро.

Для open-source это более взрослая позиция, чем простой запрет. Запрет легко написать, но сложно проверять. Правило прозрачности проще встроить в процесс: мейнтейнер видит, где участвовал инструмент, и может решить, нужен ли дополнительный разбор, тесты или отказ без длинной дискуссии о природе ИИ.

Почему AI-агент не может ставить Signed-off-by

Signed-off-by в Linux — не декоративная подпись. Это связка с Developer Certificate of Origin, то есть с утверждением, что участник имеет право отправить вклад под соответствующей open-source лицензией. В DCO 1.1 автор вклада подтверждает, что вклад создан им, основан на совместимо лицензированной работе или получен от человека, который тоже мог его подтвердить.

ИИ-инструмент не может взять на себя такую ответственность. Он не владеет правами, не понимает контекст лицензии как юридический субъект и не будет отвечать на комментарии мейнтейнера через месяц. Поэтому документация Linux формулирует жёстко: Signed-off-by добавляют люди.

Это не формальность. Если AI-сервис сгенерировал функцию из неизвестного обучающего корпуса, проблема не исчезает от того, что код компилируется. Человек должен проверить происхождение, лицензию, поведение и поддержку. Если он этого не сделал, вина не переезжает на модель.

Зачем нужен Assisted-by

Assisted-by нужен не для рекламы модели. Это audit trail: дополнительная строка в истории патча, которая показывает участие AI-инструмента. Формат из документации Linux такой:

Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]

В строке указывают имя инструмента или фреймворка, версию модели и, если нужно, специализированные средства анализа. Документация прямо уточняет: обычные инструменты вроде git, gcc, make и редакторов перечислять не нужно. Смысл не в том, чтобы превращать каждый коммит в отчёт о рабочем месте разработчика. Смысл в том, чтобы заметить существенную помощь ИИ или анализа.

Практически это защищает обе стороны. Мейнтейнер не должен гадать, почему патч выглядит как результат генератора. Автор не должен скрывать инструмент и надеяться, что никто не заметит. Если модель помогла, это можно указать. Но подпись и ответственность всё равно остаются человеческими.

Чем Assisted-by отличается от Signed-off-by и Co-developed-by

Чтобы не путать новые правила с уже знакомыми тегами Linux, полезно разложить их в таблицу. Здесь нет “ИИ-авторства” в юридическом смысле: есть человеческая подпись, человеческое соавторство и отдельная отметка о помощи инструмента.

Эта таблица хорошо показывает, чего Linux не делает. Он не превращает AI в соавтора. Он не принимает фразу “модель написала” как юридическую защиту. Он просто добавляет прозрачный маркер к уже существующей культуре patch review.

Связь с правилами для tool-generated content

Документ про AI Coding Assistants не висит в вакууме. В соседней документации Kernel Guidelines for Tool-Generated Content уже описана более широкая логика: участники ядра давно используют инструменты, но время ревьюеров и мейнтейнеров остаётся ограниченным ресурсом.

Там же проведена полезная граница. Не всякая автоподстановка или форматирование требует отдельного отчёта. Но если значимая часть вклада не была написана человеком из цепочки Signed-off-by, происхождение стоит раскрыть. В примерах прямо есть чатбот, который сгенерировал новую функцию, и описание изменений, написанное генеративным инструментом.

Вывод для AI-generated code простой: чем больше вклада сделал инструмент, тем больше прозрачности ожидают мейнтейнеры. Если автор не понимает сгенерированный код и не может его защищать, документация допускает отказ без подробного ревью. Это жёстко, но честно: у ядра Linux нет лишнего времени на патчи, за которые никто реально не отвечает.

Почему это важно не только для Linux

Linux kernel здесь интересен как ранний пример политики, которую будут копировать другие open-source проекты. Не дословно, но по принципу. Вместо эмоционального “AI slop запрещён” появляется рабочая модель: разрешаем помощь, требуем раскрытия, не снимаем ответственность с человека.

Это связано с более широким сдвигом в разработке. GitHub Copilot, Claude Code, Cursor и локальные модели уже стали частью рабочих процессов. Мы отдельно разбирали, как Copilot меняет правила работы с кодом и обучающими данными. Но вопрос происхождения кода не решается кнопкой в IDE. Его приходится фиксировать в правилах проекта.

Похожая проблема есть и в агентной разработке. Если ИИ-агент быстро создаёт изменения, он так же быстро может накопить ошибки, которые человек заметит позже. Об этом мы писали в материале про то, как ИИ-агенты копят ошибки быстрее, чем разработчик успевает их заметить. Linux отвечает на тот же риск своим языком: покажи происхождение, подпиши ответственность, будь готов объяснить каждую строку.

Что стоит сделать разработчикам и мейнтейнерам

Если вы ведёте open-source проект, политика Linux даёт неплохой минимум. Она не пытается определить, “настоящий” ли код написал человек. Она задаёт проверяемые вопросы.

• Кто подписывает вклад и подтверждает DCO или аналогичное правило проекта?
• Какая часть работы была сделана AI-инструментом?
• Нужно ли указывать модель, агент или дополнительные анализаторы?
• Должны ли промпты или краткое описание сессии попадать в сопроводительное письмо?
• Когда мейнтейнер может потребовать дополнительное тестирование или отклонить патч без длинного ревью?

Для компаний это тоже не отвлечённая история. Если команда принимает код от подрядчиков, внутренних AI-агентов или “быстрых” pull request’ов, ей нужен свой вариант Assisted-by. Не обязательно именно такой тег. Нужен след: кто использовал инструмент, что он сделал, кто проверил результат и кто отвечает за поддержку.

Сравнение с App Store тоже показательно. В материале про Apple и вайб-кодинг мы разбирали другой тип фильтра: платформа не хочет пропускать приложения, которые после ревью могут стать чем-то иным. Linux решает похожую задачу на уровне исходного кода: не запрещает инструменты, но требует понятного происхождения изменений.

Итог

Linux kernel AI-generated code теперь лучше описывать не как “ИИ пустили в ядро”, а как “ядро формализовало правила для ИИ-помощи”. Разница принципиальная. AI-инструмент может помочь, но не может подписать DCO, не может взять юридическую ответственность и не может заменить понимание кода человеком.

Это, вероятно, и есть направление для зрелой разработки с ИИ в 2026 году. Меньше лозунгов про запреты или революцию, больше журналов, тегов, тестов и человеческой подписи. Скучно? Да. Но именно так open-source проекты переживают моду и превращают её в процесс.

Читайте также

• GitHub Copilot начнёт обучаться на вашем коде: что меняется и как отказаться
• Создатель libGDX: ИИ-агенты копят ошибки быстрее, чем вы их замечаете
• Apple против вайб-кодинга: App Store как фильтр AI-приложений