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

On Fri, 7 Aug 2026 at 19:43, Paolo Bonzini <[email protected]> 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).

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