Как отправлять код, написанный ИИ, в open source проекты

Что нужно сделать перед отправкой кода, созданного с помощью ИИ, в upstream

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

Правильный патч будет отклонен, если проект запрещает сгенерированный код или если вы скрыли его происхождение. Репутационные издержки ложатся на ваше имя и остаются с вами, так как сопровождающий, обнаруживший сокрытие позже, не будет доверять остальной части вашей истории коммитов. Сначала определимся с терминами, так как они используются в политиках. LLM (large language model) — это модель, лежащая в основе вашего помощника по написанию кода. PR (pull request) на GitHub — это то же самое, что MR (merge request) на GitLab, и все нижесказанное применимо к обоим. DCO (developer certificate of origin) — это строка подтверждения в конце сообщения коммита, которая оказывается в центре всей дискуссии.

Текущее состояние политик open source в отношении кода, созданного ИИ

Проекты разделились на четыре категории. Все приведенные ниже примеры имеют дату, так как эти документы постоянно обновляются.

Запрещено. Совет Gentoo 14 апреля 2024 года проголосовал за то, что «категорически запрещено вносить в Gentoo любой контент, созданный с помощью инструментов искусственного интеллекта на основе обработки естественного языка». Руководство по коммитам NetBSD называет вывод LLM «испорченным кодом» (tainted code), который «не должен быть закоммичен без предварительного письменного одобрения со стороны ядра разработчиков». Документ о происхождении кода QEMU по состоянию на август 2026 года по-прежнему гласит, что проект будет «ОТКЛОНЯТЬ любые вклады, которые, как считается, включают или являются производными от контента, созданного ИИ».

Только анализ. Большинство запретов более узкие, чем кажется из заголовков. Документ QEMU гласит, что политика «не применяется к другим способам использования ИИ, таким как исследование API или алгоритмов, статический анализ или отладка, при условии, что их вывод не включается в состав вкладов». Вы можете использовать агента для чтения кода. Вы не можете поставлять то, что он написал. Это различие является рабочей границей внутри большинства строгих проектов, и именно его люди часто упускают из виду.

Требуется раскрытие информации. Совет Fedora утвердил политику в отношении вкладов с помощью ИИ в октябре 2025 года. Она разрешает использование инструментов и возлагает ответственность на человека: участник является автором, несет полную ответственность за весь вклад и обязан раскрыть информацию, если значительная его часть была получена с помощью инструмента без изменений. В декабре 2025 года в документацию процесса ядра Linux была добавлена страница о помощниках по написанию кода с разделом для указания инструмента и строгим правилом о том, кто имеет право подписывать изменения (sign off).

Ничего не зафиксировано письменно. Это по-прежнему наиболее распространенный случай. В препринте от мая 2026 года, исследовавшем 1000 популярных репозиториев GitHub, было обнаружено, что только 118 из них имеют какую-либо письменную политику в отношении ИИ. Отсутствие запрета не означает разрешение. Спросите об этом в issue tracker одним предложением перед написанием патча, и ответ станет публичной записью, на которую вы сможете сослаться в будущем.

Почему сопровождающие установили эти правила

Первая причина — нагрузка на проверку кода, и арифметика здесь работает в одну сторону. Агент генерирует правдоподобный merge request на 400 строк за минуту. Качественная проверка такого запроса отнимает у сопровождающего полдня, а большинство сопровождающих — волонтеры. Стоимость отправки кода упала почти до нуля. Стоимость проверки не изменилась вовсе.

Проект curl демонстрирует крайнюю точку этой кривой. В середине 2025 года Daniel Stenberg сообщил, что примерно пятая часть отчетов об уязвимостях, поступающих через программу bug bounty, — это то, что он называет AI slop: отчеты, которые упоминают реальные функции и пути в коде, описывают правдоподобную атаку, но не содержат ничего полезного. В начале 2026 года проект закрыл программу вознаграждений, чтобы не финансировать этот поток. Это были отчеты, а не патчи, но механизм тот же: сопровождающий открывает ваш PR, уже будучи утомленным.

Проект GNOME Calendar сформулировал проблему в виде метки. В июне 2026 года проект ввел метку "Probabilistically Automated" для merge requests, демонстрирующих «значительную или полную зависимость от искусственного "интеллекта" при генерации кода», и точно описал симптом: «обычно сопровождается отсутствием надлежащего тестирования и доработкой патчей на основе теоретически предполагаемого поведения, а не корректности кода». Прочитайте последнюю фразу дважды. Код выглядит так, будто он должен работать. Никто не проверил, работает ли он на самом деле.

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

