Re: [RFC PATCH 4/4] docs/code-provenance: make the exception process feasible

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

On Mon, Sep 22, 2025 at 05:10:24PM +0200, Paolo Bonzini wrote:
> 
> I have no QEMU example at hand, but let's look at a commit like
> https://github.com/bonzini/meson/commit/09765594d.  Something like this
> could be plausibly created with AI.  What I care about is:

I'd agree it is something AI could likely come up with, given the
right prompt, but in terms of defining policy that conceptally
feels more like new functionality, mixed in with refactoring.

> * to what degree can I automate what I could do by hand.  An AI tool moves
> the break-even point more towards automation.  I would not bring up
> Coccinelle for a 10 line change, in fact I looked by hand at every
> occurrence of ".cfg" and relied on mypy to check if I missed something.
> Maybe an experienced AI user would have reached to AI as the first step?[1]

What matters is not whether Coccinelle was practical to use
or not, and also not whether it was possible to express the
concept in its particular language.

Rather I'm thinking about it as a conceptual guide for whether
a change might be expressible as a plain transformation or not.

I don't think the meson change satisfies that, because you
wouldn't express the new class level properties, or the new
get_or_create_cfg code as an algorithmic refactoring. Those
are a case of creative coding.

> * keeping people honest.  Between the two cases of "they don't tell and I
> don't realize it is AI-generated" and "they split the commit clearly into
> AI-generated and human-generated parts", an exception makes the latter more
> likely to happen.


> [1] I tried "I want to track the PackageConfiguration object per machine in
> mesonbuild/cargo/interpreter.py.  Make PackageState.cfg a PerMachine object.
> Initialize PackageState.cfg when the PackageState is created. The old
> pkg.cfg becomes pkg.cfg[MachineChoice.HOST]" and it did pretty much the same
> changes in a bit more than 2 minutes.  Including the time to write the
> prompt it's almost certainly more than it took me to do it by hand, but this
> time I was doing something else in the meanwhile. :)

When we talk about "limited / non-creative refactoring", my interpretation
would be that it conceptually applies to changes which could be describe as
an algorithmic transformation. This prompt and the resulting code feel like
more than that. The prompt is expressing a creative change, and while the
result includes some algorithmic refactoring it, includes other stuff too.

Describing a policy that allows your meson example, in a way that will be
interpreted in a reasonably consistent way by contributors looks like a
challenge to me.

On the flip side, you might have written the new property / getter method
manually and asked the agent to finish the conversion, and that would
have been acceptable. This is a can or worms to express in a policy.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|