На обсуждение представлены правила и ограничения для ИИ-ассистентов, применяемых при разработке компонентов ядра Linux

Разработчик Саша Левин (Sasha Levin), который занимается сопровождением LTS‑веток (с долгосрочной поддержкой) ядра Linux и входит в консультативный совет организации Linux Foundation, выставил на открытое обсуждение с сообществом набор правил и документацию, которые должны учитываться ИИ‑ассистентами при генерации изменений в коде ядра Linux, которые готовят и присылают мейнтейнеры после своих внутренних проверок.

Предложение от Саши Левин не меняет процесс разработки Linux в одночасье. Пока это всего лишь запрос комментариев (RFC). Но оно поднимает более важный вопрос: какое количество ИИ считается чрезмерным, когда речь идёт об открытом исходном коде, работающем на миллиардах устройств?

Ссылки на инструкции по этому обсуждению отмечены в файлах конфигурации подготовлены для ИИ‑платформ Claude, GitHub Copilot, Cursor, Codeium, Continue, Windsurf и Aider.

По информации OpenNET, определены следующие ключевые принципы для AI:

• перед созданием изменений необходимо прочитать документацию и следовать изложенным в ней требованиям;

• следует выполнять требования по стилю и оформлению кода для ядра;

• перед отправкой изменения его нужно тщательно протестировать;

• к коду нужно приложить понятное и исчерпывающее сообщение с описанием изменения;

• изменения не должны нарушать работу компонентов в пространстве пользователя;

• в качестве соавтора изменения должен быть отмечен ИИ, не ограничиваясь только упоминанием разработчика, использовавшего ИИ‑ассистент.

Для выделения изменений, подготовленных с использованием ИИ, разработчикам к коммиту предписывается прикреплять тег «Co‑developed‑by: $AI_NAME $AI_MODEL $AI_VERSION». Например: «Co‑developed‑by: Claude claude-3-opus-20 240 229», «Co‑developed‑by: GitHub‑Copilot GPT-4 v1.0.0» и «Co‑developed‑by: Cursor gpt-4-turbo-2024–04–09». При этом ИИ‑ассистент не должен добавлять себя в тег «Signed‑off‑by». Данный тег должен добавляться только человеком для юридически значимого подтверждения права на передачу кода под открытой лицензией.

Документация, которую должен учитывать ИИ-ассистент:

• Руководство, как стать разработчиком ядра.

• Информация о процессе разработки ядра.

• Руководство по передаче своего кода в ядро.

• Чек-лист проверок перед отправкой кода в ядро.

• Требования к стилю и оформлению кода (использование табуляции для выравнивания, не больше 80 символов в строке, отдельные правила форматирования функций и условных выражений).

• Требования к языкам программирования и стандартам.

• Запрет использования устаревших программных интерфейсов и возможностей.

• Правила отправки патчей для включения в ядро.

• Настройки почтового клиента для отправки патчей.

• Правила приёма патчей.

• Правила лицензирования кода для ядра (лицензия GPL-2.0 c исключениями для системных вызовов, наличие SPDX-идентификаторов лицензии в каждом файле).

• Инструкция по добавлению нового системного вызова.

• Правила для отправки патчей к стабильным веткам ядра.

• Обработка проблем с безопасностью.

• Действия при выявлении регрессий.

• Руководство по взаимодействию с сопровождающими.

• Руководства, специфичные для подсистем.

Ранее автор curl Даниэль Стенберг объявил, что его открытый проект перестанет изучать отчёты об уязвимостях через платформу HackerOne, полученные с помощью ИИ-систем. По заверению Стенберга, подобные массовые сообщения об уязвимостях от систем на базе ИИ перегружают команду проекта. Для проверки ИИ-отчётов необходимо время, которое несравнимо с тем временем, что тратится для создания подобных отчётов при помощи ИИ.