Как найти политику проекта в отношении ИИ?

Ищите в указанных местах, строго в этом порядке.

• CONTRIBUTING.md в корне репозитория, затем .github/CONTRIBUTING.md, затем любой файл DCO рядом с ними.
• Документация для разработчиков. QEMU хранит свои правила в docs/devel/code-provenance.rst. Ядро Linux хранит свои в Documentation/process/coding-assistants.rst.
• Веб-сайт проекта или вики. Политика Gentoo находится на странице совета в вики, а политика NetBSD — в руководстве по коммитам.
• Система отслеживания задач и архив списка рассылки. Политика обычно существует там месяцами, прежде чем кто-либо зафиксирует её в репозитории.

Находясь внутри локальной копии проекта, можно охватить большинство случаев одной командой grep:

grep -rniE '(llm|copilot|chatgpt|generative|ai-generated|ai-assisted)' CONTRIBUTING.md docs/ .github/ 2>/dev/null | head -20

Затем изучите историю самого проекта, так как зафиксированная практика важнее любого её краткого изложения:

git log --format='%(trailers:key=Assisted-by,valueonly)' | grep . | sort | uniq -c
git log --format='%(trailers:key=AI-used-for,valueonly)' | grep . | sort | uniq -c

Количество рядом со значением трейлера показывает, какой формат реально использует данный проект. Пустой результат означает, что никто не раскрывал информацию в таком формате, что само по себе является полезным фактом. Если проект размещён на GitHub, а сам рабочий процесс для вас в новинку, как работают pull requests и forks на GitHub описывает механику, на которую опирается этот раздел.

Раскрытие информации в трейлере коммита, а не в комментарии

Трейлер — это строка Key: value в последнем абзаце сообщения коммита. Git уже использует этот формат для Signed-off-by: и Co-authored-by:, а инструменты его распознают, поэтому это единственный способ раскрытия информации, который перемещается вместе с кодом в дерево репозитория.

net: release the buffer on the error path

The error path returned before releasing the buffer, so every failed
setup leaked one page.

Assisted-by: Claude:claude-3-opus coccinelle sparse
Signed-off-by: Your Real Name <you@example.com>

Ядро документирует этот формат как Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2] и четко ограничивает его использование: «AI-агенты НЕ ДОЛЖНЫ добавлять теги Signed-off-by. Только люди могут юридически подтверждать Developer Certificate of Origin (DCO)». Имя агента указывается в Assisted-by. Ваше имя указывается в Signed-off-by. Никогда не позволяйте инструменту записывать второе имя и никогда не позволяйте ему выдумывать адрес Co-authored-by, который никому не принадлежит.

Имена различаются, поэтому копируйте локальное имя, а не придумывайте свое. В патче, отправленном в список рассылки QEMU в мае 2026 года, предлагалось смягчить запрет проекта для механических изменений, тестов, документации и исправлений ошибок объемом до 20 строк, фиксируемых с помощью трейлера вида AI-used-for: tests, docs. По состоянию на август 2026 года это предложение находится в списке рассылки, а утвержденный документ по-прежнему запрещает сгенерированный контент. Один проект менял свою позицию дважды в период с 2023 по 2026 год. Следующее изменение не будет ждать вас, поэтому метод важнее, чем список.

git commit -s --trailer "Assisted-by: Claude:claude-3-opus" -m "net: release the buffer on the error path"
git log -1 --format='%(trailers:key=Assisted-by,valueonly)'

Для --trailer требуется Git 2.32 или новее. Вторая команда должна вывести значение обратно вам. Пустая строка означает, что git не распознал трейлер; почти всегда это происходит из-за того, что внутри блока трейлера в конце сообщения находится пустая строка или обычное предложение. Для серии коммитов, которую вы уже написали, git rebase --signoff origin/main добавляет подпись к каждому коммиту, а git interpret-trailers --in-place --trailer "Assisted-by: Claude:claude-3-opus" msg.txt редактирует файл сообщения.

Стоит предусмотреть два сценария сбоя. Squash-merge переписывает сообщение коммита, поэтому в проектах, где используется squash, повторяйте раскрытие информации в описании PR, где его прочитает мейнтейнер. Комментарий к ревью не является записью, так как комментарии можно редактировать, и они никогда не попадают в историю git.

