Re: GCC, Conservancy and Rust AI documents (was Re: [PATCH v2] docs/devel: relax policy on AI-generated contributions)

["Michael S. Tsirkin" <mst@redhat.com>]

On Mon, Aug 10, 2026 at 11:18:44AM +0100, Peter Maydell wrote:
> On Fri, 7 Aug 2026 at 19:43, Paolo Bonzini <pbonzini@redhat.com> wrote:
> > No one is going to agree 100% with everyone else; the only possible
> > equilibrium is going to be the current "no AI for code generation"
> > policy.
> 
> Also, I'm not sure we even have consensus on what the goals
> of an AI policy should be. At least, in my own mind I am
> not sure about that. We might care about, to different degrees:
> 
>  - the possibility that AI contributions might later be found
>    to be copyright-infringing or otherwise legally encumbered,
>    and need to be removed again
>  - poor quality of resulting generated code
>  - that a large number of individually OK-looking changes might
>    pile up to result in design messes and degeneration of the
>    codebase into "big ball of mud" architecture (you can argue
>    we already have this difficulty without AI :-))
>  - that our already very limited code-review ability gets
>    overwhelmed if we allow AI-generated patchsets (there are
>    already human-generated patchsets which go unreviewed and
>    ignored as it is)
>  - that we don't think one-shot AI-generated changes are likely
>    to be a pathway by which new contributors join the community
>    in the longer term
>  - various non-technical aspects like those the Rust policy drafters
>    labelled as "out of scope for discussion" under the "ethics"
>    label
> 
> (and probably others that I have forgotten).


Well the 15 line limit helps with these too, to a degree.


> The current policy being "no AI" on a fairly narrow legal ground
> had the advantage for me that I didn't need to consider my views
> on all the rest of this. If we relax that strong position then
> what kinds of relaxation we're OK with depends on what goals
> we are trying to achieve and what problems we're trying to
> defend against.
> 
> > Second, the Rust project came up with a different way to approach the
> > issue: require disclosure of LLM-assisted changes and hold them to a
> > higher bar.
> 
> That's not really the way the Rust policy came over to me. I
> read it more as "no AI for codegen, but with an 'experimental'
> back door for limited use". But that comes down to how much
> "experimental" really means that to them and how much it's
> "not actually experimental but the label made it easier to get
> the policy agreed"...
> 
> I do think the "pre-agreement and pre-finding-a-reviewer" parts
> are worth thinking about; to the extent that we've allowed some
> AI-assisted work already, it's had that kind of "pre-agreement
> and done by somebody we already trust as a contributor" aspect.
> 
> Also, I would be more in favour of uses of AI in the project
> that made my life / job easier. "More and larger and more
> frequent patch submissions that I have to review" isn't that,
> so I am not super enthusiastic about permitting LLM assisted
> contributions. ("Deluge of not very interesting autogenerated
> bug reports" isn't great either, for that matter.)
> 
> -- PMM