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

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

On Fri, May 29, 2026 at 06:17:29PM +0200, Paolo Bonzini wrote:
> 
> 
> Il ven 29 mag 2026, 17:46 Michael S. Tsirkin <mst@redhat.com> ha scritto:
> 
>     > If as a project we want to limit the
>     > blast-radius if we find we have to rip out a hypothetical tainted
>     > contribution, shouldn't that mean that we hold that as a project-wide
>     > line, rather than leaving it up to the opinion of the individual
>     > maintainer ?
> 
>     I guess, the maintainer can judge that the code is unique and qemu
>     specific enough, and follows from what it is doing automatically enough,
>     that the chances it is accidentally copying something are nil?
> 
> 
> One thing that I had in mind was using AI to adjust QEMU code as the kernel
> side goes through review and APIs change. The changes at that point may be not
> entirely mechanical and, more importantly for traceability, it probably will
> not make sense to separate them from the original code; but the code still has
> fundamentally a shape and design that was provided by the human.
> 
> Another, which is Rust-specific, is procedural macro code, which is often
> boring, or very much tied to the shape of the generated code and human-written
> traits, or both. See https://github.com/qemu/qemu/blob/master/rust/qemu-macros/
> src/migration_state.rs for an example, contrasting the block starting with
> "self.conversion = match" with the rest.
> 
> I don't think it makes sense to have a wholesale permission for procedural
> macros because that is not *always* true, or true for a whole file. But say a
> contributor wrote the overall specification/documentation first, and mostly
> one-shotted a skeleton with a prompt like "based on the documentation, generate
> basic attribute parsing code for the MigrationState derive macro, together with
> a code generator that provides empty methods for an implementation of the trait
> ::migration::MigrationState from rust/hw/migration/". Then I would absolutely
> not reject it. This is also the intention of the suggestion around prompts—to
> favor quick generation of boilerplate code over full "agentic" (blargh)
> implementation.


Agreed.

> 
>     > > +**Documentation and code comments**
>     > > +  While AI can help draft text, it still requires significant human
>     > > +  oversight.  Pay attention to the organization and flow of the
>     generated
>     > > +  text, and strictly fact-check all technical details as LLMs are
>     prone
>     > > +  to being confidently wrong.
>     >
>     > I think the application to documentation and comments is the part
>     > I'm least enthusiastic about here.
> 
>     But I am very enthusiastic about less agrammatical english in both.
>     AI is super helpful for non native speakers.
> 
> 
> I am also not enthusiastic for documentation; the review I gave for Philippe's
> unedited experiment was rather scathing. The main challenge for documentation
> is the structure of the work, which is really complicated to establish because
> the LLM doesn't have a clue about the underlying design.
> 
> But there can be interesting uses nevertheless, such as integrating knowledge
> from functional tests into documentation, that are worth exploring. Also for
> Rust I am really trying to have *all* functions commented (and tested through
> so tests) and AI can produce good results more often than not, especially when
> the model has access to a human-written file-level blurb.
> 
> 
>     > For changes to code, we have at
>     > least some guardrails on the AI output, in the fact that it has to
>     > compile and to pass tests. For changes to documentation, the
>     > only guardrails are human eyeballs.
>     >
>     > Also both comments and documentation ideally are a record of
>     > what we intended the behaviour to be. If an LLM is effectively
>     > autogenerating something documentation-shaped from the code we
>     > lose that.
> 
> 
> I agree with both of these observations, for what it's worth.
> 
> Paolo
> 
> 
>     >
>     > -- PMM
> 
>