Re: [PATCH 1/4] docs/devel: relax policy on AI-generated contributions

["Daniel P. Berrangé" <berrange@redhat.com>]

On Mon, Sep 21, 2026 at 09:52:48AM +0200, Paolo Bonzini wrote:

> diff --git a/docs/devel/llm-usage.rst b/docs/devel/llm-usage.rst
> new file mode 100644
> index 00000000000..972436828a6
> --- /dev/null
> +++ b/docs/devel/llm-usage.rst
> @@ -0,0 +1,202 @@
> +.. _llm-usage:
> +
> +Use of AI-generated content
> +===========================
> +
> +.. warning::
> +
> +   Please read the below policy before using AI to contribute code or
> +   documentation to QEMU.  This applies to ChatGPT, Claude, Copilot,
> +   Llama, and similar tools.
> +
> +The QEMU project does not want to introduce restrictions on the tools
> +that contributors use for their work on the project.  However,
> +the increasing prevalence of AI-assisted software development,
> +and especially the use of content generated by `Large Language Models
> +<https://en.wikipedia.org/wiki/Large_language_model>`__ (LLMs),
> +poses a number of difficult questions.

It is a bit odd saying we don't want to restrict tools, since that is
exactly what we do want todo in this document. 

Perhaps

 The QEMU project does not want to dictate what tools contributors use
 for their work on the project. The increasing prevalence of AI-assisted
 software development, and especially the use of content generated by
 `Large Language Models <https://en.wikipedia.org/wiki/Large_language_model>`__
 (LLMs), poses a number of difficult questions, requiring some guidance
 around acceptable contribution practices involving LLMS.


> +
> +Risks to open source projects include maintainer burnout from an
> +increased number of contributions, as well as the risk to the project
> +from unintentional inclusion of copyrighted material in the LLM's output.
> +In order to mitigate these risks, the QEMU project limits the way
> +in which use of the output of generative AI can be included
> +in contributions to QEMU.
> +
> +The main guidelines for use of generative AI tools are roughly
> +as follows:
> +
> +- It's fine to use LLMs to answer questions, analyze, distill,
> +  refine, check, suggest, review. Use of LLMs to *create* is limited.
> +
> +- If in doubt, disclose any use of AI tools other than simple code
> +  completion and code review.
> +
> +- LLMs are allowed as a tool to write *better*, not *faster*.
> +
> +.. note:: **Use of AI does not remove the need for authors to comply
> +          with all other requirements for contribution.**  In particular,
> +          the ``Signed-off-by`` label in a patch submission is a statement
> +          that the author takes responsibility for the entire contents of
> +          the patch, certifying that their patch submission is made in
> +          accordance with the rules of the :ref:`Developer's Certificate of
> +          Origin (DCO) <dco>`.
> +
> +          Since a submitter cannot audit LLM output against its training
> +          data, the DCO is paired with :ref:`metadata in the commit message
> +          <ai-used-for>` about AI-generated parts.  The DCO still certifies
> +          that the contributor has the legal right to submit code in general.

I'm not a fan of this second paragraph, as that feels like it is undermining
the DCO. That first sentence in particular is somewhat saying that the
contributor does not have to think about plagarism and thed project is ok
with that, and also implying that the DCO doesn't apply to the LLM output.
This is both not OK in its implication of the project accepting some
liability, and then also contradicted by the next sentence.

IMHO this paragraph should just be removed.  The first paragraph clearly
states the DCO applies to the submission as a whole, and leaves all liability
for infringement on the contributor.


> +LLM-assisted and LLM-created contributions
> +''''''''''''''''''''''''''''''''''''''''''
> +
> +Use of generative AI tools for code contributions generally falls into
> +four buckets:

> +- use of LLMs to help generating parts of a larger patch---test cases,
> +  adaptations of existing code, boilerplate code for a new API, a tool to
> +  help performing mechanical changes, etc.  These are generally allowed;
> +  disclosure is highly recommended for non-trivial, functional code.
> +
> +- large, heavily LLM-assisted contributions where LLMs write large parts
> +  of functional code.  These are only allowed if *pre-arranged*,
> +  *high-quality* and *well-tested*.


In *both* of these cases, I think we should state a expectation that
the human contributor *must* be able to explain the *reasons* for
all key design choices in the code.

If a tool generates a qtest  test case with a bunch of device accesses,
the contributor needs to know what those are doing and why they are
appropriate usage in the real world

When a reviewer asks questions about the patch, they don't want to get
an answer "that's just the way the LLM did it", as then we've just back
to arguing with a bot again, even if the human wrote the mail.

Even for minor design choices that an LLM might make on its own, the
contributors needs to be able to explain and justify why they are
desirable.



> +
> +- "High-quality" means that the contributor must apply the same judgment
> +  that would be applied to other code changes.  Contributors must invest
> +  substantial time reviewing their contributions, curating them, and
> +  understanding them in depth; in particular, you are still expected to
> +  :ref:`understand and explain your changes
> +  <write_a_meaningful_commit_message>` and the rationale behind them.


This needs to apply to all cases, not merely the 'pre-arranged' large
contribution.

> +
> +- "Well-tested" means the LLM-created contributions will be held to a
> +  higher standard than human-created ones, because LLMs make it easier
> +  to write tests.  There are no exceptions for "writing the tests seems
> +  hard" or for `yak shaving <https://en.wiktionary.org/wiki/yak_shaving>`__.
> +
> +.. note::
> +    Pre-arrangement ensures maintainers have bandwidth for review before a
> +    contributor invests effort in creating a large change.  This is not
> +    a new concept in QEMU: maintainers have always encouraged early
> +    alignment on mailing lists or IRC prior to major architecture or
> +    subsystem refactoring.
> +
> +    Maintainers have freedom to determine what constitutes "high quality".
> +    Because LLMs lower the cost of patch generation, maintainers may demand
> +    significantly larger changes than for purely human-written code.
> +
> +.. _ai-used-for:


With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|