QEMU: Определить политику, запрещающую использование генераторов кода ИИ ( github.com/qemu )
Интересно, мотивация действительно законна? У меня такое чувство, что некоторые проекты просто устали от просмотра дерьмовых заявок на ИИ
Это может честно сломать открытый исходный код, учитывая, как быстро вы можете генерировать ерунду и как долго ее рассматривать и отклонять. Я могу представить, что больше проектов пойдут по пути Android, где вы можете скачать исходный код, но реалистично вы не можете внести свой вклад как случайный сторонний наблюдатель.
Я всегда считал, что возможность ответвления проекта является основным преимуществом лицензирования с открытым исходным кодом, а Android был ответвлен, например, проектом GrapheneOS.
Качественный вклад в разработку программного обеспечения с открытым исходным кодом встречается редко, если только проект не является крупным.
Исторически противоположностью качественному вкладу было отсутствие вклада, а не чистый отрицательный вклад (беспорядочная ерунда, которая при проверке обходится дороже, чем приносит пользы).
Я понимаю, откуда это взялось, но я думаю, что это ошибка. Я согласен, что было бы неплохо, если бы был “хорошо устоявшийся закон” относительно ИИ и авторских прав, вероятно, относительно немного решений и почти ноль законов, на которых можно было бы основывать свои чувства.
В дополнение к политике отклонения вкладов от ИИ, я думаю, имеет смысл указать места, где может использоваться контент, созданный ИИ. Например, какая часть (обширной) настройки CI проекта QEMU действительно является тем, что критически важно защищать? А как насчет все более интересных тестовых случаев или сред, которые можно включить? Что-то вроде «вместо этого вносите эти вещи здесь и разумно используйте ИИ там, с такими-то ограждениями…»
Когда люди откажутся от этой архаичной практики отправки исправлений по электронной почте?
Отправка патчей по электронной почте — это, по сути, фильтр для мусора. Останавливает низкое усилие PR, и любой, кто действительно хочет потратить время на участие, не будет иметь проблем с разработкой рабочего процесса.
По сути, это «давайте прикроемся, сказав, что это не разрешено», и на практике это означает не допускать код, который человек считает кодом, сгенерированным ИИ.
Эта проблема также существует в университетах, несмотря на то, что многие из них предлагают студентам и сотрудникам Grammarly (Gen AI), одновременно пытаясь запретить Gen AI.
Звучит как хорошая идея — гарантировать, что разработчики владеют кодом, который они отправляют, а не прятаться за фразой «Я не знаю, почему он так делает, это написал ChatGPT».
Используйте ИИ, если хотите, но если человек на другой стороне это заметит, а вы не сможете защитить свое заявление, это станет проблемой.
> Используйте ИИ, если хотите, но если человек на другой стороне это заметит, а вы не сможете защитить свое заявление, это проблема.
Фактическая политика — «не используйте генераторы кода ИИ»; не пытайтесь втереться в доверие к «используйте, если хотите, но если человек на другой стороне может это заметить». По сути, это «это обман, только если вас поймают».
По аналогии, проекты с открытым исходным кодом обычно имеют политику (будь то письменную или неписьменную), согласно которой вы отправляете только тот код, который вам разрешено отправлять по закону. Теоретически вы можете взять кучу проприетарного кода, полученного путем обратного проектирования, на который у вас нет лицензии, или кучу кода из другого проекта, лицензию которого вы не соблюдаете, и отправить его в любом случае, налепив на него «Signed-off-by». Физически вас ничто не остановит, и люди могут и не заметить. Это не делает его нормальным.
Это больше похоже на разъяснение.
Правила относительно происхождения вкладов кода довольно строгие, то есть вы не можете вносить код других людей, если вы не можете убедиться, что лицензия является подходящей. LLM может выводить копию чужого кода, иногда дословно, не сообщая вам его источник, поэтому вы не можете вносить код, написанный LLM.
Ну, я полагаю, что ключевое отличие в том, что код детерминирован, то есть достигает ли статья своих целей — вопрос несколько субъективный, но с кодом это абсолютная уверенность.
Я уверен, что если участник, работающий над функцией, изначально использовал курсор для генерации кода, а затем проверил его, чтобы убедиться, что он работает так, как ожидалось, то это будет разрешено. Это больше подходит тем людям, которые просто хотят быстро написать PR-закодированный в Vibe, чтобы они могли добавить «внес вклад в проект QEMU» в свое резюме.
Вы ошибаетесь, в приложенном коммите четко указано, что все, написанное с помощью генерации кода ИИ или полученное с ее помощью, не допускается.
Я пробовал Claude Code (инструмент, который я нашел наиболее эффективным в плане агентной генерации/манипуляции кодом) для своего проекта эмулятора в течение последних нескольких дней. Часть его — это компилятор из определения архитектуры в дизассемблер/интерпретатор/рекомпилятор. Я наткнулся на довольно незначительную ошибку компилятора и решил попросить Клода отладить и исправить ее. Вот некоторые вещи, которые я отметил:
1. Мой код C# отлично скомпилировался и даже запустился, но он был убежден, что я пропустил закрывающую скобку в лямбде рядом с местом, где возникало исключение. Разница была … Помещение существующей скобки на новую строку. Уверенно заявил, что проблема была и объявил ее исправленной.
2. Он выяснил, что был обнаружен неожиданный тип, и реализовал путь, который позволил ему перейти к следующей ошибке, но не стал разбираться, почему этот тип туда попал; это была фактическая ошибка, а не необработанный тип. Поэтому он «исправил» ее, но просто отложил это дело в долгий ящик.
3. При выяснении проблемы он просто посмотрел на трассировку стека. Вот и все. Он запустил сам компилятор; он мог бы просто встроить какой-нибудь отладочный код (как я) и выяснить, в чем на самом деле проблема, но он даже не попытался. Исключением было просто NotSupportedException без дополнительных деталей, с которыми можно было бы работать, поэтому добавление всего лишь крохи контекста позволило бы решить проблему.
Итак, это самый простой эмулятор, в который можно было бы вставить ИИ? Нет, совсем нет. Но и qemu тоже. Я совершенно не убежден, что текущие инструменты могут обеспечить реальную ценность для таких кодовых баз. Я настроен оптимистично в отношении их будущего и постоянно использую GenAI, но сегодня это не жизнеспособный вариант использования.
Source: news.ycombinator.com