Точность важна в обоих направлениях. Assisted-by в коммите, который вы написали вручную, — это шум, который обесценивает ваши реальные раскрытия информации. Отсутствие этого тега в коммите, написанном агентом, — это то, что прекращает доверительные отношения.

Что на самом деле подтверждает Signed-off-by?

DCO — это короткий текст версии 1.1, опубликованный на developercertificate.org и используемый в ядре Linux, QEMU и многих других проектах. Добавление Signed-off-by: Your Name <you@example.com> означает, что вы подтверждаете свое согласие с ним. Прочитайте, под чем именно вы подписываетесь, так как большинство людей ставят подпись, не читая текст.

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

Обратите внимание на то, чего здесь нет. DCO не требует, чтобы вы набрали каждый символ самостоятельно. Он требует, чтобы вы имели право предоставить код на условиях данной лицензии. Именно поэтому сгенерированный код вызывает вопросы: дело не в авторстве, а в том, можете ли вы подтвердить его происхождение. Большинство проектов, требующих подписи, также требуют использования настоящего имени, поэтому псевдоним не пройдет проверку. Добавьте строку с помощью git commit -s, которая считывает user.name и user.email из вашей конфигурации git. Если бот DCO отклоняет ваш PR и указывает на коммит, в котором отсутствует эта строка, git rebase --signoff origin/main и принудительная отправка (force push) в вашу ветку исправят ситуацию.

Подписание коммита не равносильно sign-off

git commit -s добавляет строку текста. git commit -S создает криптографическую подпись объекта коммита с использованием вашего ключа GPG или SSH. Они отвечают на разные вопросы. Подпись подтверждает, что этот коммит поступил от владельца данного ключа и не был изменен с момента подписания. Она ничего не говорит о происхождении кода внутри, поэтому подписанный коммит, содержащий нераскрытый сгенерированный код, является подписанным, но все равно нарушает политику. Sign-off — это заявление о происхождении. Подпись — это заявление об идентичности. Проекты, которым требуется и то, и другое, будут запрашивать оба подтверждения.

Никогда не отправляйте код, который вы не можете объяснить при проверке

Этот тест — не столько проверка на честность. Для каждой строки кода вы должны знать: зачем она нужна и что сломается без неё? Если вы не можете ответить на любой из этих вопросов, патч не готов, так как при проверке возникнут вопросы, и вам придётся тратить время на повторную генерацию. Ревьюеры это чувствуют. В этот момент участник проекта становится обузой. Задавайте те же вопросы о граничных случаях, пустых входных данных, путях обработки ошибок и повторных вызовах.

Запустите код. Соберите проект, выполните набор тестов и напишите репродьюсер для ошибки, которую вы исправляете. В документации ядра Linux честно указан запасной вариант: «Если исправление невозможно собрать или протестировать, или если невозможно создать репродьюсер, скажите об этом прямо: мейнтейнеры тратят слишком много времени на анализ непроверенных отчётов и нетестируемых исправлений». Фраза «Я не смог протестировать это на реальном оборудовании» ничего вам не стоит. Попытка выдать желаемое за действительное стоит вам репутации в проекте.

Отвечайте на комментарии к проверке самостоятельно, своими словами и в своё время. Ответ, который приходит через тридцать секунд после комментария и пересказывает его пятью абзацами, сразу выдаёт мейнтейнеру, что именно произошло. Старайтесь делать diff небольшим. Сорок строк, которые вы полностью понимаете, ценнее для проекта, чем четырехсотенный рефакторинг, за которым вы просто наблюдали. Если ваш агент продолжает выдавать больше, чем вы просили, навык ограничения изменений минимально необходимым объёмом — это способ сохранить патч в пределах того, что вы сможете защитить построчно.

Храните инструкции для агента в репозитории

Инструкции, которые вы даете своему агенту, являются частью вашего инструментария, поэтому относитесь к ним как к коду. Файл в корне репозитория, обычно AGENTS.md, содержит команду сборки, команду тестирования, формат сообщений коммитов, требования к подписи и правила оформления кода, которые уже задокументированы в проекте. Этот файл версионируется и доступен для проверки, и он будет одинаковым сегодня и завтра. Инструкции, вводимые по памяти в каждой сессии, приводят к созданию разных патчей, и вы не сможете определить, какая именно сессия создала патч, который был отклонен. В Написание AGENTS.md, понятного и агенту, и человеку рассматривается сам файл.

