Hi, Not sure if this belongs to the changes made in these patches but can we establish some "rules of engagement" in the mailing list discussions w.r.t AI usage in replies? I know that patch 3 touches on it a little bit but I'm talking mostly about mailing list email.
I've seen several cases now where we have an apparent non-English speaking trying to engage in review/discussions in the ML, and some the discussions are a bit off. I assume it has to do with human reply in English -> AI -> translated reply in language X, the developer reads it in X, writes a reply in X, then uses AI again to generate an English response for the ML. This works ... sometimes. And other times we have cases where the developer keeps sending the same stuff over and over again, and we're now wondering whether someone is being cheeky and ignoring feedback or if the developer didn't fully understand the feedback, and I bet it's the latter. I'll assume that we don't want to forbid AI usage in ML replies (might as well just forbid AI altogether in that case), but can we ask people to let everyone know in advance "this is a reply generated by Claude"? Maybe a tag in the reply or something? If I know I'm replying to a bot I'll refrain from write things like "dwell in your turf", or whatever lingo I came up with when replying, because I know the bots won't be able to deal with figures of speech or pop culture references and etc. If I know I'm talking to a bot we can make an effort to use plain, boring and direct English as possible. It'll also align our expectations w.r.t the interaction overall. Thanks, Daniel On 9/30/2026 5:54 AM, Paolo Bonzini wrote:
Based on the previous discussions, I am finally attempting a non-RFC version of the new AI policy. Discussion on v3 introduced interesting points on attestation and I think a consensus is forming. Why review the policy? The blanket ban no longer reflects reality, since contributors have been posting AI-generated patches or even larger series. This was done most likely in good faith, as these submissions predated the introduction of an AGENTS.md file, and it shows that AI can be used for useful and creative work on QEMU. Rather than expecting maintainers to police these contributors, the new policy seeks to ensure that AI usage helps us produce better code rather than simply move faster and flood us with dubious work. In the words of Warner Losh, we want to avoid "free as in puppy" contributions[1] that increase the load of present and future maintainers by adding technical debt. This is not a free-for-all. To avoid maintainer burnout, AI contributions must be grounded in respect for maintainers and in the existing contribution process. Large, heavily AI-assisted contributions require pre-arrangement with the relevant subsystem maintainers, and will be held to a higher standard. One of the reasons for the old policy was the issue of code provenance and the impossibility to certify the originality of code created by AI/LLM tools. The new policy tries to adopt a "Swiss cheese" approach to mitigating the risks implicit in accepting AI-generated code in three ways: 1) by requiring pre-arrangement for larger contributions, and making maintainers free to apply their own considerations (see [2] for a good list). Maintainers' preferences bring experience and creative thought into the process, and contributors must take them into account. 2) by introducing agent instructions that help the contributor drive the design and understand the code produced by the LLM; 3) by introducing an "AI-used-for" trailer that scopes areas where Signed-off-by cannot guarantee full control of provenance. This series reflects feedback from earlier requests for comments, and even earlier discussions with members of the QEMU community. Thanks to everyone who provided feedback on earlier drafts. Paolo v3->v4: - rework opening text [Daniel] - exempt "official project agents" from not being able to post to GitLab [Alex] - explicitly forbid clean room reimplementation [Kevin/Daniel] - remove "The DCO still certifies that the contributor has the legal right to submit code in general" paragraph, replace with a note that "AI-used-for" attests respecting the policies and is considered enough for DCO [Daniel, Kevin] - make the requirement to "understand and explain your changes" more prominent - small edits for grammar and clarity v2->v3: - remove parser example, replace with "adaptations of existing code" - when LLMs are used for boilerplate, "highly recommend" disclosure for "non-trivial, functional code". The idea here is to avoid having to disclose using AI to apply e.g. changes related to automatic code review, and leaving people some leeway. - clarify split between DCO (legal right to submit code in general) and AI-used-for acknowledging that the submitter cannot audit LLM output against e.g. the training data. - clarify the defense-in-depth/swiss-cheese approach to limit the risk of copyright violations from LLM output - mention that pre-arrangement is not an entirely new concept - mention that maintainers can demand larger changes than for human-written code - do not mention inclusion of the prompt - add checkpatch.pl hunk, changing the phrasing of "no AI" lint - rebase AGENTS.md on top of existing file, split - drop CLAUDE.md/GEMINI.md symlinks, already done via .claude/.gemini [1] https://lore.kernel.org/qemu-devel/canczdfrtwfrk0wnul2cpvf_9w2-8pxtjehkgktp+uv2st8s...@mail.gmail.com/ [2] https://lore.kernel.org/qemu-devel/CAFEAcA860fF_+ffk=cXiYyFoQo0wCSUJ6b=7nvllcwkhp6n...@mail.gmail.com/ Paolo Bonzini (4): docs/devel: relax policy on AI-generated contributions AGENTS.md: add final instructions AGENTS.md: let agents know what the participation rules are AGENTS.md: make the human part of the design process docs/devel/code-provenance.rst | 71 +---------- docs/devel/index-process.rst | 1 + docs/devel/llm-usage.rst | 213 +++++++++++++++++++++++++++++++++ AGENTS.md | 137 +++++++++++++++++++-- scripts/checkpatch.pl | 5 +- 5 files changed, 347 insertions(+), 80 deletions(-) create mode 100644 docs/devel/llm-usage.rst
