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

[Markus Armbruster <armbru@redhat.com>]

Daniel P. Berrangé <berrange@redhat.com> writes:

> On Thu, Oct 01, 2026 at 01:21:43PM +0100, Peter Maydell wrote:
>> On Wed, 30 Sept 2026 at 09:54, Paolo Bonzini <pbonzini@redhat.com> wrote:
>> > +LLM-assisted and LLM-created contributions
>> > +''''''''''''''''''''''''''''''''''''''''''
>> > +
>> > +Use of generative AI can be classified in the following four buckets:
>> > +
>> > +- "background" assistance, such as completion and code review.  This does
>> > +  not need disclosure.
>> > +
>> > +- small LLM-assisted bugfixes (as a rule of thumb, below 10 lines of code)
>> > +  are allowed with disclosure.  Splitting a submission in multiple parts
>> > +  is **not** a valid way to bypass this rule; repeated, frequent posting
>> > +  of such fixes must follow the rule for full contributions.
>> > +
>> > +- 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.
>> 
>> I think we can get or have consensus on these first three buckets...
>> 
>> > +- 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*.
>> > +
>> > +The last case (*"LLM-created contribution"*) is the one that requires
>> > +a more careful approach.  In particular:
>> > +
>> > +- "Pre-arranged" means that a maintainer has communicated ahead of time,
>> > +  for example on `IRC or the QEMU mailing
>> > +  list <https://www.qemu.org/contribute/>`__, that they are willing
>> > +  to review an LLM-created contribution.
>> > +
>> > +- "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.
>> > +
>> > +- "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>`__.
>> 
>> ...but I think fundamentally I am not in favour of having this
>> fourth category of permitted uses. It seems even to have lost the
>> idea of it being an "experimental" approach in this revision of the
>> series. The first three categories are fine, and I have no particular
>> problem with our relaxing our current policy to explicitly permit them.
>
> I suggested previously to remove the "experimental" tag, because it
> felt rather misleading wrt what the policy was actually proposing to
> permit in practice.
>
>
> When we're saying that a maintainer and contributor can agree to
> use AI for *anything* and will merge it, then that work has ceased
> to be for "experiments". It is a fully accepted use case for writing
> and merging code. All the policy is doing at that point is attempting
> to rate-limit work by requiring prior agreement to use AI.
>
>
>> Our problem as a project does not seem to be on the "writing
>> code" side of things, but has always been on the "code review"
>> side. This policy relaxation makes it much easier to write more
>> code. Even when there's a "pre-arranged reviewer" that isn't
>> necessarily helpful -- if you're one of the primary maintainers
>> for an area of QEMU then the fact that somebody else is reviewing
>> it doesn't make a big AI-generated code infusion any more palatable.
>
> Yes, that is my concern with anything that ends up spreading outside
> the bounds of a single subsystem & its maintainer(s).

A big part (maybe the biggest) of my review load is patches crossing
boundaries.

Alice posts patches for a subsystem maintained by Bob and Charlie, but
she also needs a new QMP interface, so I get copied on that.  This is
*fine*.

David wants to do the same but with AI.  He "pre-arranges", and Bob
agrees to review.  Does Charlie get a vote?  What about me?

Charlie and I can of course leave the review to Bob.  But we'll have to
live with whatever makes it into the tree.

I fear this risks creating resentment among maintainers.

[...]