Сообщество ядра Linux решило отказаться от обязательной отметки Assisted-by, которой авторы патчей должны были сообщать об использовании продвинутых инструментов разработки. Для тех, кто применяет ИИ в Linux-проектах, сигнал предельно практичный: проверять будут не происхождение строчек кода, а способность автора объяснить и поддерживать свой вклад.
Решение принял Maintainers Summit — встреча мейнтейнеров ядра. О консенсусе сообщил разработчик Linux и инженер Nvidia Саша Левин; документацию с требованием использовать тег поручено удалить, сообщает The Register. Формально правило просуществовало недолго: обсуждать его начали в июле 2025 года, а в документации ядра оно появилось в январе 2026-го.
Тег Assisted-by предлагал указывать в сообщении коммита, что при подготовке патча применялся «любой продвинутый инструмент программирования». Идея выглядела понятной: код от языковой модели несёт риск незамеченных ошибок, а мейнтейнеры должны знать, с чем имеют дело. Но на практике маркировка не отвечала на главный вопрос ревью: корректен ли патч, понимает ли его автор и сможет ли исправить проблему после попадания изменений в ядро.
Линус Торвальдс в дискуссии резко возразил против правил, запрещающих или стигматизирующих использование ИИ. Он сравнил их с требованием писать патчи на ассемблере вместо компилятора или набирать сообщения коммитов без редактора: наличие инструмента само по себе не доказывает ни компетентность разработчика, ни её отсутствие. Его критерий проще и жёстче: участник должен делать работу добросовестно и понимать, что именно отправляет на ревью.
От учёта инструмента — к ответственности за результат
Отмена тега не означает, что Linux объявил генеративный код безопасным по умолчанию. Ядро остаётся проектом с многоступенчатым ревью, тестированием и персональной ответственностью автора подписи в цепочке коммитов. Ошибочный патч, созданный вручную, с помощью автодополнения или агентом, одинаково может сломать драйвер, подсистему памяти либо сетевой стек. Источник проблемы важен для расследования, но не заменяет технической проверки до принятия изменений.
У сторонников раскрытия использования ИИ остаются аргументы. Разработчик ядра и основатель Ideas on Board Лоран Пиншар предупреждал: без какого-либо механизма авторы могут начать сопротивляться прямым вопросам о том, как был подготовлен код. По его мнению, даже правило, которое невозможно обеспечить в каждом случае, задаёт ожидания сообщества. Нарушителей и раньше приходилось отсекать на ревью; наличие нарушений ещё не делает норму бессмысленной.
Противники обязательной маркировки указывают на другую сторону. Разработчик Red Hat Джефф Лейтон отмечал, что ей следуют не все, непонятно, зачем сообществу собирать эти сведения, а сам тег превращается в бесплатное продвижение закрытых поставщиков LLM. Это не только вопрос идеологии. Если разработчик использовал модель для поиска по кодовой базе, генерации теста, объяснения старого участка C-кода или черновика патча, граница между «использовал ИИ» и «не использовал» быстро становится произвольной.
Почему это важно за пределами ядра
Спор в Linux хорошо отражает зрелую фазу внедрения кодовых ассистентов. В августе ветеран сопровождения ядра Грег Кроа-Хартман говорил на Open Source Summit в Южной Корее, что LLM уже достаточно полезны для поиска ошибок: код во многом состоит из повторяющихся структур, которые модели умеют распознавать. При этом у разработчиков не исчезли опасения насчёт галлюцинаций, уязвимостей, лицензионной чистоты и патчей, которые выглядят убедительно, но не учитывают контекст подсистемы.
Для российских команд вывод не сводится к формуле «можно пользоваться ИИ». Полезнее отделить внутренний контроль качества от символических деклараций. В продуктовой разработке стоит требовать от автора изменений понятного описания решения, тестов, результатов статического анализа и готовности разбирать патч на ревью. Для критичного кода — дополнительно фиксировать, какие проверки прошли изменения и кто за них отвечает. Запретить модели легко; сложнее построить процесс, в котором сгенерированный фрагмент не проходит в продакшен только потому, что выглядит правдоподобно.
Вопрос теперь не в том, появится ли ИИ в Linux-цепочке разработки — он уже там, как и компиляторы, IDE и анализаторы. Гораздо важнее, смогут ли проекты сохранить прозрачность ответственности, не превращая историю коммитов в анкету об используемых инструментах. Ядро Linux выбрало проверку знаний и качества кода вместо обязательного признания; другим open source-проектам ещё предстоит решить, достаточно ли им такого баланса.