Одно предостережение относительно чужих репозиториев. Не делайте своим первым вкладом PR, добавляющий файл инструкций для агента в проект, который вы не поддерживаете. Это выглядит как попытка навязать политику использования инструментов извне, и это быстрый способ добиться того, чтобы ваш аккаунт ассоциировался с тем, от чего мейнтейнеры уже устали. Храните этот файл в своем форке, пока кто-нибудь не попросит его предоставить.

Место, где вы запускаете агента, имеет значение по той же причине. Агент, который может собрать проект и запустить тесты внутри контролируемой вами песочницы, предоставляет патч, который вы фактически проверили. В этом заключается разница между предоставлением проверенного решения и предположения. В Запуск агента для написания кода на собственном VPS рассматривается такая настройка, а в Практические различия между Claude Code, Cursor, Codex и Copilot описываются повседневные различия между этими инструментами.

Метод после изменения политики

1. Найдите установленную политику перед тем, как что-либо писать: репозиторий, документация для разработчиков, веб-сайт, трекер.
2. Если политики нет, задайте вопрос в issue одним предложением и сохраните ответ.
3. Раскройте информацию в форме, которую использует проект, в трейлере коммита и повторите её в теле PR, если проект выполняет squash.
4. Подпишитесь своим настоящим именем, осознавая, что эта строка является заявлением о вашем праве на отправку кода.
5. Проверьте свой собственный патч так, будто его написал незнакомец, потому что так оно и есть.

Каждый проект, упомянутый на этой странице, к моменту прочтения вами уже переместится. Пять шагов остаются неизменными.

FAQ

Нужно ли сообщать об использовании ИИ-помощника при написании кода?

Проверьте правила проекта, так как требования устанавливаются локально. Fedora требует раскрытия информации, если значительная часть вклада была создана инструментом без правок. В ядре Linux требуется использование трейлера Assisted-by. В Gentoo и QEMU по состоянию на август 2026 года такие вклады не принимаются вовсе. Если правила не зафиксированы, всё равно укажите это в трейлере коммита. Если сопровождающий узнает об этом позже, его реакция будет направлена на факт сокрытия, а не на сам инструмент, и это отношение распространится на все ваши будущие отправки.

Какие проекты с открытым исходным кодом запрещают код, сгенерированный ИИ?

По состоянию на август 2026 года: Gentoo (с апреля 2024 года), NetBSD (рассматривает вывод LLM как «загрязненный» код, требующий одобрения ядра), QEMU (отклоняет вклады, производные от сгенерированного контента), а также ряд приложений GNOME, включая Loupe и Calendar. Читайте правила каждого конкретного проекта, а не этот список, так как информация устаревает. Обратите внимание на исключение, общее для большинства из них: использование модели для изучения API, запуска статического анализа или помощи в отладке обычно допустимо, если её вывод не попадает в итоговый патч.

В чем разница между Signed-off-by и подписанным коммитом?

Signed-off-by — это строка обычного текста, добавляемая с помощью git commit -s. Она подтверждает сертификат происхождения разработчика (DCO), что означает ваше право на предоставление этого кода под лицензией проекта. Подписанный коммит, созданный с помощью git commit -S, представляет собой криптографическую подпись объекта коммита вашим GPG- или SSH-ключом. Она доказывает, что коммит был сделан именно вашим ключом и не подвергался изменениям. Происхождение и авторство — это разные утверждения, поэтому подписанный коммит всё равно может нарушать политику в отношении ИИ.

Можно ли указать информацию об использовании ИИ в описании pull request, а не в сообщении коммита?

Указывайте это в сообщении коммита, так как именно оно попадает в историю git и передается всем, кто клонирует репозиторий в будущем. Описание pull request можно отредактировать позже, и оно существует только на платформе хостинга. Добавьте эту информацию и в тело PR, если проект использует squash merge, так как при squash сообщение вашего коммита перезаписывается и трейлер может быть удален.

Мой pull request закрыли из-за того, что код был сгенерирован ИИ. Что делать?

Не спорьте о политике в ветке обсуждения, так как человек, закрывший PR, не принимал это правило в одиночку, и ветка — не то место, где его можно изменить. Прочитайте текст политики и решите, можете ли вы ей соответствовать. Если проект запрещает сгенерированные патчи, четкий отчет об ошибке с примером для воспроизведения (без самого патча) по-прежнему приветствуется и часто является более полезным вкладом. Если вы вернетесь с кодом, пусть это будет небольшое изменение, которое вы сможете защитить построчно.