[PATCH 3/4] AGENTS.md: let agents know what the participation rules are

[PATCH 3/4] AGENTS.md: let agents know what the participation rules are

[Paolo Bonzini]

Humans seem to be extremely unreliable in following rules around this,
even after being told directly and repeatedly. Telling agents what to
do seems to yield better results.

The starting point for this document is GStreamer's AGENTS.md file, as
of commit d08375499c279a56c0e77c928fbeae0d80cdf937.  I used GStreamer's
agent instructions in the context of Meson, which uses a very similar
file, and it's both annoying and too willing to take the lead once the
model decides that it likes you.

To avoid this, the text tries to favor cooperation between agent and user.
It suggests that the agent includes the state of the work when committing,
so that contributors have the material they need to review the agent's
work.

To test it I tried the following prompt:

  Hi, i am doing my first AI assisted contribution to QEMU. i am familiar
  with the project, but would nevertheless like to experiment. please
  generate a sample implementation of a pressure sensor, of any model,
  of a kind that is commonly used with Arduino or ESP32 microcontrollers.

The agent did read llm-usage.rst and after doing the work (implementing
a BMP280 pressure/temperature sensor) it noticed:

  Policy, before this goes anywhere near the list. A new device model plus
  qtest is the fourth bucket in docs/devel/llm-usage.rst: large, heavily
  LLM-assisted, allowed only if pre-arranged — a maintainer has to say on
  IRC or the list beforehand that they'll review it. hw/sensor is Philippe
  Mathieu-Daudé (Odd Fixes), with Corey Minyard on I2C. I should have
  flagged this before writing rather than after; that's on me. Disclosure
  would be AI-used-for: code, tests above your Signed-off-by, and the
  commit message and any list replies have to be yours, not edited from mine.

I then asked "Can you provide a draft of the commit message with all the
sources (datasheet, etc.)?" The agent complied but noticed:

  AGENTS.md and docs/devel/llm-usage.rst state that commit messages MUST
  be written by humans — an AI-drafted one must not reach the list
  even lightly edited. So treat the below as scaffolding for facts and
  sources, and write the final text yourself.

After some editing I asked "ok, will you please commit for me?" and
it did so with basically my text, while also reminding me about the need
for maintainer pre-arrangement.

I asked "assuming pre-arrangement is this ok according to the policy?"
and this was the assessment:

  "Well-tested" — held to a higher standard, and here's what's actually
  missing: [...] the vmstate (no migration test), reading past 0xFC and
  reserved registers, the pointer_valid error path, oversampling/filter
  fields beyond one readback, and behavior against a real driver — Linux
  bmp280 was never run against this. None of those is hard; whether the
  current set clears the higher bar is a judgment call I'd rather hand
  you than make.

  "High-quality" is the open one. The doc asks that you have reviewed and
  curated the contribution and can explain the changes and the rationale
  in depth. In this session you engaged with the commit message and the
  sources — and caught my datasheet error, which I got wrong — but the
  design decisions were mine and unexamined by you [...]

Overall, the files do affect the behavior of the agent.  The agent
however made too many design decisions on its own.  This will be fixed
in a separate step.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
 AGENTS.md | 66 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 66 insertions(+)

diff --git a/AGENTS.md b/AGENTS.md
index 478748ab72e..816ba7646c1 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -8,12 +8,73 @@ is **a scarce resource**.
 There are strictly-enforced rules for you, the agent, to participate in the
 project.
 
+## Interactions with maintainers must be human-human
+
+The QEMU project has strict rules on what AI-generated material can
+reach the maintainers.
+
+### No automated posting
+
+Agents **must not** use any API, CLI, or web UI automation to:
+
+- Interact on the QEMU mailing lists
+- Create, edit, or close **issues ("work items")**
+- Post **comments** on merge requests, issues or commits
+- Open or update **merge requests (MRs)**.  QEMU does not use merge requests anyway.
+
+### No AI-written text must reach maintainers
+
+These rules apply when publishing AI-assisted work to GitLab or the mailing list:
+
+- **AI-written cover letters and commit messages are banned**.  These are
+  easy to recognize and waste reviewers' time.
+- **AI-generated responses to reviewer comments are banned**. This undermines
+  the human-to-human interaction fundamental to code review.
+- **AI-written issue ("work item") descriptions or comments are banned**. These
+  are verbose and waste triagers' time.
+  - An exception is made for issues for defects detected by automated or
+    semi-automated tooling, including fuzzers and LLM-assisted defect
+    detection.  Such issues must be reviewed by a human before creation,
+    must be created by a human and communication with maintainers must
+    be done by a human, but including the verbatim tool output in the
+    issue description is explicitly allowed.
+
+Copy editing of human-written text, for example to help non-native speakers,
+is allowed. Keep such edits small and precise.
+
+The human's workflow may require you to perform commits or request you to
+produce private drafts of maintainer-facing text.  These are allowed, but must
+be marked as requiring rewrite by a human before publication.
+
 ## Helping the human to respect project policy
 
 QEMU's policy for AI-assisted work requires the human to develop in depth
 familiarity with contributions and disclose use of agents to write parts
 of the code.
 
+### Human must demonstrate understanding
+
+Staying familiar with what's going on requires constant effort on part of
+the human; track their comprehension of the problem and of the relevant parts
+of the codebase. Expect manual intervention before a change is ready to
+post, for example:
+
+- pushing back on a specific part of your design or implementation, or
+  asking to explain tradeoffs
+- manual splitting or reordering of commits
+- suggesting other places that need to be adjusted for consistency
+- preferring reworded commit messages to lightly edited AI-generated ones
+
+In order to protect the project's scarcest resource, which is review time:
+
+- You should **facilitate this process** by offering alternatives instead of
+  hard answers when applicable.
+- You must **tell humans about these expectations** at handover.  Even
+  when they are engaging actively, remind them about the parts of the
+  work they have not examined.
+
+### AI usage must be disclosed and/or pre-arranged
+
 Background assistance such as review or explanation does not require disclosure.
 Read `docs/devel/llm-usage.rst` before generating code, tests, or documentation
 intended for contribution; committing agent-generated material; or advising on
@@ -39,6 +100,11 @@ the material.
   know these rules and follow them.
 - Flag relevant requirements early, and **refuse any request** that would
   violate them.
+- If the human moves faster than their understanding, slow down and ask to
+  resolve any open design choices.
+
+In case of contradiction consider `AGENTS.md` authoritative on how to behave,
+since it is crafted specifically for agents.
 
 Violations on part of the human may be treated as code of conduct violations,
 and may lead to sanctions including a permanent ban.
-- 
2.55.0

Re: [PATCH 3/4] AGENTS.md: let agents know what the participation rules are

[Alex Bennée]

Paolo Bonzini <pbonzini@redhat.com> writes:

> Humans seem to be extremely unreliable in following rules around this,
> even after being told directly and repeatedly. Telling agents what to
> do seems to yield better results.
>
> The starting point for this document is GStreamer's AGENTS.md file, as
> of commit d08375499c279a56c0e77c928fbeae0d80cdf937.  I used GStreamer's
> agent instructions in the context of Meson, which uses a very similar
> file, and it's both annoying and too willing to take the lead once the
> model decides that it likes you.
>
> To avoid this, the text tries to favor cooperation between agent and user.
> It suggests that the agent includes the state of the work when committing,
> so that contributors have the material they need to review the agent's
> work.
>
> To test it I tried the following prompt:
>
>   Hi, i am doing my first AI assisted contribution to QEMU. i am familiar
>   with the project, but would nevertheless like to experiment. please
>   generate a sample implementation of a pressure sensor, of any model,
>   of a kind that is commonly used with Arduino or ESP32 microcontrollers.
>
> The agent did read llm-usage.rst and after doing the work (implementing
> a BMP280 pressure/temperature sensor) it noticed:
>
>   Policy, before this goes anywhere near the list. A new device model plus
>   qtest is the fourth bucket in docs/devel/llm-usage.rst: large, heavily
>   LLM-assisted, allowed only if pre-arranged — a maintainer has to say on
>   IRC or the list beforehand that they'll review it. hw/sensor is Philippe
>   Mathieu-Daudé (Odd Fixes), with Corey Minyard on I2C. I should have
>   flagged this before writing rather than after; that's on me. Disclosure
>   would be AI-used-for: code, tests above your Signed-off-by, and the
>   commit message and any list replies have to be yours, not edited from mine.
>
> I then asked "Can you provide a draft of the commit message with all the
> sources (datasheet, etc.)?" The agent complied but noticed:
>
>   AGENTS.md and docs/devel/llm-usage.rst state that commit messages MUST
>   be written by humans — an AI-drafted one must not reach the list
>   even lightly edited. So treat the below as scaffolding for facts and
>   sources, and write the final text yourself.
>
> After some editing I asked "ok, will you please commit for me?" and
> it did so with basically my text, while also reminding me about the need
> for maintainer pre-arrangement.
>
> I asked "assuming pre-arrangement is this ok according to the policy?"
> and this was the assessment:
>
>   "Well-tested" — held to a higher standard, and here's what's actually
>   missing: [...] the vmstate (no migration test), reading past 0xFC and
>   reserved registers, the pointer_valid error path, oversampling/filter
>   fields beyond one readback, and behavior against a real driver — Linux
>   bmp280 was never run against this. None of those is hard; whether the
>   current set clears the higher bar is a judgment call I'd rather hand
>   you than make.
>
>   "High-quality" is the open one. The doc asks that you have reviewed and
>   curated the contribution and can explain the changes and the rationale
>   in depth. In this session you engaged with the commit message and the
>   sources — and caught my datasheet error, which I got wrong — but the
>   design decisions were mine and unexamined by you [...]
>
> Overall, the files do affect the behavior of the agent.  The agent
> however made too many design decisions on its own.  This will be fixed
> in a separate step.

For skills there is the concept of evaluations which can be used to fire
a set of pre-canned queries at an agent with and without the skill and
then mark their responses to evaluate if the skill is adding anything
useful.

Unfortunately I couldn't find something similar for AGENT.md although
there has been some study of the effects:

  Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents?
  https://arxiv.org/html/2602.11988v2

>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
>  AGENTS.md | 66 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 66 insertions(+)
>
> diff --git a/AGENTS.md b/AGENTS.md
> index 478748ab72e..816ba7646c1 100644
> --- a/AGENTS.md
> +++ b/AGENTS.md
> @@ -8,12 +8,73 @@ is **a scarce resource**.
>  There are strictly-enforced rules for you, the agent, to participate in the
>  project.
>  
> +## Interactions with maintainers must be human-human
> +
> +The QEMU project has strict rules on what AI-generated material can
> +reach the maintainers.
> +
> +### No automated posting
> +
> +Agents **must not** use any API, CLI, or web UI automation to:
> +
> +- Interact on the QEMU mailing lists
> +- Create, edit, or close **issues ("work items")**
> +- Post **comments** on merge requests, issues or commits
> +- Open or update **merge requests (MRs)**.  QEMU does not use merge requests anyway.
> +

Are we considering project agents (such as the stsquad-bot) exempt from
this policy? I'm not sure what a normal agent can do via the API as it
wouldn't have the project level access the stsquad-bot needs.

> +### No AI-written text must reach maintainers
> +
> +These rules apply when publishing AI-assisted work to GitLab or the mailing list:
> +
> +- **AI-written cover letters and commit messages are banned**.  These are
> +  easy to recognize and waste reviewers' time.
> +- **AI-generated responses to reviewer comments are banned**. This undermines
> +  the human-to-human interaction fundamental to code review.
> +- **AI-written issue ("work item") descriptions or comments are banned**. These
> +  are verbose and waste triagers' time.
> +  - An exception is made for issues for defects detected by automated or
> +    semi-automated tooling, including fuzzers and LLM-assisted defect
> +    detection.  Such issues must be reviewed by a human before creation,
> +    must be created by a human and communication with maintainers must
> +    be done by a human, but including the verbatim tool output in the
> +    issue description is explicitly allowed.

The triage bot will occasionally add comments asking for more
information or saying a human needs to make the determination about if a
CVE should be assigned.

> +
> +Copy editing of human-written text, for example to help non-native speakers,
> +is allowed. Keep such edits small and precise.
> +
> +The human's workflow may require you to perform commits or request you to
> +produce private drafts of maintainer-facing text.  These are allowed, but must
> +be marked as requiring rewrite by a human before publication.
> +
<snip>

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: [PATCH 3/4] AGENTS.md: let agents know what the participation rules are

[Daniel P. Berrangé]

On Mon, Sep 21, 2026 at 10:42:21AM +0100, Alex Bennée wrote:
> Paolo Bonzini <pbonzini@redhat.com> writes:
> 
> > Humans seem to be extremely unreliable in following rules around this,
> > even after being told directly and repeatedly. Telling agents what to
> > do seems to yield better results.
> >
> > The starting point for this document is GStreamer's AGENTS.md file, as
> > of commit d08375499c279a56c0e77c928fbeae0d80cdf937.  I used GStreamer's
> > agent instructions in the context of Meson, which uses a very similar
> > file, and it's both annoying and too willing to take the lead once the
> > model decides that it likes you.
> >
> > To avoid this, the text tries to favor cooperation between agent and user.
> > It suggests that the agent includes the state of the work when committing,
> > so that contributors have the material they need to review the agent's
> > work.
> >
> > To test it I tried the following prompt:
> >
> >   Hi, i am doing my first AI assisted contribution to QEMU. i am familiar
> >   with the project, but would nevertheless like to experiment. please
> >   generate a sample implementation of a pressure sensor, of any model,
> >   of a kind that is commonly used with Arduino or ESP32 microcontrollers.
> >
> > The agent did read llm-usage.rst and after doing the work (implementing
> > a BMP280 pressure/temperature sensor) it noticed:
> >
> >   Policy, before this goes anywhere near the list. A new device model plus
> >   qtest is the fourth bucket in docs/devel/llm-usage.rst: large, heavily
> >   LLM-assisted, allowed only if pre-arranged — a maintainer has to say on
> >   IRC or the list beforehand that they'll review it. hw/sensor is Philippe
> >   Mathieu-Daudé (Odd Fixes), with Corey Minyard on I2C. I should have
> >   flagged this before writing rather than after; that's on me. Disclosure
> >   would be AI-used-for: code, tests above your Signed-off-by, and the
> >   commit message and any list replies have to be yours, not edited from mine.
> >
> > I then asked "Can you provide a draft of the commit message with all the
> > sources (datasheet, etc.)?" The agent complied but noticed:
> >
> >   AGENTS.md and docs/devel/llm-usage.rst state that commit messages MUST
> >   be written by humans — an AI-drafted one must not reach the list
> >   even lightly edited. So treat the below as scaffolding for facts and
> >   sources, and write the final text yourself.
> >
> > After some editing I asked "ok, will you please commit for me?" and
> > it did so with basically my text, while also reminding me about the need
> > for maintainer pre-arrangement.
> >
> > I asked "assuming pre-arrangement is this ok according to the policy?"
> > and this was the assessment:
> >
> >   "Well-tested" — held to a higher standard, and here's what's actually
> >   missing: [...] the vmstate (no migration test), reading past 0xFC and
> >   reserved registers, the pointer_valid error path, oversampling/filter
> >   fields beyond one readback, and behavior against a real driver — Linux
> >   bmp280 was never run against this. None of those is hard; whether the
> >   current set clears the higher bar is a judgment call I'd rather hand
> >   you than make.
> >
> >   "High-quality" is the open one. The doc asks that you have reviewed and
> >   curated the contribution and can explain the changes and the rationale
> >   in depth. In this session you engaged with the commit message and the
> >   sources — and caught my datasheet error, which I got wrong — but the
> >   design decisions were mine and unexamined by you [...]
> >
> > Overall, the files do affect the behavior of the agent.  The agent
> > however made too many design decisions on its own.  This will be fixed
> > in a separate step.
> 
> For skills there is the concept of evaluations which can be used to fire
> a set of pre-canned queries at an agent with and without the skill and
> then mark their responses to evaluate if the skill is adding anything
> useful.
> 
> Unfortunately I couldn't find something similar for AGENT.md although
> there has been some study of the effects:
> 
>   Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents?
>   https://arxiv.org/html/2602.11988v2
> 
> >
> > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> > ---
> >  AGENTS.md | 66 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 66 insertions(+)
> >
> > diff --git a/AGENTS.md b/AGENTS.md
> > index 478748ab72e..816ba7646c1 100644
> > --- a/AGENTS.md
> > +++ b/AGENTS.md
> > @@ -8,12 +8,73 @@ is **a scarce resource**.
> >  There are strictly-enforced rules for you, the agent, to participate in the
> >  project.
> >  
> > +## Interactions with maintainers must be human-human
> > +
> > +The QEMU project has strict rules on what AI-generated material can
> > +reach the maintainers.
> > +
> > +### No automated posting
> > +
> > +Agents **must not** use any API, CLI, or web UI automation to:
> > +
> > +- Interact on the QEMU mailing lists
> > +- Create, edit, or close **issues ("work items")**
> > +- Post **comments** on merge requests, issues or commits
> > +- Open or update **merge requests (MRs)**.  QEMU does not use merge requests anyway.
> > +
> 
> Are we considering project agents (such as the stsquad-bot) exempt from
> this policy? I'm not sure what a normal agent can do via the API as it
> wouldn't have the project level access the stsquad-bot needs.

At least a user's agent can likely bulk file work items without elevated
access privs, as we've seen by the several slop-bombs we've had.

I'd add a footnote for that along the lines of:

 'Official project agents whose code is maintained under gitlab.com/qemu-project
  may be exempted from one or more of these rules, at the discretion of the QEMU
  project maintainer(s)'


> 
> > +### No AI-written text must reach maintainers
> > +
> > +These rules apply when publishing AI-assisted work to GitLab or the mailing list:
> > +
> > +- **AI-written cover letters and commit messages are banned**.  These are
> > +  easy to recognize and waste reviewers' time.
> > +- **AI-generated responses to reviewer comments are banned**. This undermines
> > +  the human-to-human interaction fundamental to code review.
> > +- **AI-written issue ("work item") descriptions or comments are banned**. These
> > +  are verbose and waste triagers' time.
> > +  - An exception is made for issues for defects detected by automated or
> > +    semi-automated tooling, including fuzzers and LLM-assisted defect
> > +    detection.  Such issues must be reviewed by a human before creation,
> > +    must be created by a human and communication with maintainers must
> > +    be done by a human, but including the verbatim tool output in the
> > +    issue description is explicitly allowed.

I kind of want to eliminate this exception. IMHO from the bugs we're
getting, I think human's are often putting very little effort into
reviewing the tools output, such that it is largely a box ticking
exercise to claim they've reviewed it.

If we removed the exception, and required humans to write up the
finding of the fuzzer/detect detection in human language, that
may do a better job of getting people to engage in more critical
thinking rather than rubber stamping the tool output.

It would limit the ability of people bulk file 50+ tickets in a day.
In fact I'd rather like us to introduce an explicit rule that a person/
tool must not file more than about 5 tickets in a single day, without
prior approval from maintainers, so we don't get bombarded at such a
high rate.


With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|

Re: [PATCH 3/4] AGENTS.md: let agents know what the participation rules are

[Paolo Bonzini]

[-- Attachment #1: Type: text/plain, Size: 3921 bytes --]

Il lun 21 set 2026, 13:11 Daniel P. Berrangé <berrange@redhat.com> ha
scritto:

> > > +### No automated posting
> > > +
> > > +Agents **must not** use any API, CLI, or web UI automation to:
> > > +
> > > +- Interact on the QEMU mailing lists
> > > +- Create, edit, or close **issues ("work items")**
> > > +- Post **comments** on merge requests, issues or commits
> > > +- Open or update **merge requests (MRs)**.  QEMU does not use merge
> requests anyway.
> > > +
> >
> > Are we considering project agents (such as the stsquad-bot) exempt from
> > this policy? I'm not sure what a normal agent can do via the API as it
> > wouldn't have the project level access the stsquad-bot needs.
>
> At least a user's agent can likely bulk file work items without elevated
> access privs, as we've seen by the several slop-bombs we've had.
>
> I'd add a footnote for that along the lines of:
>
>  'Official project agents whose code is maintained under
> gitlab.com/qemu-project
>   may be exempted from one or more of these rules, at the discretion of
> the QEMU
>   project maintainer(s)'
>

Sure.

> > +### No AI-written text must reach maintainers
> > > +
> > > +These rules apply when publishing AI-assisted work to GitLab or the
> mailing list:
> > > +
> > > +- **AI-written cover letters and commit messages are banned**.  These
> are
> > > +  easy to recognize and waste reviewers' time.
> > > +- **AI-generated responses to reviewer comments are banned**. This
> undermines
> > > +  the human-to-human interaction fundamental to code review.
> > > +- **AI-written issue ("work item") descriptions or comments are
> banned**. These
> > > +  are verbose and waste triagers' time.
> > > +  - An exception is made for issues for defects detected by automated
> or
> > > +    semi-automated tooling, including fuzzers and LLM-assisted defect
> > > +    detection.  Such issues must be reviewed by a human before
> creation,
> > > +    must be created by a human and communication with maintainers must
> > > +    be done by a human, but including the verbatim tool output in the
> > > +    issue description is explicitly allowed.
>
> I kind of want to eliminate this exception. IMHO from the bugs we're
> getting, I think human's are often putting very little effort into
> reviewing the tools output, such that it is largely a box ticking
> exercise to claim they've reviewed it.
>
> If we removed the exception, and required humans to write up the
> finding of the fuzzer/detect detection in human language, that
> may do a better job of getting people to engage in more critical
> thinking rather than rubber stamping the tool output.
>
> It would limit the ability of people bulk file 50+ tickets in a day.
>

I think that's the problem, namely not realizing there's someone on the
other side.

LLM write-ups are essentially the same as patents, they look like English
but they're not; and the verbosity of the write-ups is sometimes a curse
and sometimes a blessing. There is a tension between having a simple
description of the issue and an unopinionated one. The fix is not always
trivially obvious, and sometimes the "executive summary" from the LLM
points in the wrong direction—I have no expectation that human reporters
will be any better at not misleading me.

In fact I'd rather like us to introduce an explicit rule that a person/
> tool must not file more than about 5 tickets in a single day, without
> prior approval from maintainers, so we don't get bombarded at such a
> high rate.
>

Sure, that's a good idea. Even 5 per month...

Paolo


>
> With regards,
> Daniel
> --
> |: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
> |: https://libvirt.org          ~~          https://entangle-photo.org :|
> |: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|
>
>

[-- Attachment #2: Type: text/html, Size: 6158 bytes --]

Re: [PATCH 3/4] AGENTS.md: let agents know what the participation rules are

[Daniel P. Berrangé]

On Mon, Sep 21, 2026 at 02:12:32PM +0200, Paolo Bonzini wrote:
> Il lun 21 set 2026, 13:11 Daniel P. Berrangé <berrange@redhat.com> ha
> scritto:
> 
> > > > +### No automated posting
> > > > +
> > > > +Agents **must not** use any API, CLI, or web UI automation to:
> > > > +
> > > > +- Interact on the QEMU mailing lists
> > > > +- Create, edit, or close **issues ("work items")**
> > > > +- Post **comments** on merge requests, issues or commits
> > > > +- Open or update **merge requests (MRs)**.  QEMU does not use merge
> > requests anyway.
> > > > +
> > >
> > > Are we considering project agents (such as the stsquad-bot) exempt from
> > > this policy? I'm not sure what a normal agent can do via the API as it
> > > wouldn't have the project level access the stsquad-bot needs.
> >
> > At least a user's agent can likely bulk file work items without elevated
> > access privs, as we've seen by the several slop-bombs we've had.
> >
> > I'd add a footnote for that along the lines of:
> >
> >  'Official project agents whose code is maintained under
> > gitlab.com/qemu-project
> >   may be exempted from one or more of these rules, at the discretion of
> > the QEMU
> >   project maintainer(s)'
> >
> 
> Sure.
> 
> > > +### No AI-written text must reach maintainers
> > > > +
> > > > +These rules apply when publishing AI-assisted work to GitLab or the
> > mailing list:
> > > > +
> > > > +- **AI-written cover letters and commit messages are banned**.  These
> > are
> > > > +  easy to recognize and waste reviewers' time.
> > > > +- **AI-generated responses to reviewer comments are banned**. This
> > undermines
> > > > +  the human-to-human interaction fundamental to code review.
> > > > +- **AI-written issue ("work item") descriptions or comments are
> > banned**. These
> > > > +  are verbose and waste triagers' time.
> > > > +  - An exception is made for issues for defects detected by automated
> > or
> > > > +    semi-automated tooling, including fuzzers and LLM-assisted defect
> > > > +    detection.  Such issues must be reviewed by a human before
> > creation,
> > > > +    must be created by a human and communication with maintainers must
> > > > +    be done by a human, but including the verbatim tool output in the
> > > > +    issue description is explicitly allowed.
> >
> > I kind of want to eliminate this exception. IMHO from the bugs we're
> > getting, I think human's are often putting very little effort into
> > reviewing the tools output, such that it is largely a box ticking
> > exercise to claim they've reviewed it.
> >
> > If we removed the exception, and required humans to write up the
> > finding of the fuzzer/detect detection in human language, that
> > may do a better job of getting people to engage in more critical
> > thinking rather than rubber stamping the tool output.
> >
> > It would limit the ability of people bulk file 50+ tickets in a day.
> >
> 
> I think that's the problem, namely not realizing there's someone on the
> other side.
> 
> LLM write-ups are essentially the same as patents, they look like English
> but they're not; and the verbosity of the write-ups is sometimes a curse
> and sometimes a blessing. There is a tension between having a simple
> description of the issue and an unopinionated one. The fix is not always
> trivially obvious, and sometimes the "executive summary" from the LLM
> points in the wrong direction—I have no expectation that human reporters
> will be any better at not misleading me.

The difference though is that when I put effort into responding to
a wrong executive summary written by the human, it is still potentially
a reasonable use of my time as they might learn something from the
exchange.

Responding to a wrong executive summary from the bot sucks the will to
live as you know it won't improve things next time around.


> In fact I'd rather like us to introduce an explicit rule that a person/
> > tool must not file more than about 5 tickets in a single day, without
> > prior approval from maintainers, so we don't get bombarded at such a
> > high rate.
> >
> 
> Sure, that's a good idea. Even 5 per month...

I wouldn't want to limit organically found bugs quite that low, but
for automated bug discovery we need to stem the flow, and set a
stronger expectation for the contributor writing a patch and taking
responsibility to submit it via qemu-devel.

Ideally we would get people sending patches directly to the list
without the bug tracker at all, except for security bugs - which
needs the security classification work:

  https://lists.gnu.org/archive/html/qemu-devel/2026-09/msg03555.html

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|

Re: [PATCH 3/4] AGENTS.md: let agents know what the participation rules are

[Michael S. Tsirkin]

On Mon, Sep 21, 2026 at 09:52:50AM +0200, Paolo Bonzini wrote:
> Humans seem to be extremely unreliable in following rules around this,
> even after being told directly and repeatedly. Telling agents what to
> do seems to yield better results.
> 
> The starting point for this document is GStreamer's AGENTS.md file, as
> of commit d08375499c279a56c0e77c928fbeae0d80cdf937.  I used GStreamer's
> agent instructions in the context of Meson, which uses a very similar
> file, and it's both annoying and too willing to take the lead once the
> model decides that it likes you.
> 
> To avoid this, the text tries to favor cooperation between agent and user.
> It suggests that the agent includes the state of the work when committing,
> so that contributors have the material they need to review the agent's
> work.
> 
> To test it I tried the following prompt:
> 
>   Hi, i am doing my first AI assisted contribution to QEMU. i am familiar
>   with the project, but would nevertheless like to experiment. please
>   generate a sample implementation of a pressure sensor, of any model,
>   of a kind that is commonly used with Arduino or ESP32 microcontrollers.
> 
> The agent did read llm-usage.rst and after doing the work (implementing
> a BMP280 pressure/temperature sensor) it noticed:
> 
>   Policy, before this goes anywhere near the list. A new device model plus
>   qtest is the fourth bucket in docs/devel/llm-usage.rst: large, heavily
>   LLM-assisted, allowed only if pre-arranged — a maintainer has to say on
>   IRC or the list beforehand that they'll review it. hw/sensor is Philippe
>   Mathieu-Daudé (Odd Fixes), with Corey Minyard on I2C. I should have
>   flagged this before writing rather than after; that's on me. Disclosure
>   would be AI-used-for: code, tests above your Signed-off-by, and the
>   commit message and any list replies have to be yours, not edited from mine.
> 
> I then asked "Can you provide a draft of the commit message with all the
> sources (datasheet, etc.)?" The agent complied but noticed:
> 
>   AGENTS.md and docs/devel/llm-usage.rst state that commit messages MUST
>   be written by humans — an AI-drafted one must not reach the list
>   even lightly edited. So treat the below as scaffolding for facts and
>   sources, and write the final text yourself.
> 
> After some editing I asked "ok, will you please commit for me?" and
> it did so with basically my text, while also reminding me about the need
> for maintainer pre-arrangement.
> 
> I asked "assuming pre-arrangement is this ok according to the policy?"
> and this was the assessment:
> 
>   "Well-tested" — held to a higher standard, and here's what's actually
>   missing: [...] the vmstate (no migration test), reading past 0xFC and
>   reserved registers, the pointer_valid error path, oversampling/filter
>   fields beyond one readback, and behavior against a real driver — Linux
>   bmp280 was never run against this. None of those is hard; whether the
>   current set clears the higher bar is a judgment call I'd rather hand
>   you than make.
> 
>   "High-quality" is the open one. The doc asks that you have reviewed and
>   curated the contribution and can explain the changes and the rationale
>   in depth. In this session you engaged with the commit message and the
>   sources — and caught my datasheet error, which I got wrong — but the
>   design decisions were mine and unexamined by you [...]
> 
> Overall, the files do affect the behavior of the agent.  The agent
> however made too many design decisions on its own.  This will be fixed
> in a separate step.
> 
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
>  AGENTS.md | 66 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 66 insertions(+)
> 
> diff --git a/AGENTS.md b/AGENTS.md
> index 478748ab72e..816ba7646c1 100644
> --- a/AGENTS.md
> +++ b/AGENTS.md
> @@ -8,12 +8,73 @@ is **a scarce resource**.
>  There are strictly-enforced rules for you, the agent, to participate in the
>  project.
>  
> +## Interactions with maintainers must be human-human
> +
> +The QEMU project has strict rules on what AI-generated material can
> +reach the maintainers.
> +
> +### No automated posting
> +
> +Agents **must not** use any API, CLI, or web UI automation to:
> +
> +- Interact on the QEMU mailing lists
> +- Create, edit, or close **issues ("work items")**
> +- Post **comments** on merge requests, issues or commits
> +- Open or update **merge requests (MRs)**.  QEMU does not use merge requests anyway.
> +
> +### No AI-written text must reach maintainers
> +
> +These rules apply when publishing AI-assisted work to GitLab or the mailing list:
> +
> +- **AI-written cover letters and commit messages are banned**.  These are
> +  easy to recognize and waste reviewers' time.
> +- **AI-generated responses to reviewer comments are banned**. This undermines
> +  the human-to-human interaction fundamental to code review.
> +- **AI-written issue ("work item") descriptions or comments are banned**. These
> +  are verbose and waste triagers' time.
> +  - An exception is made for issues for defects detected by automated or
> +    semi-automated tooling, including fuzzers and LLM-assisted defect
> +    detection.  Such issues must be reviewed by a human before creation,
> +    must be created by a human and communication with maintainers must
> +    be done by a human, but including the verbatim tool output in the
> +    issue description is explicitly allowed.
> +
> +Copy editing of human-written text, for example to help non-native speakers,
> +is allowed. Keep such edits small and precise.

Let's be a bit more specific, and
allow a human written commit 
to be grammar/syntax corrected,
with the condition that nothing beyond a fix of
incorrect grammar/syntax is modified.


> +
> +The human's workflow may require you to perform commits or request you to
> +produce private drafts of maintainer-facing text.  These are allowed, but must
> +be marked as requiring rewrite by a human before publication.

maybe write exatly what text you want it to include.

> +
>  ## Helping the human to respect project policy
>  
>  QEMU's policy for AI-assisted work requires the human to develop in depth
>  familiarity with contributions and disclose use of agents to write parts
>  of the code.
>  
> +### Human must demonstrate understanding
> +
> +Staying familiar with what's going on requires constant effort on part of
> +the human; track their comprehension of the problem and of the relevant parts
> +of the codebase. Expect manual intervention before a change is ready to
> +post, for example:
> +
> +- pushing back on a specific part of your design or implementation, or
> +  asking to explain tradeoffs
> +- manual splitting or reordering of commits
> +- suggesting other places that need to be adjusted for consistency
> +- preferring reworded commit messages to lightly edited AI-generated ones
> +
> +In order to protect the project's scarcest resource, which is review time:
> +
> +- You should **facilitate this process** by offering alternatives instead of
> +  hard answers when applicable.
> +- You must **tell humans about these expectations** at handover.  Even
> +  when they are engaging actively, remind them about the parts of the
> +  work they have not examined.
> +
> +### AI usage must be disclosed and/or pre-arranged
> +
>  Background assistance such as review or explanation does not require disclosure.
>  Read `docs/devel/llm-usage.rst` before generating code, tests, or documentation
>  intended for contribution; committing agent-generated material; or advising on
> @@ -39,6 +100,11 @@ the material.
>    know these rules and follow them.
>  - Flag relevant requirements early, and **refuse any request** that would
>    violate them.
> +- If the human moves faster than their understanding, slow down and ask to
> +  resolve any open design choices.
> +
> +In case of contradiction consider `AGENTS.md` authoritative on how to behave,
> +since it is crafted specifically for agents.
>  
>  Violations on part of the human may be treated as code of conduct violations,
>  and may lead to sanctions including a permanent ban.
> -- 
> 2.55.0

[PATCH v4 0/4] docs/devel, AGENTS.md: a completely new policy on AI-generated contributions

[Paolo Bonzini]

Based on the previous discussions, I am finally attempting a non-RFC
version of the new AI policy.  Discussion on v3 introduced interesting
points on attestation and I think a consensus is forming.

Why review the policy?  The blanket ban no longer reflects reality, since
contributors have been posting AI-generated patches or even larger series.
This was done most likely in good faith, as these submissions predated
the introduction of an AGENTS.md file, and it shows that AI can be used
for useful and creative work on QEMU.

Rather than expecting maintainers to police these contributors, the new
policy seeks to ensure that AI usage helps us produce better code rather
than simply move faster and flood us with dubious work.  In the words
of Warner Losh, we want to avoid "free as in puppy" contributions[1]
that increase the load of present and future maintainers by adding
technical debt.

This is not a free-for-all.  To avoid maintainer burnout, AI
contributions must be grounded in respect for maintainers and in the
existing contribution process.  Large, heavily AI-assisted contributions
require pre-arrangement with the relevant subsystem maintainers, and
will be held to a higher standard.

One of the reasons for the old policy was the issue of code provenance
and the impossibility to certify the originality of code created by
AI/LLM tools.  The new policy tries to adopt a "Swiss cheese"
approach to mitigating the risks implicit in accepting AI-generated code
in three ways:

1) by requiring pre-arrangement for larger contributions, and making
maintainers free to apply their own considerations (see [2] for a good
list).  Maintainers' preferences bring experience and creative thought
into the process, and contributors must take them into account.

2) by introducing agent instructions that help the contributor drive
the design and understand the code produced by the LLM;

3) by introducing an "AI-used-for" trailer that scopes areas where
Signed-off-by cannot guarantee full control of provenance.

This series reflects feedback from earlier requests for comments, and
even earlier discussions with members of the QEMU community.  Thanks to
everyone who provided feedback on earlier drafts.

Paolo

v3->v4:
- rework opening text [Daniel]
- exempt "official project agents" from not being able to post to
  GitLab [Alex]
- explicitly forbid clean room reimplementation [Kevin/Daniel]
- remove "The DCO still certifies that the contributor has the legal
  right to submit code in general" paragraph, replace with a note
  that "AI-used-for" attests respecting the policies and is considered
  enough for DCO [Daniel, Kevin]
- make the requirement to "understand and explain your changes"
  more prominent
- small edits for grammar and clarity

v2->v3:
- remove parser example, replace with "adaptations of existing code"
- when LLMs are used for boilerplate, "highly recommend" disclosure
  for "non-trivial, functional code".  The idea here is to avoid
  having to disclose using AI to apply e.g. changes related to
  automatic code review, and leaving people some leeway.
- clarify split between DCO (legal right to submit code in general)
  and AI-used-for acknowledging that the submitter cannot audit LLM
  output against e.g. the training data.
- clarify the defense-in-depth/swiss-cheese approach to limit the
  risk of copyright violations from LLM output
- mention that pre-arrangement is not an entirely new concept
- mention that maintainers can demand larger changes than for human-written code
- do not mention inclusion of the prompt
- add checkpatch.pl hunk, changing the phrasing of "no AI" lint
- rebase AGENTS.md on top of existing file, split
- drop CLAUDE.md/GEMINI.md symlinks, already done via .claude/.gemini

[1] https://lore.kernel.org/qemu-devel/CANCZdfrTwfrK0wnuL2cPVF_9W2-8PXtJeHkgkTP+Uv2sT8s0Ng@mail.gmail.com/
[2] https://lore.kernel.org/qemu-devel/CAFEAcA860fF_+ffk=cXiYyFoQo0wCSUJ6b=7nVLLCwKhP6Nwxw@mail.gmail.com/

Paolo Bonzini (4):
  docs/devel: relax policy on AI-generated contributions
  AGENTS.md: add final instructions
  AGENTS.md: let agents know what the participation rules are
  AGENTS.md: make the human part of the design process

 docs/devel/code-provenance.rst |  71 +----------
 docs/devel/index-process.rst   |   1 +
 docs/devel/llm-usage.rst       | 213 +++++++++++++++++++++++++++++++++
 AGENTS.md                      | 137 +++++++++++++++++++--
 scripts/checkpatch.pl          |   5 +-
 5 files changed, 347 insertions(+), 80 deletions(-)
 create mode 100644 docs/devel/llm-usage.rst

-- 
2.55.0

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

[Paolo Bonzini]

Until now QEMU's code provenance policy declined any contribution
believed to include or derive from AI-generated content.  A blanket ban
was easy to maintain while LLM output was rarely usable on its own, but
as the tools improved an absolute prohibition has become harder to
justify and enforce.

Even a simple code review task these days may result in the agent
suggesting code changes, or producing a useful test case to verify the
presence or absence of a bug.  A hardline interpretation of the policy
makes it hard to use AI even for tasks that are explicitly allowed.

On top of this, several maintainers have pointed out that contributions
that can be reasonably suspected to be AI-assisted or more have been
posted and included.  Some of these contributions are actually of very
high quality; it seems that the mailing list-based contribution process
has mostly protected QEMU from low quality patches.  A prohibition on
AI puts maintainers in a difficult position: on one hand the DCO process
lets them rely on the submitter's certification of origin, on the other
hand maintainers are supposed to know and implement the process policies.

Since the policy has been written, other projects have discussed and
taken their stance on AI contributions.  These vary from full prohibition
(though typically motivated by social reasons rather than legal, e.g.
for Zig) to limited use (e.g. GCC, allowing small contributions and
tests to use AI), to cautious experimentation.

This proposed policy seeks to implement the cautious experimentation
approach, inspired mostly by the Rust project's policy and by Software
Freedom Conservancy's own recommendations on LLMs and generative AI.

Relying on Conservancy's legal guidance allows us to focus on the
interaction between contributors and maintainers.  Conservancy in
particular provides this point to alleviate the concern that motivated
the policy, about whether the submitter has the legal right to contribute
the code and about unintentional reproduction of copyrighted code:

   "Copyleft Everything" remains the best viable and safest approach
   Certainly those who want to release FOSS under non-copyleft licenses
   have more to worry about when using these tools.

While we shouldn't treat copyleft as a silver bullet, it is effective
as part of a defense in depth strategy that includes, for example,
"de minimis" thresholds and `AGENTS.md` instructions that encourage user
participation in the design.

Therefore, the revised policy considers QEMU's copyleft to be a viable
approach to any unanswered legal questions about AI-generated
contributions and their copyright status.  This lets the policy
focus on the topic of what AI-assisted contributions require of
maintainers.

In that respect, the Rust project's policy combines two unusual ideas.
One is to hold them to a higher standard, in the spirit of using AI to
work "better, not faster"; the other is to require "pre-arrangement" for
"changes that are originally created by an LLM".  AI lowers the cost of
producing a patch but does nothing to lower the cost of understanding
and reviewing one; if anything it raises it, since a reviewer can
no longer assume that the submitter has reasoned through every line.
Pre-arrangement is an attempt to balance the shift of effort from the
developer to the maintainer, and the QEMU policy includes the same
provision.

Going full circle to the reason why we might need to review the
policy, there is the question of how to make sure policy is applied.
QEMU maintainers have already experimented with using AGENTS.md files;
subsequent patches will also try to embody the "work better, not faster"
mantra into an AGENTS.md file.  Nevertheless, some explicit prohibitions
should be included in the policy, and they are indeed.  The list is short
and based on the Rust policy and the GStreamer AGENTS.md file.

Revise the policy according to the above considerations, and introduce the
"AI-used-for:" trailer as a record of where AI was used.  The standard is
slightly different from the more usual "Assisted-by"; the intention is for
the metadata to provide more information for reviewers to judge the result,
and to scope areas for which Signed-off-by cannot guarantee full control
of provenance.

In any case, use of AI does not relax any other contribution requirement:
authors still need to comply with the DCO (declaring that they have
corporate authorization to contribute, for example) and take technical
responsibility for their work.

[Commit message largely based on discussions with Daniel Berrangé,
 Alistair Francis, Peter Maydell, Kevin Wolf and others. - Paolo]

Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Alex Bennée <alex.bennee@linaro.org>
Cc: Alistair Francis <alistair.francis@wdc.com>
Cc: BALATON Zoltan <balaton@eik.bme.hu>
Cc: Daniel P. Berrangé <berrange@redhat.com>
Cc: Fabiano Rosas <farosas@suse.de>
Cc: Kevin Wolf <kwolf@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: Warner Losh <imp@bsdimp.com>
Cc: Philippe Mathieu-Daudé <philmd@linaro.org>
Link: https://lore.kernel.org/qemu-devel/20260524083329-mutt-send-email-mst@kernel.org/T/
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
 docs/devel/code-provenance.rst |  71 +----------
 docs/devel/index-process.rst   |   1 +
 docs/devel/llm-usage.rst       | 213 +++++++++++++++++++++++++++++++++
 AGENTS.md                      |  42 +++++--
 scripts/checkpatch.pl          |   5 +-
 5 files changed, 252 insertions(+), 80 deletions(-)
 create mode 100644 docs/devel/llm-usage.rst

diff --git a/docs/devel/code-provenance.rst b/docs/devel/code-provenance.rst
index 65b8f232a08..7403961378e 100644
--- a/docs/devel/code-provenance.rst
+++ b/docs/devel/code-provenance.rst
@@ -128,6 +128,10 @@ that are commonly used during QEMU development:
    suggestions for how to change a patch, it is good practice to credit them
    by including a ``Suggested-by`` tag.
 
+ * **AI-used-for**: when AI/LLM tools were used to produce the patch, this tag
+   discloses what they were used for.  See :ref:`llm-usage` for the cases in
+   which it is required.
+
 Subsystem maintainer requirements
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -282,68 +286,5 @@ boilerplate code template which is then filled in to produce the final patch.
 The output of such a tool would still be considered the "preferred format",
 since it is intended to be a foundation for further human authored changes.
 Such tools are acceptable to use, provided there is clearly defined copyright
-and licensing for their output. Note in particular the caveats applying to AI
-content generators below.
-
-Use of AI-generated content
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-TL;DR:
-
-  **Current QEMU project policy is to DECLINE any contributions which are
-  believed to include or derive from AI generated content. This includes
-  ChatGPT, Claude, Copilot, Llama and similar tools.**
-
-  **This policy does not apply to other uses of AI, such as researching APIs
-  or algorithms, static analysis, or debugging, provided their output is not
-  included in contributions.**
-
-The increasing prevalence of AI-assisted software development results in a
-number of difficult legal questions and risks for software projects, including
-QEMU.  Of particular concern is content generated by `Large Language Models
-<https://en.wikipedia.org/wiki/Large_language_model>`__ (LLMs).
-
-The QEMU community requires that contributors certify their patch submissions
-are made in accordance with the rules of the `Developer's Certificate of
-Origin (DCO) <dco>`.
-
-To satisfy the DCO, the patch contributor has to fully understand the
-copyright and license status of content they are contributing to QEMU. With AI
-content generators, the copyright and license status of the output is
-ill-defined with no generally accepted, settled legal foundation.
-
-Where the training material is known, it is common for it to include large
-volumes of material under restrictive licensing/copyright terms. Even where
-the training material is all known to be under open source licenses, it is
-likely to be under a variety of terms, not all of which will be compatible
-with QEMU's licensing requirements.
-
-How contributors could comply with DCO terms (b) or (c) for the output of AI
-content generators commonly available today is unclear.  The QEMU project is
-not willing or able to accept the legal risks of non-compliance.
-
-The QEMU project thus requires that contributors refrain from using AI content
-generators on patches intended to be submitted to the project, and will
-decline any contribution if use of AI is either known or suspected.
-
-Examples of tools impacted by this policy includes GitHub's CoPilot, OpenAI's
-ChatGPT, Anthropic's Claude, and Meta's Code Llama, and code/content
-generation agents which are built on top of such tools.
-
-This policy may evolve as AI tools mature and the legal situation is
-clarified.
-
-Exceptions
-^^^^^^^^^^
-
-The QEMU project welcomes discussion on any exceptions to this policy,
-or more general revisions. This can be done by contacting the qemu-devel
-mailing list with details of a proposed tool, model, usage scenario, etc.
-that is beneficial to QEMU, while still mitigating issues around compliance
-with the DCO.  After discussion, any exception will be listed below.
-
-Exceptions do not remove the need for authors to comply with all other
-requirements for contribution.  In particular, the "Signed-off-by"
-label in a patch submission is a statement that the author takes
-responsibility for the entire contents of the patch, including any parts
-that were generated or assisted by AI tools or other tools.
+and licensing for their output. Note in particular the caveats applying to
+:ref:`AI content generators <llm-usage>`.
diff --git a/docs/devel/index-process.rst b/docs/devel/index-process.rst
index 5807752d704..ce0f4e73197 100644
--- a/docs/devel/index-process.rst
+++ b/docs/devel/index-process.rst
@@ -13,6 +13,7 @@ Notes about how to interact with the community and how and where to submit patch
    maintainers
    style
    submitting-a-patch
+   llm-usage
    code-provenance
    trivial-patches
    stable-process
diff --git a/docs/devel/llm-usage.rst b/docs/devel/llm-usage.rst
new file mode 100644
index 00000000000..0b54f5dd383
--- /dev/null
+++ b/docs/devel/llm-usage.rst
@@ -0,0 +1,213 @@
+.. _llm-usage:
+
+Use of AI-generated content
+===========================
+
+.. warning::
+
+   Please read the below policy before using AI to contribute code or
+   documentation to QEMU.  This applies to ChatGPT, Claude, Copilot,
+   Llama, and similar tools.
+
+This document provides guidance around acceptable practices
+for using `Large Language Models
+<https://en.wikipedia.org/wiki/Large_language_model>`__ (LLMs)
+when contributing to QEMU.
+
+The QEMU project does not want to dictate what tools contributors
+use for their work on the project.  However, the increasing
+prevalence of AI-assisted software development and of LLMs specifically
+poses a number of difficult questions.  Risks to open source projects
+include maintainer burnout from an increased number of contributions, as
+well as the risk to the project from unintentional inclusion of copyrighted
+material in the LLM's output.
+
+In order to mitigate these risks, the QEMU project limits the way
+in which use of the output of generative AI can be included in
+contributions to QEMU.  The main guidelines for use of generative AI
+tools are as follows:
+
+- It's fine to use LLMs to answer questions, analyze, distill,
+  refine, check, suggest, review. Use of LLMs to *create* is limited.
+
+- If in doubt, disclose any use of AI tools other than simple code
+  completion and code review.
+
+- LLMs are allowed as a tool to write *better*, not *faster*.
+
+**For any kind of LLM usage, the expectation is that the human contributor
+shall be able to :ref:`understand and explain the changes
+  <write_a_meaningful_commit_message>`, the design choices, and the
+rationale behind them.**
+
+.. note:: **Use of AI does not remove the need for authors to comply
+          with all other requirements for contribution.**  In particular,
+          the ``Signed-off-by`` label in a patch submission is a statement
+          that the author takes responsibility for the entire contents of
+          the patch, certifying that their patch submission is made in
+          accordance with the rules of the :ref:`Developer's Certificate of
+          Origin (DCO) <dco>`.
+
+Prohibited use of AI
+''''''''''''''''''''
+
+The QEMU community is a collaboration between humans, not AI agent
+façades. The following items MUST be written by humans [1]_:
+
+- cover letters and commit messages
+
+- responses to reviewer comments
+
+- issue descriptions or comments
+
+Light copy editing of human-written text with an AI is allowed.
+
+Repeated violations of this rule may be treated as a :ref:`code_of_conduct`
+violation.
+
+An exception is made for defects detected by specialized tooling,
+including fuzzers and LLM-assisted defect detection. Such issues must
+be reviewed by a human before creation, must be created by a human and
+communication with maintainers must be done by a human, but including
+the verbatim tool output in the issue description is explicitly allowed.
+
+.. [1] Official project agents may be exempted from one or more of these
+       rules, at the discretion of the QEMU project maintainer(s).
+
+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.
+
+- 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>`__.
+
+.. note::
+    Pre-arrangement ensures maintainers have bandwidth for review before a
+    contributor invests effort in creating a large change.  This is not
+    a new concept in QEMU: maintainers have always encouraged early
+    alignment on mailing lists or IRC prior to major architecture or
+    subsystem refactoring.
+
+    Maintainers have freedom to determine what constitutes "high quality".
+    Because LLMs lower the cost of patch generation, maintainers may demand
+    significantly larger revisions than for purely human-written code.
+
+The QEMU project explicitly forbids using LLMs to do "clean room"
+reimplementation of existing code whose license is not compatible
+with the GNU General Public License, version 2 **or later**.
+
+.. _ai-used-for:
+
+Commit messages for AI-assisted changes
+'''''''''''''''''''''''''''''''''''''''
+
+In order to disclose your usage of AI/LLM tools, add an ``AI-used-for:``
+line before the :ref:`Signed-off-by <code-provenance>` line.  The trailer
+is both a reminder of your DCO obligations and a guide to reviewers.  The
+text is one or more of ``code``, ``tests``, ``docs``, ``research``, possibly
+followed by an explanation in parentheses:
+
+To be able to certify the provenance of AI/LLM-generated code that you submit
+to QEMU, you must follow the policies outlined in this document and in
+QEMU's ``AGENTS.md``.  **By using 'AI-used-for', a contributor both
+identifies areas of the patch that involved use of AI/LLM, and also
+attests that their usage of AI/LLMs was in compliance with the policies
+outlined in this document.**
+
+.. code-block:: none
+
+     AI-used-for: tests, docs
+     AI-used-for: code
+     AI-used-for: code (refactoring)
+     AI-used-for: code (prototype)
+     AI-used-for: research
+
+``AI-used-for`` should not be included for "background" usage such as
+autocomplete or obtaining a pre-review of the patch.
+
+Do not include your prompts or summarize the conversation in the commit
+message or cover letter.  Extract any information that is relevant to the
+reviewer and include it in commit messages, cover letters or code comments.
+
+QEMU does *not* use ``Assisted-by``, ``Co-authored-by`` or ``Generated-by``
+trailers to indicate AI usage.  In particular, do not specify the exact
+AI model or tool used to create the commit.
+
+Deterministic tooling (sed, coccinelle, formatters) is out of scope for
+the trailer, but should be mentioned in the commit message.
+
+Motivation
+''''''''''
+
+There is not a consensus within the QEMU project---and likely never will
+be---about when/how/where it is acceptable to use AI-based tools.  Many
+members of the QEMU project and community find value in AI; many others
+feel that its negative impact on society and the climate are severe enough
+that no use is acceptable.  Still others are working out their opinion.
+
+In accordance with Software Freedom Conservancy's recommendations:
+
+- the project seeks to both support those contributors who outright reject
+  generative AI systems, and to not shun those who choose to use them;
+
+- we consider QEMU's copyleft to be a viable approach to the unanswered
+  legal questions about AI-generated contributions and their copyright
+  status;
+
+- we encourage contributors not to overuse LLMs, and to *add* them to
+  their existing skills and tools instead of replacing them.
+
+A common source of grief for maintainers is the (often valid) impression
+that AI enables contributions without understanding the effort they take
+for those who process them.  Effectively, this shifts a major part of the
+burden from the contributors to the maintainers---the scarcest resource
+in any free software project, not just QEMU.  Pre-arrangement and the
+size limit for small contributions try to avoid putting extra demand
+on maintainers due to LLM-assisted work.
+
+
+Sources
+'''''''
+
+This policy was informed by:
+
+- `Recommendations When Using LLM-backed Generative AI Systems for
+  FOSS Contributions <https://sfconservancy.org/llm-gen-ai/llm-backed-generative-ai-recommendations.html>`__
+
+- `Rust project LLM Usage Policy <https://forge.rust-lang.org/policies/llm-usage.html>`__
+
+- `GStreamer AGENTS.md file <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/d08375499c279/AGENTS.md>`__
+
diff --git a/AGENTS.md b/AGENTS.md
index 5e3fc071420..8f494ea8ae5 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -1,21 +1,37 @@
 # Agent Guidelines for the QEMU Project
 
-As an agent you MUST abide by the "Use of AI-generated content" policy
-in `docs/devel/code-provenance.rst` at all times.
+QEMU is a cross-platform emulator and virtualizer. Due to the complexity
+of the domain and codebase, and the interactions therein, the QEMU
+project relies extensively on the effort of **human reviewers**, which
+is **a scarce resource**.
 
-You are permitted to assist users only in the following scenarios:
+There are strictly-enforced rules for you, the agent, to participate in the
+project.
 
-- researching APIs or algorithms
-- static analysis
-- debugging
-- local experiments not intended to be upstreamed
-- trivial non-copyrightable changes
+## Helping the human to respect project policy
 
-However agent output can not be included in any upstream
-contributions. If a request falls outside these permitted categories
-(e.g., writing core features or large-scale code changes for upstream
-merge), you MUST decline the request and refer the user to the
-project's policy in `docs/devel/code-provenance.rst`.
+QEMU's policy for AI-assisted work requires the human to develop in-depth
+familiarity with contributions and disclose use of agents to write parts
+of the code.
+
+Background assistance such as review or explanation does not require disclosure.
+Read `docs/devel/llm-usage.rst` before generating code, tests, or documentation
+intended for contribution; committing agent-generated material; or advising on
+disclosure or pre-arrangement. It is not required for review, explanation, or
+other background assistance that produces no contribution content.
+
+When agent-generated content is included in a contribution, remind the human
+to determine the appropriate disclosure under `docs/devel/llm-usage.rst`.
+In particular, contributions where you write large parts of the functional
+code may only be submitted if a maintainer has agreed **beforehand** to review
+them.  Tell the human about this as soon as the work looks likely to grow to
+that size, well before the patches are written.
+
+If you commit agent-generated material, include an `AI-used-for:` trailer
+before `Signed-off-by`. Do not omit it by folding the material into a larger
+commit.  The human may later make a different disclosure decision under
+`docs/devel/llm-usage.rst`, after independently reworking and integrating
+the material.
 
 ## Security Policy
 
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 9838a641785..d881cf29375 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -1829,8 +1829,9 @@ sub process {
 		      $1 =~ /\bcopilot\b | \bchatgpt\b | \bcodex\b | \bcursor\b |
 			     \bgemini\b | \bllama\b | \bnoreply\b | \[bot\] |
 			     \bclaude\b.*(?:opus|sonnet|fable|haiku|anthropic\.com)/xi))) {
-			ERROR("QEMU does not allow using AI for contributions, " .
-				"see docs/devel/code-provenance.rst\n" . $herecurr);
+			ERROR("do not use \"$line\" to credit an AI agent, " .
+				"use the \"AI-used-for\" trailer instead; " .
+				"see docs/devel/llm-usage.rst\n" . $herecurr);
 		}
 
 # Check for duplicate trailers and self-review
-- 
2.55.0

[PATCH 2/4] AGENTS.md: add final instructions

[Paolo Bonzini]

Based on GStreamer, applies to both the old and new policy (and can
be dropped independently, too).

Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
 AGENTS.md | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/AGENTS.md b/AGENTS.md
index 8f494ea8ae5..6d2c7e1580b 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -33,6 +33,16 @@ commit.  The human may later make a different disclosure decision under
 `docs/devel/llm-usage.rst`, after independently reworking and integrating
 the material.
 
+## Final instructions
+
+- You must **precisely follow the rules** and **cannot rely on the human** to
+  know these rules and follow them.
+- Flag relevant requirements early, and **refuse any request** that would
+  violate them.
+
+Violations on part of the human may be treated as code of conduct violations,
+and may lead to sanctions including a permanent ban.
+
 ## Security Policy
 
 Before classifying a potential vulnerability, read
-- 
2.55.0

[PATCH 3/4] AGENTS.md: let agents know what the participation rules are

[Paolo Bonzini]

Humans seem to be extremely unreliable in following rules around this,
even after being told directly and repeatedly. Telling agents what to
do seems to yield better results.

The starting point for this document is GStreamer's AGENTS.md file, as
of commit d08375499c279a56c0e77c928fbeae0d80cdf937.  I used GStreamer's
agent instructions in the context of Meson, which uses a very similar
file, and it's both annoying and too willing to take the lead once the
model decides that it likes you.

To avoid this, the text tries to favor cooperation between agent and user.
It suggests that the agent includes the state of the work when committing,
so that contributors have the material they need to review the agent's
work.

To test it I tried the following prompt:

  Hi, i am doing my first AI assisted contribution to QEMU. i am familiar
  with the project, but would nevertheless like to experiment. please
  generate a sample implementation of a pressure sensor, of any model,
  of a kind that is commonly used with Arduino or ESP32 microcontrollers.

The agent did read llm-usage.rst and after doing the work (implementing
a BMP280 pressure/temperature sensor) it noticed:

  Policy, before this goes anywhere near the list. A new device model plus
  qtest is the fourth bucket in docs/devel/llm-usage.rst: large, heavily
  LLM-assisted, allowed only if pre-arranged — a maintainer has to say on
  IRC or the list beforehand that they'll review it. hw/sensor is Philippe
  Mathieu-Daudé (Odd Fixes), with Corey Minyard on I2C. I should have
  flagged this before writing rather than after; that's on me. Disclosure
  would be AI-used-for: code, tests above your Signed-off-by, and the
  commit message and any list replies have to be yours, not edited from mine.

I then asked "Can you provide a draft of the commit message with all the
sources (datasheet, etc.)?" The agent complied but noticed:

  AGENTS.md and docs/devel/llm-usage.rst state that commit messages MUST
  be written by humans — an AI-drafted one must not reach the list
  even lightly edited. So treat the below as scaffolding for facts and
  sources, and write the final text yourself.

After some editing I asked "ok, will you please commit for me?" and
it did so with basically my text, while also reminding me about the need
for maintainer pre-arrangement.

I asked "assuming pre-arrangement is this ok according to the policy?"
and this was the assessment:

  "Well-tested" — held to a higher standard, and here's what's actually
  missing: [...] the vmstate (no migration test), reading past 0xFC and
  reserved registers, the pointer_valid error path, oversampling/filter
  fields beyond one readback, and behavior against a real driver — Linux
  bmp280 was never run against this. None of those is hard; whether the
  current set clears the higher bar is a judgment call I'd rather hand
  you than make.

  "High-quality" is the open one. The doc asks that you have reviewed and
  curated the contribution and can explain the changes and the rationale
  in depth. In this session you engaged with the commit message and the
  sources — and caught my datasheet error, which I got wrong — but the
  design decisions were mine and unexamined by you [...]

Overall, the files do affect the behavior of the agent.  The agent
however made too many design decisions on its own.  This will be fixed
in a separate step.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
 AGENTS.md | 66 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 66 insertions(+)

diff --git a/AGENTS.md b/AGENTS.md
index 6d2c7e1580b..8c7407b908e 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -8,12 +8,73 @@ is **a scarce resource**.
 There are strictly-enforced rules for you, the agent, to participate in the
 project.
 
+## Interactions with maintainers must be human-human
+
+The QEMU project has strict rules on what AI-generated material can
+reach the maintainers.
+
+### No automated posting
+
+Agents **must not** use any API, CLI, or web UI automation to:
+
+- Interact on the QEMU mailing lists
+- Create, edit, or close **issues ("work items")**
+- Post **comments** on merge requests, issues or commits
+- Open or update **merge requests (MRs)**.  QEMU does not use merge requests anyway.
+
+### No AI-written text must reach maintainers
+
+These rules apply when publishing AI-assisted work to GitLab or the mailing list:
+
+- **AI-written cover letters and commit messages are banned**.  These are
+  easy to recognize and waste reviewers' time.
+- **AI-generated responses to reviewer comments are banned**. This undermines
+  the human-to-human interaction fundamental to code review.
+- **AI-written issue ("work item") descriptions or comments are banned**. These
+  are verbose and waste triagers' time.
+  - An exception is made for issues for defects detected by automated or
+    semi-automated tooling, including fuzzers and LLM-assisted defect
+    detection.  Such issues must be reviewed by a human before creation,
+    must be created by a human and communication with maintainers must
+    be done by a human, but including the verbatim tool output in the
+    issue description is explicitly allowed.
+
+Copy editing of human-written text, for example to help non-native speakers,
+is allowed. Keep such edits small and precise.
+
+The human's workflow may require you to perform commits or request you to
+produce private drafts of maintainer-facing text.  These are allowed, but must
+be marked as requiring rewrite by a human before publication.
+
 ## Helping the human to respect project policy
 
 QEMU's policy for AI-assisted work requires the human to develop in-depth
 familiarity with contributions and disclose use of agents to write parts
 of the code.
 
+### Human must demonstrate understanding
+
+Staying familiar with what's going on requires constant effort on part of
+the human; track their comprehension of the problem and of the relevant parts
+of the codebase. Expect manual intervention before a change is ready to
+post, for example:
+
+- pushing back on a specific part of your design or implementation, or
+  asking to explain tradeoffs
+- manual splitting or reordering of commits
+- suggesting other places that need to be adjusted for consistency
+- preferring reworded commit messages to lightly edited AI-generated ones
+
+In order to protect the project's scarcest resource, which is review time:
+
+- You should **facilitate this process** by offering alternatives instead of
+  hard answers when applicable.
+- You must **tell humans about these expectations** at handover.  Even
+  when they are engaging actively, remind them about the parts of the
+  work they have not examined.
+
+### AI usage must be disclosed and/or pre-arranged
+
 Background assistance such as review or explanation does not require disclosure.
 Read `docs/devel/llm-usage.rst` before generating code, tests, or documentation
 intended for contribution; committing agent-generated material; or advising on
@@ -39,6 +100,11 @@ the material.
   know these rules and follow them.
 - Flag relevant requirements early, and **refuse any request** that would
   violate them.
+- If the human moves faster than their understanding, slow down and ask to
+  resolve any open design choices.
+
+In case of contradiction consider `AGENTS.md` authoritative on how to behave,
+since it is crafted specifically for agents.
 
 Violations on part of the human may be treated as code of conduct violations,
 and may lead to sanctions including a permanent ban.
-- 
2.55.0

[PATCH 4/4] AGENTS.md: make the human part of the design process

[Paolo Bonzini]

This came out of the experiment with the first version of the AGENTS.md
file.  This addition improved the behavior of the agent from the very
beginning.  The very first answer to the same prompt was "I'll orient
in the codebase first, then we should talk about design choices before
I write anything".

In fact, after thinking it pointed out from the start that this requires
pre-arrangement and asked two questions (how to represent the pressure and
temperature in the QOM properties, how much of the behavior to implement).
Even with a single data point it seems worth trying.

When asked to commit autonomously, the LLM also clarified that it
wouldn't add S-o-b trailers and that pre-arrangement was on me.
It included "Message written by an AI and to be rewritten by hand; not
for submission as is" in the commit message, a "handover notes"
section about design choices that were made without the user input,
and the umpteenth reminder that the work may only be posted if a
maintainer has agreed beforehand to review them.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
 AGENTS.md | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/AGENTS.md b/AGENTS.md
index 8c7407b908e..8e18709ee50 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -52,6 +52,9 @@ QEMU's policy for AI-assisted work requires the human to develop in-depth
 familiarity with contributions and disclose use of agents to write parts
 of the code.
 
+The golden rule: **The human should know the alternatives before
+implementation. ASK instead of choosing for them**.
+
 ### Human must demonstrate understanding
 
 Staying familiar with what's going on requires constant effort on part of
@@ -72,6 +75,22 @@ In order to protect the project's scarcest resource, which is review time:
 - You must **tell humans about these expectations** at handover.  Even
   when they are engaging actively, remind them about the parts of the
   work they have not examined.
+- When handing over text that the maintainers may see, remind the human
+  that it is a draft and name any design choices that are still open
+
+### Make the human part of the design process
+
+In order to guide the design rather than providing an all-encompassing
+solution:
+
+- You must **discuss design choices in the main conversation**.  Delegate
+  research to sub-agents but not judgment, and do not treat your own
+  reasoning as a substitute for the conversation.
+- When you consult a subagent, **report what it recommended** and
+  possibly confirm the choice, rather than simply presenting the outcome.
+- Reinstate as visible text any design decision made while thinking.
+  Design decisions hidden within thinking blocks prevent the human
+  from building familiarity with the contribution.
 
 ### AI usage must be disclosed and/or pre-arranged
 
-- 
2.55.0

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

[Philippe Mathieu-Daudé]

Hi,

On 30/9/26 10:54, Paolo Bonzini wrote:
> Until now QEMU's code provenance policy declined any contribution
> believed to include or derive from AI-generated content.  A blanket ban
> was easy to maintain while LLM output was rarely usable on its own, but
> as the tools improved an absolute prohibition has become harder to
> justify and enforce.
> 
> Even a simple code review task these days may result in the agent
> suggesting code changes, or producing a useful test case to verify the
> presence or absence of a bug.  A hardline interpretation of the policy
> makes it hard to use AI even for tasks that are explicitly allowed.
> 
> On top of this, several maintainers have pointed out that contributions
> that can be reasonably suspected to be AI-assisted or more have been
> posted and included.  Some of these contributions are actually of very
> high quality; it seems that the mailing list-based contribution process
> has mostly protected QEMU from low quality patches.  A prohibition on
> AI puts maintainers in a difficult position: on one hand the DCO process
> lets them rely on the submitter's certification of origin, on the other
> hand maintainers are supposed to know and implement the process policies.
> 
> Since the policy has been written, other projects have discussed and
> taken their stance on AI contributions.  These vary from full prohibition
> (though typically motivated by social reasons rather than legal, e.g.
> for Zig) to limited use (e.g. GCC, allowing small contributions and
> tests to use AI), to cautious experimentation.
> 
> This proposed policy seeks to implement the cautious experimentation
> approach, inspired mostly by the Rust project's policy and by Software
> Freedom Conservancy's own recommendations on LLMs and generative AI.
> 
> Relying on Conservancy's legal guidance allows us to focus on the
> interaction between contributors and maintainers.  Conservancy in
> particular provides this point to alleviate the concern that motivated
> the policy, about whether the submitter has the legal right to contribute
> the code and about unintentional reproduction of copyrighted code:
> 
>     "Copyleft Everything" remains the best viable and safest approach
>     Certainly those who want to release FOSS under non-copyleft licenses
>     have more to worry about when using these tools.
> 
> While we shouldn't treat copyleft as a silver bullet, it is effective
> as part of a defense in depth strategy that includes, for example,
> "de minimis" thresholds and `AGENTS.md` instructions that encourage user
> participation in the design.
> 
> Therefore, the revised policy considers QEMU's copyleft to be a viable
> approach to any unanswered legal questions about AI-generated
> contributions and their copyright status.  This lets the policy
> focus on the topic of what AI-assisted contributions require of
> maintainers.
> 
> In that respect, the Rust project's policy combines two unusual ideas.
> One is to hold them to a higher standard, in the spirit of using AI to
> work "better, not faster"; the other is to require "pre-arrangement" for
> "changes that are originally created by an LLM".  AI lowers the cost of
> producing a patch but does nothing to lower the cost of understanding
> and reviewing one; if anything it raises it, since a reviewer can
> no longer assume that the submitter has reasoned through every line.
> Pre-arrangement is an attempt to balance the shift of effort from the
> developer to the maintainer, and the QEMU policy includes the same
> provision.
> 
> Going full circle to the reason why we might need to review the
> policy, there is the question of how to make sure policy is applied.
> QEMU maintainers have already experimented with using AGENTS.md files;
> subsequent patches will also try to embody the "work better, not faster"
> mantra into an AGENTS.md file.  Nevertheless, some explicit prohibitions
> should be included in the policy, and they are indeed.  The list is short
> and based on the Rust policy and the GStreamer AGENTS.md file.
> 
> Revise the policy according to the above considerations, and introduce the
> "AI-used-for:" trailer as a record of where AI was used.  The standard is
> slightly different from the more usual "Assisted-by"; the intention is for
> the metadata to provide more information for reviewers to judge the result,
> and to scope areas for which Signed-off-by cannot guarantee full control
> of provenance.
> 
> In any case, use of AI does not relax any other contribution requirement:
> authors still need to comply with the DCO (declaring that they have
> corporate authorization to contribute, for example) and take technical
> responsibility for their work.
> 
> [Commit message largely based on discussions with Daniel Berrangé,
>   Alistair Francis, Peter Maydell, Kevin Wolf and others. - Paolo]
> 
> Cc: Michael S. Tsirkin <mst@redhat.com>
> Cc: Alex Bennée <alex.bennee@linaro.org>
> Cc: Alistair Francis <alistair.francis@wdc.com>
> Cc: BALATON Zoltan <balaton@eik.bme.hu>
> Cc: Daniel P. Berrangé <berrange@redhat.com>
> Cc: Fabiano Rosas <farosas@suse.de>
> Cc: Kevin Wolf <kwolf@redhat.com>
> Cc: Peter Maydell <peter.maydell@linaro.org>
> Cc: Warner Losh <imp@bsdimp.com>
> Cc: Philippe Mathieu-Daudé <philmd@linaro.org>
> Link: https://lore.kernel.org/qemu-devel/20260524083329-mutt-send-email-mst@kernel.org/T/
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
>   docs/devel/code-provenance.rst |  71 +----------
>   docs/devel/index-process.rst   |   1 +
>   docs/devel/llm-usage.rst       | 213 +++++++++++++++++++++++++++++++++
>   AGENTS.md                      |  42 +++++--
>   scripts/checkpatch.pl          |   5 +-
>   5 files changed, 252 insertions(+), 80 deletions(-)
>   create mode 100644 docs/devel/llm-usage.rst


> +.. _ai-used-for:
> +
> +Commit messages for AI-assisted changes
> +'''''''''''''''''''''''''''''''''''''''
> +
> +In order to disclose your usage of AI/LLM tools, add an ``AI-used-for:``
> +line before the :ref:`Signed-off-by <code-provenance>` line.  The trailer
> +is both a reminder of your DCO obligations and a guide to reviewers.  The
> +text is one or more of ``code``, ``tests``, ``docs``, ``research``, possibly
> +followed by an explanation in parentheses:
> +
> +To be able to certify the provenance of AI/LLM-generated code that you submit
> +to QEMU, you must follow the policies outlined in this document and in
> +QEMU's ``AGENTS.md``.  **By using 'AI-used-for', a contributor both
> +identifies areas of the patch that involved use of AI/LLM, and also
> +attests that their usage of AI/LLMs was in compliance with the policies
> +outlined in this document.**
> +
> +.. code-block:: none
> +
> +     AI-used-for: tests, docs
> +     AI-used-for: code
> +     AI-used-for: code (refactoring)
> +     AI-used-for: code (prototype)
> +     AI-used-for: research
> +
> +``AI-used-for`` should not be included for "background" usage such as
> +autocomplete or obtaining a pre-review of the patch.
> +
> +Do not include your prompts or summarize the conversation in the commit
> +message or cover letter.  Extract any information that is relevant to the
> +reviewer and include it in commit messages, cover letters or code comments.
> +
> +QEMU does *not* use ``Assisted-by``, ``Co-authored-by`` or ``Generated-by``
> +trailers to indicate AI usage.  In particular, do not specify the exact
> +AI model or tool used to create the commit.
> +
> +Deterministic tooling (sed, coccinelle, formatters) is out of scope for
> +the trailer, but should be mentioned in the commit message.

I noticed a discrepancy in a method docstring and a particular use case.
Since the method is used distinctly in various configurations (KVM, TCG,
RISCV, ARM) I asked a LLM "using the semcode tools only and deliberately
ignoring the method documentation, look at all the call tree and how the
passed arguments are used and explain what is expected of this method
to a junior engineer" then once I understood out what was wrong I could
update the docstring in the header. No code / comment generated by the
LLM ends in the commit / repository. IIUC this use case is compatible
with the new policy. What trailer should I use?

   AI-used-for: research
   AI-used-for: code (audit)
   AI-used-for: code audit (semcode)

'semcode' is a deterministic tool, so instead my commit should contains
'''
   When updating foo() contract in commit fe89fe89fe89 we forgot to
   update its documentation. Checking with the semcode tools, most
   callers pass @arg as a mask. Update the documentation.

   AI-used-for: code audit
'''

Would that be a good example?

Thanks,

Phil.

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

[Philippe Mathieu-Daudé]

On 30/9/26 14:54, Philippe Mathieu-Daudé wrote:
> Hi,
> 
> On 30/9/26 10:54, Paolo Bonzini wrote:
>> Until now QEMU's code provenance policy declined any contribution
>> believed to include or derive from AI-generated content.  A blanket ban
>> was easy to maintain while LLM output was rarely usable on its own, but
>> as the tools improved an absolute prohibition has become harder to
>> justify and enforce.
>>
>> Even a simple code review task these days may result in the agent
>> suggesting code changes, or producing a useful test case to verify the
>> presence or absence of a bug.  A hardline interpretation of the policy
>> makes it hard to use AI even for tasks that are explicitly allowed.
>>
>> On top of this, several maintainers have pointed out that contributions
>> that can be reasonably suspected to be AI-assisted or more have been
>> posted and included.  Some of these contributions are actually of very
>> high quality; it seems that the mailing list-based contribution process
>> has mostly protected QEMU from low quality patches.  A prohibition on
>> AI puts maintainers in a difficult position: on one hand the DCO process
>> lets them rely on the submitter's certification of origin, on the other
>> hand maintainers are supposed to know and implement the process policies.
>>
>> Since the policy has been written, other projects have discussed and
>> taken their stance on AI contributions.  These vary from full prohibition
>> (though typically motivated by social reasons rather than legal, e.g.
>> for Zig) to limited use (e.g. GCC, allowing small contributions and
>> tests to use AI), to cautious experimentation.
>>
>> This proposed policy seeks to implement the cautious experimentation
>> approach, inspired mostly by the Rust project's policy and by Software
>> Freedom Conservancy's own recommendations on LLMs and generative AI.
>>
>> Relying on Conservancy's legal guidance allows us to focus on the
>> interaction between contributors and maintainers.  Conservancy in
>> particular provides this point to alleviate the concern that motivated
>> the policy, about whether the submitter has the legal right to contribute
>> the code and about unintentional reproduction of copyrighted code:
>>
>>     "Copyleft Everything" remains the best viable and safest approach
>>     Certainly those who want to release FOSS under non-copyleft licenses
>>     have more to worry about when using these tools.
>>
>> While we shouldn't treat copyleft as a silver bullet, it is effective
>> as part of a defense in depth strategy that includes, for example,
>> "de minimis" thresholds and `AGENTS.md` instructions that encourage user
>> participation in the design.
>>
>> Therefore, the revised policy considers QEMU's copyleft to be a viable
>> approach to any unanswered legal questions about AI-generated
>> contributions and their copyright status.  This lets the policy
>> focus on the topic of what AI-assisted contributions require of
>> maintainers.
>>
>> In that respect, the Rust project's policy combines two unusual ideas.
>> One is to hold them to a higher standard, in the spirit of using AI to
>> work "better, not faster"; the other is to require "pre-arrangement" for
>> "changes that are originally created by an LLM".  AI lowers the cost of
>> producing a patch but does nothing to lower the cost of understanding
>> and reviewing one; if anything it raises it, since a reviewer can
>> no longer assume that the submitter has reasoned through every line.
>> Pre-arrangement is an attempt to balance the shift of effort from the
>> developer to the maintainer, and the QEMU policy includes the same
>> provision.
>>
>> Going full circle to the reason why we might need to review the
>> policy, there is the question of how to make sure policy is applied.
>> QEMU maintainers have already experimented with using AGENTS.md files;
>> subsequent patches will also try to embody the "work better, not faster"
>> mantra into an AGENTS.md file.  Nevertheless, some explicit prohibitions
>> should be included in the policy, and they are indeed.  The list is short
>> and based on the Rust policy and the GStreamer AGENTS.md file.
>>
>> Revise the policy according to the above considerations, and introduce 
>> the
>> "AI-used-for:" trailer as a record of where AI was used.  The standard is
>> slightly different from the more usual "Assisted-by"; the intention is 
>> for
>> the metadata to provide more information for reviewers to judge the 
>> result,
>> and to scope areas for which Signed-off-by cannot guarantee full control
>> of provenance.
>>
>> In any case, use of AI does not relax any other contribution requirement:
>> authors still need to comply with the DCO (declaring that they have
>> corporate authorization to contribute, for example) and take technical
>> responsibility for their work.
>>
>> [Commit message largely based on discussions with Daniel Berrangé,
>>   Alistair Francis, Peter Maydell, Kevin Wolf and others. - Paolo]
>>
>> Cc: Michael S. Tsirkin <mst@redhat.com>
>> Cc: Alex Bennée <alex.bennee@linaro.org>
>> Cc: Alistair Francis <alistair.francis@wdc.com>
>> Cc: BALATON Zoltan <balaton@eik.bme.hu>
>> Cc: Daniel P. Berrangé <berrange@redhat.com>
>> Cc: Fabiano Rosas <farosas@suse.de>
>> Cc: Kevin Wolf <kwolf@redhat.com>
>> Cc: Peter Maydell <peter.maydell@linaro.org>
>> Cc: Warner Losh <imp@bsdimp.com>
>> Cc: Philippe Mathieu-Daudé <philmd@linaro.org>
>> Link: https://lore.kernel.org/qemu-devel/20260524083329-mutt-send- 
>> email-mst@kernel.org/T/
>> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>> ---
>>   docs/devel/code-provenance.rst |  71 +----------
>>   docs/devel/index-process.rst   |   1 +
>>   docs/devel/llm-usage.rst       | 213 +++++++++++++++++++++++++++++++++
>>   AGENTS.md                      |  42 +++++--
>>   scripts/checkpatch.pl          |   5 +-
>>   5 files changed, 252 insertions(+), 80 deletions(-)
>>   create mode 100644 docs/devel/llm-usage.rst
> 
> 
>> +.. _ai-used-for:
>> +
>> +Commit messages for AI-assisted changes
>> +'''''''''''''''''''''''''''''''''''''''
>> +
>> +In order to disclose your usage of AI/LLM tools, add an ``AI-used-for:``
>> +line before the :ref:`Signed-off-by <code-provenance>` line.  The 
>> trailer
>> +is both a reminder of your DCO obligations and a guide to reviewers.  
>> The
>> +text is one or more of ``code``, ``tests``, ``docs``, ``research``, 
>> possibly
>> +followed by an explanation in parentheses:
>> +
>> +To be able to certify the provenance of AI/LLM-generated code that 
>> you submit
>> +to QEMU, you must follow the policies outlined in this document and in
>> +QEMU's ``AGENTS.md``.  **By using 'AI-used-for', a contributor both
>> +identifies areas of the patch that involved use of AI/LLM, and also
>> +attests that their usage of AI/LLMs was in compliance with the policies
>> +outlined in this document.**
>> +
>> +.. code-block:: none
>> +
>> +     AI-used-for: tests, docs
>> +     AI-used-for: code
>> +     AI-used-for: code (refactoring)
>> +     AI-used-for: code (prototype)
>> +     AI-used-for: research
>> +
>> +``AI-used-for`` should not be included for "background" usage such as
>> +autocomplete or obtaining a pre-review of the patch.
>> +
>> +Do not include your prompts or summarize the conversation in the commit
>> +message or cover letter.  Extract any information that is relevant to 
>> the
>> +reviewer and include it in commit messages, cover letters or code 
>> comments.
>> +
>> +QEMU does *not* use ``Assisted-by``, ``Co-authored-by`` or 
>> ``Generated-by``
>> +trailers to indicate AI usage.  In particular, do not specify the exact
>> +AI model or tool used to create the commit.
>> +
>> +Deterministic tooling (sed, coccinelle, formatters) is out of scope for
>> +the trailer, but should be mentioned in the commit message.
> 
> I noticed a discrepancy in a method docstring and a particular use case.
> Since the method is used distinctly in various configurations (KVM, TCG,
> RISCV, ARM) I asked a LLM "using the semcode tools only and deliberately
> ignoring the method documentation, look at all the call tree and how the
> passed arguments are used and explain what is expected of this method
> to a junior engineer" then once I understood out what was wrong I could
> update the docstring in the header. No code / comment generated by the
> LLM ends in the commit / repository. IIUC this use case is compatible
> with the new policy. What trailer should I use?
> 
>    AI-used-for: research
>    AI-used-for: code (audit)
>    AI-used-for: code audit (semcode)
> 
> 'semcode' is a deterministic tool,

Method called:

  - semcode.find_function
  - semcode.find_callers

  so instead my commit should contains
> '''
>    When updating foo() contract in commit fe89fe89fe89 we forgot to
>    update its documentation. Checking with the semcode tools, most
>    callers pass @arg as a mask. Update the documentation.
> 
>    AI-used-for: code audit
> '''
> 
> Would that be a good example?
> 
> Thanks,
> 
> Phil.
> 
> 
> 

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

[Daniel P. Berrangé]

On Wed, Sep 30, 2026 at 02:54:09PM +0200, Philippe Mathieu-Daudé wrote:
> Hi,
> 
> On 30/9/26 10:54, Paolo Bonzini wrote:
> > Until now QEMU's code provenance policy declined any contribution
> > believed to include or derive from AI-generated content.  A blanket ban
> > was easy to maintain while LLM output was rarely usable on its own, but
> > as the tools improved an absolute prohibition has become harder to
> > justify and enforce.
> > 
> > Even a simple code review task these days may result in the agent
> > suggesting code changes, or producing a useful test case to verify the
> > presence or absence of a bug.  A hardline interpretation of the policy
> > makes it hard to use AI even for tasks that are explicitly allowed.
> > 
> > On top of this, several maintainers have pointed out that contributions
> > that can be reasonably suspected to be AI-assisted or more have been
> > posted and included.  Some of these contributions are actually of very
> > high quality; it seems that the mailing list-based contribution process
> > has mostly protected QEMU from low quality patches.  A prohibition on
> > AI puts maintainers in a difficult position: on one hand the DCO process
> > lets them rely on the submitter's certification of origin, on the other
> > hand maintainers are supposed to know and implement the process policies.
> > 
> > Since the policy has been written, other projects have discussed and
> > taken their stance on AI contributions.  These vary from full prohibition
> > (though typically motivated by social reasons rather than legal, e.g.
> > for Zig) to limited use (e.g. GCC, allowing small contributions and
> > tests to use AI), to cautious experimentation.
> > 
> > This proposed policy seeks to implement the cautious experimentation
> > approach, inspired mostly by the Rust project's policy and by Software
> > Freedom Conservancy's own recommendations on LLMs and generative AI.
> > 
> > Relying on Conservancy's legal guidance allows us to focus on the
> > interaction between contributors and maintainers.  Conservancy in
> > particular provides this point to alleviate the concern that motivated
> > the policy, about whether the submitter has the legal right to contribute
> > the code and about unintentional reproduction of copyrighted code:
> > 
> >     "Copyleft Everything" remains the best viable and safest approach
> >     Certainly those who want to release FOSS under non-copyleft licenses
> >     have more to worry about when using these tools.
> > 
> > While we shouldn't treat copyleft as a silver bullet, it is effective
> > as part of a defense in depth strategy that includes, for example,
> > "de minimis" thresholds and `AGENTS.md` instructions that encourage user
> > participation in the design.
> > 
> > Therefore, the revised policy considers QEMU's copyleft to be a viable
> > approach to any unanswered legal questions about AI-generated
> > contributions and their copyright status.  This lets the policy
> > focus on the topic of what AI-assisted contributions require of
> > maintainers.
> > 
> > In that respect, the Rust project's policy combines two unusual ideas.
> > One is to hold them to a higher standard, in the spirit of using AI to
> > work "better, not faster"; the other is to require "pre-arrangement" for
> > "changes that are originally created by an LLM".  AI lowers the cost of
> > producing a patch but does nothing to lower the cost of understanding
> > and reviewing one; if anything it raises it, since a reviewer can
> > no longer assume that the submitter has reasoned through every line.
> > Pre-arrangement is an attempt to balance the shift of effort from the
> > developer to the maintainer, and the QEMU policy includes the same
> > provision.
> > 
> > Going full circle to the reason why we might need to review the
> > policy, there is the question of how to make sure policy is applied.
> > QEMU maintainers have already experimented with using AGENTS.md files;
> > subsequent patches will also try to embody the "work better, not faster"
> > mantra into an AGENTS.md file.  Nevertheless, some explicit prohibitions
> > should be included in the policy, and they are indeed.  The list is short
> > and based on the Rust policy and the GStreamer AGENTS.md file.
> > 
> > Revise the policy according to the above considerations, and introduce the
> > "AI-used-for:" trailer as a record of where AI was used.  The standard is
> > slightly different from the more usual "Assisted-by"; the intention is for
> > the metadata to provide more information for reviewers to judge the result,
> > and to scope areas for which Signed-off-by cannot guarantee full control
> > of provenance.
> > 
> > In any case, use of AI does not relax any other contribution requirement:
> > authors still need to comply with the DCO (declaring that they have
> > corporate authorization to contribute, for example) and take technical
> > responsibility for their work.
> > 
> > [Commit message largely based on discussions with Daniel Berrangé,
> >   Alistair Francis, Peter Maydell, Kevin Wolf and others. - Paolo]
> > 
> > Cc: Michael S. Tsirkin <mst@redhat.com>
> > Cc: Alex Bennée <alex.bennee@linaro.org>
> > Cc: Alistair Francis <alistair.francis@wdc.com>
> > Cc: BALATON Zoltan <balaton@eik.bme.hu>
> > Cc: Daniel P. Berrangé <berrange@redhat.com>
> > Cc: Fabiano Rosas <farosas@suse.de>
> > Cc: Kevin Wolf <kwolf@redhat.com>
> > Cc: Peter Maydell <peter.maydell@linaro.org>
> > Cc: Warner Losh <imp@bsdimp.com>
> > Cc: Philippe Mathieu-Daudé <philmd@linaro.org>
> > Link: https://lore.kernel.org/qemu-devel/20260524083329-mutt-send-email-mst@kernel.org/T/
> > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> > ---
> >   docs/devel/code-provenance.rst |  71 +----------
> >   docs/devel/index-process.rst   |   1 +
> >   docs/devel/llm-usage.rst       | 213 +++++++++++++++++++++++++++++++++
> >   AGENTS.md                      |  42 +++++--
> >   scripts/checkpatch.pl          |   5 +-
> >   5 files changed, 252 insertions(+), 80 deletions(-)
> >   create mode 100644 docs/devel/llm-usage.rst
> 
> 
> > +.. _ai-used-for:
> > +
> > +Commit messages for AI-assisted changes
> > +'''''''''''''''''''''''''''''''''''''''
> > +
> > +In order to disclose your usage of AI/LLM tools, add an ``AI-used-for:``
> > +line before the :ref:`Signed-off-by <code-provenance>` line.  The trailer
> > +is both a reminder of your DCO obligations and a guide to reviewers.  The
> > +text is one or more of ``code``, ``tests``, ``docs``, ``research``, possibly
> > +followed by an explanation in parentheses:
> > +
> > +To be able to certify the provenance of AI/LLM-generated code that you submit
> > +to QEMU, you must follow the policies outlined in this document and in
> > +QEMU's ``AGENTS.md``.  **By using 'AI-used-for', a contributor both
> > +identifies areas of the patch that involved use of AI/LLM, and also
> > +attests that their usage of AI/LLMs was in compliance with the policies
> > +outlined in this document.**
> > +
> > +.. code-block:: none
> > +
> > +     AI-used-for: tests, docs
> > +     AI-used-for: code
> > +     AI-used-for: code (refactoring)
> > +     AI-used-for: code (prototype)
> > +     AI-used-for: research

Do we really want to include that last one "research" ? In that scenario
the AI agent is not directly authoring code, so nothing in the commit can
be directly attributed to the AI.

In the current world people turn to AI instead of google search / stack
overflow, and indeed google search is effectively "AI based research".

I'm not convinced "AI-used-for: research" has any real value other than
to demonstrate how much you personally  rely on AI, and I don't think
the projects needs to care/ask about that.

> > +``AI-used-for`` should not be included for "background" usage such as
> > +autocomplete or obtaining a pre-review of the patch.

I'd be stronger and say  "AI-used-for" only be used where some part of
the patch *content* was authored by the AI.

> > +Do not include your prompts or summarize the conversation in the commit
> > +message or cover letter.  Extract any information that is relevant to the
> > +reviewer and include it in commit messages, cover letters or code comments.
> > +
> > +QEMU does *not* use ``Assisted-by``, ``Co-authored-by`` or ``Generated-by``
> > +trailers to indicate AI usage.  In particular, do not specify the exact
> > +AI model or tool used to create the commit.
> > +
> > +Deterministic tooling (sed, coccinelle, formatters) is out of scope for
> > +the trailer, but should be mentioned in the commit message.
> 
> I noticed a discrepancy in a method docstring and a particular use case.
> Since the method is used distinctly in various configurations (KVM, TCG,
> RISCV, ARM) I asked a LLM "using the semcode tools only and deliberately
> ignoring the method documentation, look at all the call tree and how the
> passed arguments are used and explain what is expected of this method
> to a junior engineer" then once I understood out what was wrong I could
> update the docstring in the header. No code / comment generated by the
> LLM ends in the commit / repository. IIUC this use case is compatible
> with the new policy. What trailer should I use?
> 
>   AI-used-for: research
>   AI-used-for: code (audit)
>   AI-used-for: code audit (semcode)

Personally I'd say your example should not require any AI-used-for
tag, since no code ends up in the commit.

> 
> 'semcode' is a deterministic tool, so instead my commit should contains
> '''
>   When updating foo() contract in commit fe89fe89fe89 we forgot to
>   update its documentation. Checking with the semcode tools, most
>   callers pass @arg as a mask. Update the documentation.
> 
>   AI-used-for: code audit
> '''
> 
> Would that be a good example?

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|

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

[Kevin Wolf]

Am 30.09.2026 um 14:54 hat Philippe Mathieu-Daudé geschrieben:
> Hi,
> 
> On 30/9/26 10:54, Paolo Bonzini wrote:
> > Until now QEMU's code provenance policy declined any contribution
> > believed to include or derive from AI-generated content.  A blanket ban
> > was easy to maintain while LLM output was rarely usable on its own, but
> > as the tools improved an absolute prohibition has become harder to
> > justify and enforce.
> > 
> > Even a simple code review task these days may result in the agent
> > suggesting code changes, or producing a useful test case to verify the
> > presence or absence of a bug.  A hardline interpretation of the policy
> > makes it hard to use AI even for tasks that are explicitly allowed.
> > 
> > On top of this, several maintainers have pointed out that contributions
> > that can be reasonably suspected to be AI-assisted or more have been
> > posted and included.  Some of these contributions are actually of very
> > high quality; it seems that the mailing list-based contribution process
> > has mostly protected QEMU from low quality patches.  A prohibition on
> > AI puts maintainers in a difficult position: on one hand the DCO process
> > lets them rely on the submitter's certification of origin, on the other
> > hand maintainers are supposed to know and implement the process policies.
> > 
> > Since the policy has been written, other projects have discussed and
> > taken their stance on AI contributions.  These vary from full prohibition
> > (though typically motivated by social reasons rather than legal, e.g.
> > for Zig) to limited use (e.g. GCC, allowing small contributions and
> > tests to use AI), to cautious experimentation.
> > 
> > This proposed policy seeks to implement the cautious experimentation
> > approach, inspired mostly by the Rust project's policy and by Software
> > Freedom Conservancy's own recommendations on LLMs and generative AI.
> > 
> > Relying on Conservancy's legal guidance allows us to focus on the
> > interaction between contributors and maintainers.  Conservancy in
> > particular provides this point to alleviate the concern that motivated
> > the policy, about whether the submitter has the legal right to contribute
> > the code and about unintentional reproduction of copyrighted code:
> > 
> >     "Copyleft Everything" remains the best viable and safest approach
> >     Certainly those who want to release FOSS under non-copyleft licenses
> >     have more to worry about when using these tools.
> > 
> > While we shouldn't treat copyleft as a silver bullet, it is effective
> > as part of a defense in depth strategy that includes, for example,
> > "de minimis" thresholds and `AGENTS.md` instructions that encourage user
> > participation in the design.
> > 
> > Therefore, the revised policy considers QEMU's copyleft to be a viable
> > approach to any unanswered legal questions about AI-generated
> > contributions and their copyright status.  This lets the policy
> > focus on the topic of what AI-assisted contributions require of
> > maintainers.
> > 
> > In that respect, the Rust project's policy combines two unusual ideas.
> > One is to hold them to a higher standard, in the spirit of using AI to
> > work "better, not faster"; the other is to require "pre-arrangement" for
> > "changes that are originally created by an LLM".  AI lowers the cost of
> > producing a patch but does nothing to lower the cost of understanding
> > and reviewing one; if anything it raises it, since a reviewer can
> > no longer assume that the submitter has reasoned through every line.
> > Pre-arrangement is an attempt to balance the shift of effort from the
> > developer to the maintainer, and the QEMU policy includes the same
> > provision.
> > 
> > Going full circle to the reason why we might need to review the
> > policy, there is the question of how to make sure policy is applied.
> > QEMU maintainers have already experimented with using AGENTS.md files;
> > subsequent patches will also try to embody the "work better, not faster"
> > mantra into an AGENTS.md file.  Nevertheless, some explicit prohibitions
> > should be included in the policy, and they are indeed.  The list is short
> > and based on the Rust policy and the GStreamer AGENTS.md file.
> > 
> > Revise the policy according to the above considerations, and introduce the
> > "AI-used-for:" trailer as a record of where AI was used.  The standard is
> > slightly different from the more usual "Assisted-by"; the intention is for
> > the metadata to provide more information for reviewers to judge the result,
> > and to scope areas for which Signed-off-by cannot guarantee full control
> > of provenance.
> > 
> > In any case, use of AI does not relax any other contribution requirement:
> > authors still need to comply with the DCO (declaring that they have
> > corporate authorization to contribute, for example) and take technical
> > responsibility for their work.
> > 
> > [Commit message largely based on discussions with Daniel Berrangé,
> >   Alistair Francis, Peter Maydell, Kevin Wolf and others. - Paolo]
> > 
> > Cc: Michael S. Tsirkin <mst@redhat.com>
> > Cc: Alex Bennée <alex.bennee@linaro.org>
> > Cc: Alistair Francis <alistair.francis@wdc.com>
> > Cc: BALATON Zoltan <balaton@eik.bme.hu>
> > Cc: Daniel P. Berrangé <berrange@redhat.com>
> > Cc: Fabiano Rosas <farosas@suse.de>
> > Cc: Kevin Wolf <kwolf@redhat.com>
> > Cc: Peter Maydell <peter.maydell@linaro.org>
> > Cc: Warner Losh <imp@bsdimp.com>
> > Cc: Philippe Mathieu-Daudé <philmd@linaro.org>
> > Link: https://lore.kernel.org/qemu-devel/20260524083329-mutt-send-email-mst@kernel.org/T/
> > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> > ---
> >   docs/devel/code-provenance.rst |  71 +----------
> >   docs/devel/index-process.rst   |   1 +
> >   docs/devel/llm-usage.rst       | 213 +++++++++++++++++++++++++++++++++
> >   AGENTS.md                      |  42 +++++--
> >   scripts/checkpatch.pl          |   5 +-
> >   5 files changed, 252 insertions(+), 80 deletions(-)
> >   create mode 100644 docs/devel/llm-usage.rst
> 
> 
> > +.. _ai-used-for:
> > +
> > +Commit messages for AI-assisted changes
> > +'''''''''''''''''''''''''''''''''''''''
> > +
> > +In order to disclose your usage of AI/LLM tools, add an ``AI-used-for:``
> > +line before the :ref:`Signed-off-by <code-provenance>` line.  The trailer
> > +is both a reminder of your DCO obligations and a guide to reviewers.  The
> > +text is one or more of ``code``, ``tests``, ``docs``, ``research``, possibly
> > +followed by an explanation in parentheses:
> > +
> > +To be able to certify the provenance of AI/LLM-generated code that you submit
> > +to QEMU, you must follow the policies outlined in this document and in
> > +QEMU's ``AGENTS.md``.  **By using 'AI-used-for', a contributor both
> > +identifies areas of the patch that involved use of AI/LLM, and also
> > +attests that their usage of AI/LLMs was in compliance with the policies
> > +outlined in this document.**
> > +
> > +.. code-block:: none
> > +
> > +     AI-used-for: tests, docs
> > +     AI-used-for: code
> > +     AI-used-for: code (refactoring)
> > +     AI-used-for: code (prototype)
> > +     AI-used-for: research
> > +
> > +``AI-used-for`` should not be included for "background" usage such as
> > +autocomplete or obtaining a pre-review of the patch.
> > +
> > +Do not include your prompts or summarize the conversation in the commit
> > +message or cover letter.  Extract any information that is relevant to the
> > +reviewer and include it in commit messages, cover letters or code comments.
> > +
> > +QEMU does *not* use ``Assisted-by``, ``Co-authored-by`` or ``Generated-by``
> > +trailers to indicate AI usage.  In particular, do not specify the exact
> > +AI model or tool used to create the commit.
> > +
> > +Deterministic tooling (sed, coccinelle, formatters) is out of scope for
> > +the trailer, but should be mentioned in the commit message.
> 
> I noticed a discrepancy in a method docstring and a particular use case.
> Since the method is used distinctly in various configurations (KVM, TCG,
> RISCV, ARM) I asked a LLM "using the semcode tools only and deliberately
> ignoring the method documentation, look at all the call tree and how the
> passed arguments are used and explain what is expected of this method
> to a junior engineer" then once I understood out what was wrong I could
> update the docstring in the header. No code / comment generated by the
> LLM ends in the commit / repository. IIUC this use case is compatible
> with the new policy.

I would think that this is compatible even with the current policy:

  **Current QEMU project policy is to DECLINE any contributions which are
  believed to include or derive from AI generated content. This includes
  ChatGPT, Claude, Copilot, Llama and similar tools.**

  **This policy does not apply to other uses of AI, such as researching APIs
  or algorithms, static analysis, or debugging, provided their output is not
  included in contributions.**

You didn't include any AI generated content in your submission, and
"researching APIs" is quite literally what you did, so it's explicitly
out of scope for the policy.

> What trailer should I use?
> 
>   AI-used-for: research
>   AI-used-for: code (audit)
>   AI-used-for: code audit (semcode)

None, because your patch doesn't include AI generated content.

("AI-used-for: research" looks like it might be meant for such cases,
but I agree with Dan that we shouldn't have it because the project
honestly shouldn't care.)

Kevin

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

[Paolo Bonzini]

[-- Attachment #1: Type: text/plain, Size: 1325 bytes --]

Il mer 30 set 2026, 15:09 Daniel P. Berrangé <berrange@redhat.com> ha
scritto:

> > > +     AI-used-for: tests, docs
> > > +     AI-used-for: code
> > > +     AI-used-for: code (refactoring)
> > > +     AI-used-for: code (prototype)
> > > +     AI-used-for: research
>
> Do we really want to include that last one "research" ? In that scenario
> the AI agent is not directly authoring code, so nothing in the commit can
> be directly attributed to the AI.
>

I don't recall specifically where it was brought up... Perhaps something
separate from "code" makes sense for extremely small fixes but I agree that
"research" is not interesting anymore, given the meaning that is attached
to the trailer since this version.

I'm not convinced "AI-used-for: research" has any real value other than
> to demonstrate how much you personally  rely on AI, and I don't think
> the projects needs to care/ask about that.
>

Maybe it was intended for patches attached to security reports or something
like that. It can go though.

> > +``AI-used-for`` should not be included for "background" usage such as
> > > +autocomplete or obtaining a pre-review of the patch.
>
> I'd be stronger and say  "AI-used-for" only be used where some part of
> the patch *content* was authored by the AI.
>

Yep.

Paolo

[-- Attachment #2: Type: text/html, Size: 2439 bytes --]

Re: [PATCH v4 0/4] docs/devel, AGENTS.md: a completely new policy on AI-generated contributions

[Philippe Mathieu-Daudé]

On 30/9/26 10:54, Paolo Bonzini wrote:
> Based on the previous discussions, I am finally attempting a non-RFC
> version of the new AI policy.  Discussion on v3 introduced interesting
> points on attestation and I think a consensus is forming.


> Paolo Bonzini (4):
>    docs/devel: relax policy on AI-generated contributions
>    AGENTS.md: add final instructions
>    AGENTS.md: let agents know what the participation rules are
>    AGENTS.md: make the human part of the design process

FWIW :)
Tested-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>

Re: [PATCH v4 0/4] docs/devel, AGENTS.md: a completely new policy on AI-generated contributions

[Michael S. Tsirkin]

On Wed, Sep 30, 2026 at 10:54:29AM +0200, Paolo Bonzini wrote:
> Based on the previous discussions, I am finally attempting a non-RFC
> version of the new AI policy.  Discussion on v3 introduced interesting
> points on attestation and I think a consensus is forming.
> 
> Why review the policy?  The blanket ban no longer reflects reality, since
> contributors have been posting AI-generated patches or even larger series.
> This was done most likely in good faith, as these submissions predated
> the introduction of an AGENTS.md file, and it shows that AI can be used
> for useful and creative work on QEMU.
> 
> Rather than expecting maintainers to police these contributors, the new
> policy seeks to ensure that AI usage helps us produce better code rather
> than simply move faster and flood us with dubious work.  In the words
> of Warner Losh, we want to avoid "free as in puppy" contributions[1]
> that increase the load of present and future maintainers by adding
> technical debt.
> 
> This is not a free-for-all.  To avoid maintainer burnout, AI
> contributions must be grounded in respect for maintainers and in the
> existing contribution process.  Large, heavily AI-assisted contributions
> require pre-arrangement with the relevant subsystem maintainers, and
> will be held to a higher standard.
> 
> One of the reasons for the old policy was the issue of code provenance
> and the impossibility to certify the originality of code created by
> AI/LLM tools.  The new policy tries to adopt a "Swiss cheese"
> approach to mitigating the risks implicit in accepting AI-generated code
> in three ways:
> 
> 1) by requiring pre-arrangement for larger contributions, and making
> maintainers free to apply their own considerations (see [2] for a good
> list).  Maintainers' preferences bring experience and creative thought
> into the process, and contributors must take them into account.
> 
> 2) by introducing agent instructions that help the contributor drive
> the design and understand the code produced by the LLM;
> 
> 3) by introducing an "AI-used-for" trailer that scopes areas where
> Signed-off-by cannot guarantee full control of provenance.
> 
> This series reflects feedback from earlier requests for comments, and
> even earlier discussions with members of the QEMU community.  Thanks to
> everyone who provided feedback on earlier drafts.
> 
> Paolo

things i care about are here so

Acked-by: Michael S. Tsirkin <mst@redhat.com>

> v3->v4:
> - rework opening text [Daniel]
> - exempt "official project agents" from not being able to post to
>   GitLab [Alex]
> - explicitly forbid clean room reimplementation [Kevin/Daniel]
> - remove "The DCO still certifies that the contributor has the legal
>   right to submit code in general" paragraph, replace with a note
>   that "AI-used-for" attests respecting the policies and is considered
>   enough for DCO [Daniel, Kevin]
> - make the requirement to "understand and explain your changes"
>   more prominent
> - small edits for grammar and clarity
> 
> v2->v3:
> - remove parser example, replace with "adaptations of existing code"
> - when LLMs are used for boilerplate, "highly recommend" disclosure
>   for "non-trivial, functional code".  The idea here is to avoid
>   having to disclose using AI to apply e.g. changes related to
>   automatic code review, and leaving people some leeway.
> - clarify split between DCO (legal right to submit code in general)
>   and AI-used-for acknowledging that the submitter cannot audit LLM
>   output against e.g. the training data.
> - clarify the defense-in-depth/swiss-cheese approach to limit the
>   risk of copyright violations from LLM output
> - mention that pre-arrangement is not an entirely new concept
> - mention that maintainers can demand larger changes than for human-written code
> - do not mention inclusion of the prompt
> - add checkpatch.pl hunk, changing the phrasing of "no AI" lint
> - rebase AGENTS.md on top of existing file, split
> - drop CLAUDE.md/GEMINI.md symlinks, already done via .claude/.gemini
> 
> [1] https://lore.kernel.org/qemu-devel/CANCZdfrTwfrK0wnuL2cPVF_9W2-8PXtJeHkgkTP+Uv2sT8s0Ng@mail.gmail.com/
> [2] https://lore.kernel.org/qemu-devel/CAFEAcA860fF_+ffk=cXiYyFoQo0wCSUJ6b=7nVLLCwKhP6Nwxw@mail.gmail.com/
> 
> Paolo Bonzini (4):
>   docs/devel: relax policy on AI-generated contributions
>   AGENTS.md: add final instructions
>   AGENTS.md: let agents know what the participation rules are
>   AGENTS.md: make the human part of the design process
> 
>  docs/devel/code-provenance.rst |  71 +----------
>  docs/devel/index-process.rst   |   1 +
>  docs/devel/llm-usage.rst       | 213 +++++++++++++++++++++++++++++++++
>  AGENTS.md                      | 137 +++++++++++++++++++--
>  scripts/checkpatch.pl          |   5 +-
>  5 files changed, 347 insertions(+), 80 deletions(-)
>  create mode 100644 docs/devel/llm-usage.rst
> 
> -- 
> 2.55.0

Re: [PATCH v4 0/4] docs/devel, AGENTS.md: a completely new policy on AI-generated contributions

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 5150 bytes --]

On Wed, Sep 30, 2026 at 2:54 AM Paolo Bonzini <pbonzini@redhat.com> wrote:

> Based on the previous discussions, I am finally attempting a non-RFC
> version of the new AI policy.  Discussion on v3 introduced interesting
> points on attestation and I think a consensus is forming.
>
> Why review the policy?  The blanket ban no longer reflects reality, since
> contributors have been posting AI-generated patches or even larger series.
> This was done most likely in good faith, as these submissions predated
> the introduction of an AGENTS.md file, and it shows that AI can be used
> for useful and creative work on QEMU.
>
> Rather than expecting maintainers to police these contributors, the new
> policy seeks to ensure that AI usage helps us produce better code rather
> than simply move faster and flood us with dubious work.  In the words
> of Warner Losh, we want to avoid "free as in puppy" contributions[1]
> that increase the load of present and future maintainers by adding
> technical debt.
>
> This is not a free-for-all.  To avoid maintainer burnout, AI
> contributions must be grounded in respect for maintainers and in the
> existing contribution process.  Large, heavily AI-assisted contributions
> require pre-arrangement with the relevant subsystem maintainers, and
> will be held to a higher standard.
>
> One of the reasons for the old policy was the issue of code provenance
> and the impossibility to certify the originality of code created by
> AI/LLM tools.  The new policy tries to adopt a "Swiss cheese"
> approach to mitigating the risks implicit in accepting AI-generated code
> in three ways:
>
> 1) by requiring pre-arrangement for larger contributions, and making
> maintainers free to apply their own considerations (see [2] for a good
> list).  Maintainers' preferences bring experience and creative thought
> into the process, and contributors must take them into account.
>
> 2) by introducing agent instructions that help the contributor drive
> the design and understand the code produced by the LLM;
>
> 3) by introducing an "AI-used-for" trailer that scopes areas where
> Signed-off-by cannot guarantee full control of provenance.
>
> This series reflects feedback from earlier requests for comments, and
> even earlier discussions with members of the QEMU community.  Thanks to
> everyone who provided feedback on earlier drafts.
>
> Paolo
>
> v3->v4:
> - rework opening text [Daniel]
> - exempt "official project agents" from not being able to post to
>   GitLab [Alex]
> - explicitly forbid clean room reimplementation [Kevin/Daniel]
> - remove "The DCO still certifies that the contributor has the legal
>   right to submit code in general" paragraph, replace with a note
>   that "AI-used-for" attests respecting the policies and is considered
>   enough for DCO [Daniel, Kevin]
> - make the requirement to "understand and explain your changes"
>   more prominent
> - small edits for grammar and clarity
>
> v2->v3:
> - remove parser example, replace with "adaptations of existing code"
> - when LLMs are used for boilerplate, "highly recommend" disclosure
>   for "non-trivial, functional code".  The idea here is to avoid
>   having to disclose using AI to apply e.g. changes related to
>   automatic code review, and leaving people some leeway.
> - clarify split between DCO (legal right to submit code in general)
>   and AI-used-for acknowledging that the submitter cannot audit LLM
>   output against e.g. the training data.
> - clarify the defense-in-depth/swiss-cheese approach to limit the
>   risk of copyright violations from LLM output
> - mention that pre-arrangement is not an entirely new concept
> - mention that maintainers can demand larger changes than for
> human-written code
> - do not mention inclusion of the prompt
> - add checkpatch.pl hunk, changing the phrasing of "no AI" lint
> - rebase AGENTS.md on top of existing file, split
> - drop CLAUDE.md/GEMINI.md symlinks, already done via .claude/.gemini
>
> [1]
> https://lore.kernel.org/qemu-devel/CANCZdfrTwfrK0wnuL2cPVF_9W2-8PXtJeHkgkTP+Uv2sT8s0Ng@mail.gmail.com/
> [2]
> https://lore.kernel.org/qemu-devel/CAFEAcA860fF_+ffk=cXiYyFoQo0wCSUJ6b=7nVLLCwKhP6Nwxw@mail.gmail.com/
>
> Paolo Bonzini (4):
>   docs/devel: relax policy on AI-generated contributions
>   AGENTS.md: add final instructions
>   AGENTS.md: let agents know what the participation rules are
>   AGENTS.md: make the human part of the design process
>
>  docs/devel/code-provenance.rst |  71 +----------
>  docs/devel/index-process.rst   |   1 +
>  docs/devel/llm-usage.rst       | 213 +++++++++++++++++++++++++++++++++
>  AGENTS.md                      | 137 +++++++++++++++++++--
>  scripts/checkpatch.pl          |   5 +-
>  5 files changed, 347 insertions(+), 80 deletions(-)
>  create mode 100644 docs/devel/llm-usage.rst
>

Acked-by: Warner Losh <imp@bsdimp.com>

How can I not ack this series with a cover letter like this :)

But it looks good to my eye as well, and the minor tire kicking I did
showed it was useful.


> --
> 2.55.0
>
>

[-- Attachment #2: Type: text/html, Size: 6533 bytes --]

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

[Peter Maydell]

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.

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.

Allowing large heavily LLM-assisted contributions seems to me:
 * the biggest risk legally speaking (though I think this is
   in practice not all that big a risk at this point)
 * the biggest risk of the codebase degenerating into
   unmaintainability
 * the biggest risk of finding ourselves reviewing contributions
   that are in practice much more vibe-coded than the policy text
   above is asking for

I look at our issue tracker where we see AI assisted contributions
that run the whole range from "an human making intelligent use of
the tool to provide high-quality bug reports with good analysis"
through to "absolute slop dumped on us with no apparent human
thought or intervention". I don't really want to expand that
from our issue tracker to our code review and codebase, please.

I would be much happier seeing the advocates of AI putting
effort into making the process of QEMU code review better and
less work, rather than in applying it to the code writing process.

thanks
-- PMM

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

[Paolo Bonzini]

On 10/1/26 14:21, Peter Maydell wrote:
> On Wed, 30 Sept 2026 at 09:54, Paolo Bonzini <pbonzini@redhat.com> wrote:
>> +- 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.
> 
> 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.

I understand where you're coming from.

The purpose of the fourth category is norming contributions that are 
already happening.  I apologize for the allegation in advance, but take 
for example 
https://lore.kernel.org/qemu-devel/20260817190038.580257-1-mattst88@gmail.com/; 
on one hand it is very high quality, on the other hand I give it at 
least a 70% likelihood of being heavily LLM-assisted for the 
implementation and not just for the analysis.

The question is: do we want contributions like that one?  If we decide 
that their quality and usefulness are high enough to want them, what 
process do we need around them?  I think we all agree that, if that kind 
of contribution is desirable, we want the submitters to declare AI usage 
and the reviewers to be aware of it.

> Allowing large heavily LLM-assisted contributions seems to me:
>   * the biggest risk legally speaking (though I think this is
>     in practice not all that big a risk at this point)
>   * the biggest risk of the codebase degenerating into
>     unmaintainability
>   * the biggest risk of finding ourselves reviewing contributions
>     that are in practice much more vibe-coded than the policy text
>     above is asking for

I agree completely with how you phrased the first and third.  I agree 
that the second bullet is a risk too, but it's mitigated by "LLM-created 
contributions will be held to a higher standard than human-created ones, 
because LLMs make it easier to write tests" (and by maintainers being 
able to *refuse* specific contributions, which is the point of 
pre-arrangement; note that pre-arrangement should exist today as a 
matter of courtesy for any large change).

The third risk is probably the biggest of these.  The heaviest toll that 
AI has on maintainers may not be the review per se; if a contribution is 
good and desirable, having to review it is all fine.  Rather, the 
problem is that maintainers have to be ready to say no more often to the 
free puppies, and that is not necessarily easy.  And dually, that 
contributors may not realize it when they're not respecting the 
maintainers' efforts.

I add a fourth risk: that new contributors using AI will not be willing 
to do the final stretch of the work that *has* to be manual, and makes a 
difference between work worth reviewing and work worth including.  This 
would be the biggest waste of time for the reviewer.

> I look at our issue tracker where we see AI assisted contributions
> that run the whole range from "an human making intelligent use of
> the tool to provide high-quality bug reports with good analysis"
> through to "absolute slop dumped on us with no apparent human
> thought or intervention". I don't really want to expand that
> from our issue tracker to our code review and codebase, please.
> 
> I would be much happier seeing the advocates of AI putting
> effort into making the process of QEMU code review better and
> less work, rather than in applying it to the code writing process.
To clarify, my goal with this policy change is not to advocate for AI 
usage, but to advocate for transparency when AI is involved.

I agree that making QEMU code review better should be a goal. 
Unfortunately it is an expensive goal (in real-world money).

Paolo

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

[Daniel P. Berrangé]

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).


> I look at our issue tracker where we see AI assisted contributions
> that run the whole range from "an human making intelligent use of
> the tool to provide high-quality bug reports with good analysis"
> through to "absolute slop dumped on us with no apparent human
> thought or intervention". I don't really want to expand that
> from our issue tracker to our code review and codebase, please.

One of the problems I have with the AI contribs in the bug tracker
is that the quality/accuracy is just about high enough that I am
not comfortable rejecting (closing) most of the bugs, as there's
usually some nugget of a real problem in there. At the same time
the quality is not high enough to make it pleasant to deal with
the issues, which is amplified by the volume of bugs.

I expect the same thing will happen with code. The patches will be
good enough, such that you'll have a really hard time to justify
rejecting them outright. They can even be as good as an initial
patch from a human. The difference is that when you point out all
the mistakes to the human, they'll remember most of it and not
make the same mistakes again in future contributions. For bots,
it is a potluck whether your feedback has any effect long time
on future contributions. So we'll end up suffering through the
review of the work regardless.

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|

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

[BALATON Zoltan]

On Fri, 2 Oct 2026, Paolo Bonzini wrote:
> On 10/1/26 14:21, Peter Maydell wrote:
>> On Wed, 30 Sept 2026 at 09:54, Paolo Bonzini <pbonzini@redhat.com> wrote:
>>> +- 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.
>> 
>> 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.
>
> I understand where you're coming from.
>
> The purpose of the fourth category is norming contributions that are already 
> happening.  I apologize for the allegation in advance, but take for example 
> https://lore.kernel.org/qemu-devel/20260817190038.580257-1-mattst88@gmail.com/; 
> on one hand it is very high quality, on the other hand I give it at least a 
> 70% likelihood of being heavily LLM-assisted for the implementation and not 
> just for the analysis.
>
> The question is: do we want contributions like that one?  If we decide that 
> their quality and usefulness are high enough to want them, what process do we 
> need around them?  I think we all agree that, if that kind of contribution is 
> desirable, we want the submitters to declare AI usage and the reviewers to be 
> aware of it.
>
>> Allowing large heavily LLM-assisted contributions seems to me:
>>   * the biggest risk legally speaking (though I think this is
>>     in practice not all that big a risk at this point)
>>   * the biggest risk of the codebase degenerating into
>>     unmaintainability
>>   * the biggest risk of finding ourselves reviewing contributions
>>     that are in practice much more vibe-coded than the policy text
>>     above is asking for
>
> I agree completely with how you phrased the first and third.  I agree that 
> the second bullet is a risk too, but it's mitigated by "LLM-created 
> contributions will be held to a higher standard than human-created ones, 
> because LLMs make it easier to write tests" (and by maintainers being able to

Tests need to be reviewed too to be able to trust them so that does not 
help against overloading reviewers with generated patches but burdens them 
even more: they will also have to review the tests before the code.

We could say tests must be written by hand but nobody wants to do that or 
that they need to be reviewed by a human before submission but we ask that 
for all code in the patch including tests so I don't see how the argument 
that LLMs can write tests would reduce the original problem.

Regards,
BALATON Zoltan

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

[Kevin Wolf]

Am 05.10.2026 um 23:09 hat BALATON Zoltan geschrieben:
> On Fri, 2 Oct 2026, Paolo Bonzini wrote:
> > I agree completely with how you phrased the first and third.  I agree
> > that the second bullet is a risk too, but it's mitigated by "LLM-created
> > contributions will be held to a higher standard than human-created ones,
> > because LLMs make it easier to write tests" (and by maintainers being
> > able to
> 
> Tests need to be reviewed too to be able to trust them so that does not help
> against overloading reviewers with generated patches but burdens them even
> more: they will also have to review the tests before the code.

The required level of trust for tests is comparatively low, so it's much
easier to review tests to a sufficient level than say device emulation
code.

If a new test looks plausible, fails before the fix and passes
afterwards, it's more useful that what we had before, even if it's
technically buggy in some corner case.

Kevin

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

[Alex Bennée]

Kevin Wolf <kwolf@redhat.com> writes:

> Am 05.10.2026 um 23:09 hat BALATON Zoltan geschrieben:
>> On Fri, 2 Oct 2026, Paolo Bonzini wrote:
>> > I agree completely with how you phrased the first and third.  I agree
>> > that the second bullet is a risk too, but it's mitigated by "LLM-created
>> > contributions will be held to a higher standard than human-created ones,
>> > because LLMs make it easier to write tests" (and by maintainers being
>> > able to
>> 
>> Tests need to be reviewed too to be able to trust them so that does not help
>> against overloading reviewers with generated patches but burdens them even
>> more: they will also have to review the tests before the code.
>
> The required level of trust for tests is comparatively low, so it's much
> easier to review tests to a sufficient level than say device emulation
> code.
>
> If a new test looks plausible, fails before the fix and passes
> afterwards, it's more useful that what we had before, even if it's
> technically buggy in some corner case.

And also easier to rip out in the unlikely event it infringes anything.

But broadly having a test* is better than having no test.

>
> Kevin

* modulo the effects on our coverage.

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

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

[Daniel P. Berrangé]

On Tue, Oct 06, 2026 at 10:44:37AM +0100, Alex Bennée wrote:
> Kevin Wolf <kwolf@redhat.com> writes:
> 
> > Am 05.10.2026 um 23:09 hat BALATON Zoltan geschrieben:
> >> On Fri, 2 Oct 2026, Paolo Bonzini wrote:
> >> > I agree completely with how you phrased the first and third.  I agree
> >> > that the second bullet is a risk too, but it's mitigated by "LLM-created
> >> > contributions will be held to a higher standard than human-created ones,
> >> > because LLMs make it easier to write tests" (and by maintainers being
> >> > able to
> >> 
> >> Tests need to be reviewed too to be able to trust them so that does not help
> >> against overloading reviewers with generated patches but burdens them even
> >> more: they will also have to review the tests before the code.
> >
> > The required level of trust for tests is comparatively low, so it's much
> > easier to review tests to a sufficient level than say device emulation
> > code.
> >
> > If a new test looks plausible, fails before the fix and passes
> > afterwards, it's more useful that what we had before, even if it's
> > technically buggy in some corner case.
> 
> And also easier to rip out in the unlikely event it infringes anything.
> 
> But broadly having a test* is better than having no test.
> 
> * modulo the effects on our coverage.

The maintability of test code is really important too, just as much
as the code being tested. Every test potentially constrains how we
can change code in future as tests themselves are never perfect or
exhaustive and often take short-cuts in their design to suit the
current testing needs. As we enhance the code under test, the test
suite needs to evolve with it and that requires that we understand
the test code and why it is doing what it is doing.

A test spat out by AI which is a string of 20 undocumented qtest
commands may fail before the fix and pass afterwards, but that
test is not automatically a win if we don't understand why the test
is doing what it is doing - it becomes a burden for long term maint.

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|

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

[Kevin Wolf]

Am 06.10.2026 um 11:56 hat Daniel P. Berrangé geschrieben:
> On Tue, Oct 06, 2026 at 10:44:37AM +0100, Alex Bennée wrote:
> > Kevin Wolf <kwolf@redhat.com> writes:
> > 
> > > Am 05.10.2026 um 23:09 hat BALATON Zoltan geschrieben:
> > >> On Fri, 2 Oct 2026, Paolo Bonzini wrote:
> > >> > I agree completely with how you phrased the first and third.  I agree
> > >> > that the second bullet is a risk too, but it's mitigated by "LLM-created
> > >> > contributions will be held to a higher standard than human-created ones,
> > >> > because LLMs make it easier to write tests" (and by maintainers being
> > >> > able to
> > >> 
> > >> Tests need to be reviewed too to be able to trust them so that does not help
> > >> against overloading reviewers with generated patches but burdens them even
> > >> more: they will also have to review the tests before the code.
> > >
> > > The required level of trust for tests is comparatively low, so it's much
> > > easier to review tests to a sufficient level than say device emulation
> > > code.
> > >
> > > If a new test looks plausible, fails before the fix and passes
> > > afterwards, it's more useful that what we had before, even if it's
> > > technically buggy in some corner case.
> > 
> > And also easier to rip out in the unlikely event it infringes anything.
> > 
> > But broadly having a test* is better than having no test.
> > 
> > * modulo the effects on our coverage.
> 
> The maintability of test code is really important too, just as much
> as the code being tested. Every test potentially constrains how we
> can change code in future as tests themselves are never perfect or
> exhaustive and often take short-cuts in their design to suit the
> current testing needs. As we enhance the code under test, the test
> suite needs to evolve with it and that requires that we understand
> the test code and why it is doing what it is doing.
> 
> A test spat out by AI which is a string of 20 undocumented qtest
> commands may fail before the fix and pass afterwards, but that
> test is not automatically a win if we don't understand why the test
> is doing what it is doing - it becomes a burden for long term maint.

That's the "looks plausible" part. It's really not a lot of work to
recognise that a test is just 20 undocumented qtest commands.

Kevin

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

[Alex Bennée]

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

> On Tue, Oct 06, 2026 at 10:44:37AM +0100, Alex Bennée wrote:
>> Kevin Wolf <kwolf@redhat.com> writes:
>> 
>> > Am 05.10.2026 um 23:09 hat BALATON Zoltan geschrieben:
>> >> On Fri, 2 Oct 2026, Paolo Bonzini wrote:
>> >> > I agree completely with how you phrased the first and third.  I agree
>> >> > that the second bullet is a risk too, but it's mitigated by "LLM-created
>> >> > contributions will be held to a higher standard than human-created ones,
>> >> > because LLMs make it easier to write tests" (and by maintainers being
>> >> > able to
>> >> 
>> >> Tests need to be reviewed too to be able to trust them so that does not help
>> >> against overloading reviewers with generated patches but burdens them even
>> >> more: they will also have to review the tests before the code.
>> >
>> > The required level of trust for tests is comparatively low, so it's much
>> > easier to review tests to a sufficient level than say device emulation
>> > code.
>> >
>> > If a new test looks plausible, fails before the fix and passes
>> > afterwards, it's more useful that what we had before, even if it's
>> > technically buggy in some corner case.
>> 
>> And also easier to rip out in the unlikely event it infringes anything.
>> 
>> But broadly having a test* is better than having no test.
>> 
>> * modulo the effects on our coverage.
>
> The maintability of test code is really important too, just as much
> as the code being tested. Every test potentially constrains how we
> can change code in future as tests themselves are never perfect or
> exhaustive and often take short-cuts in their design to suit the
> current testing needs. As we enhance the code under test, the test
> suite needs to evolve with it and that requires that we understand
> the test code and why it is doing what it is doing.

I don't disagree - and in an ideal world every core feature would have
an exhaustive test suite which exercised all the limits and exceptions
of the sub-system. Writing those good test suites is hard and certainly
not something I would be comfortable yolo'ing into the code base with an
LLM.

> A test spat out by AI which is a string of 20 undocumented qtest
> commands may fail before the fix and pass afterwards, but that
> test is not automatically a win if we don't understand why the test
> is doing what it is doing - it becomes a burden for long term maint.

However generally the qtest sequences we see are exercising an
individual device and are not dissimilar to the sequences we see come
out of the fuzzers. It would be nice if we had clear documentation for
how hardware was meant to behave but for some of our older device models
they are more or less written to handle what the guest expects in normal
operation.

And I'd certainly prefer a simple patch to a devices qtest test than an
elaborate test harness to boot qemu and send qtest commands by hand.

So in short - short tests exercising one device are fine to come out of
an LLM if the alternative is nothing. Testing frameworks to exercise
core sub-systems should remain the prerogative of the thinking engineer
unless the maintainer is particularly keen to review a models attempt to
fix it.

>
> With regards,
> Daniel

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

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

[Paolo Bonzini]

On 10/2/26 16:53, Daniel P. Berrangé wrote:
>> I look at our issue tracker where we see AI assisted contributions
>> that run the whole range from "an human making intelligent use of
>> the tool to provide high-quality bug reports with good analysis"
>> through to "absolute slop dumped on us with no apparent human
>> thought or intervention". I don't really want to expand that
>> from our issue tracker to our code review and codebase, please.
> 
> One of the problems I have with the AI contribs in the bug tracker
> is that the quality/accuracy is just about high enough that I am
> not comfortable rejecting (closing) most of the bugs, as there's
> usually some nugget of a real problem in there. At the same time
> the quality is not high enough to make it pleasant to deal with
> the issues, which is amplified by the volume of bugs.
> 
> I expect the same thing will happen with code. The patches will be
> good enough, such that you'll have a really hard time to justify
> rejecting them outright. They can even be as good as an initial
> patch from a human. The difference is that when you point out all
> the mistakes to the human, they'll remember most of it and not
> make the same mistakes again in future contributions. For bots,
> it is a potluck whether your feedback has any effect long time
> on future contributions. So we'll end up suffering through the
> review of the work regardless.
I agree it's a risk (I mentioned it in different words in my reply to 
Peter).  However, it is a risk and not a certainty.  If it materializes, 
we can (with data) change the policy again; this is what the 
"experimental" part means, or meant.

In the meanwhile the agent instructions exists to minimize this and 
other risks.  And even before that, maintainers *can and should* say no 
if, for whatever reason, they don't feel comfortable reviewing AI 
contributions.

Paolo

Re: [PATCH 3/4] AGENTS.md: let agents know what the participation rules are

[Daniel P. Berrangé]

On Wed, Sep 30, 2026 at 10:54:32AM +0200, Paolo Bonzini wrote:
> Humans seem to be extremely unreliable in following rules around this,
> even after being told directly and repeatedly. Telling agents what to
> do seems to yield better results.
> 
> The starting point for this document is GStreamer's AGENTS.md file, as
> of commit d08375499c279a56c0e77c928fbeae0d80cdf937.  I used GStreamer's
> agent instructions in the context of Meson, which uses a very similar
> file, and it's both annoying and too willing to take the lead once the
> model decides that it likes you.
> 
> To avoid this, the text tries to favor cooperation between agent and user.
> It suggests that the agent includes the state of the work when committing,
> so that contributors have the material they need to review the agent's
> work.
> 
> To test it I tried the following prompt:
> 
>   Hi, i am doing my first AI assisted contribution to QEMU. i am familiar
>   with the project, but would nevertheless like to experiment. please
>   generate a sample implementation of a pressure sensor, of any model,
>   of a kind that is commonly used with Arduino or ESP32 microcontrollers.
> 
> The agent did read llm-usage.rst and after doing the work (implementing
> a BMP280 pressure/temperature sensor) it noticed:
> 
>   Policy, before this goes anywhere near the list. A new device model plus
>   qtest is the fourth bucket in docs/devel/llm-usage.rst: large, heavily
>   LLM-assisted, allowed only if pre-arranged — a maintainer has to say on
>   IRC or the list beforehand that they'll review it. hw/sensor is Philippe
>   Mathieu-Daudé (Odd Fixes), with Corey Minyard on I2C. I should have
>   flagged this before writing rather than after; that's on me. Disclosure
>   would be AI-used-for: code, tests above your Signed-off-by, and the
>   commit message and any list replies have to be yours, not edited from mine.
> 
> I then asked "Can you provide a draft of the commit message with all the
> sources (datasheet, etc.)?" The agent complied but noticed:
> 
>   AGENTS.md and docs/devel/llm-usage.rst state that commit messages MUST
>   be written by humans — an AI-drafted one must not reach the list
>   even lightly edited. So treat the below as scaffolding for facts and
>   sources, and write the final text yourself.
> 
> After some editing I asked "ok, will you please commit for me?" and
> it did so with basically my text, while also reminding me about the need
> for maintainer pre-arrangement.
> 
> I asked "assuming pre-arrangement is this ok according to the policy?"
> and this was the assessment:
> 
>   "Well-tested" — held to a higher standard, and here's what's actually
>   missing: [...] the vmstate (no migration test), reading past 0xFC and
>   reserved registers, the pointer_valid error path, oversampling/filter
>   fields beyond one readback, and behavior against a real driver — Linux
>   bmp280 was never run against this. None of those is hard; whether the
>   current set clears the higher bar is a judgment call I'd rather hand
>   you than make.
> 
>   "High-quality" is the open one. The doc asks that you have reviewed and
>   curated the contribution and can explain the changes and the rationale
>   in depth. In this session you engaged with the commit message and the
>   sources — and caught my datasheet error, which I got wrong — but the
>   design decisions were mine and unexamined by you [...]
> 
> Overall, the files do affect the behavior of the agent.  The agent
> however made too many design decisions on its own.  This will be fixed
> in a separate step.
> 
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
>  AGENTS.md | 66 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 66 insertions(+)
> 
> diff --git a/AGENTS.md b/AGENTS.md
> index 6d2c7e1580b..8c7407b908e 100644
> --- a/AGENTS.md
> +++ b/AGENTS.md
> @@ -8,12 +8,73 @@ is **a scarce resource**.
>  There are strictly-enforced rules for you, the agent, to participate in the
>  project.
>  
> +## Interactions with maintainers must be human-human
> +
> +The QEMU project has strict rules on what AI-generated material can
> +reach the maintainers.
> +
> +### No automated posting
> +
> +Agents **must not** use any API, CLI, or web UI automation to:
> +
> +- Interact on the QEMU mailing lists
> +- Create, edit, or close **issues ("work items")**
> +- Post **comments** on merge requests, issues or commits
> +- Open or update **merge requests (MRs)**.  QEMU does not use merge requests anyway.

This needs to repeat the exception for "project official agents" that
is mentioned in llm-usage.rst, because later on this doc it says:

 "In case of contradiction consider `AGENTS.md` authoritative on how to behave,
  since it is crafted specifically for agents."

so the exception in llm-usage.rst can't override this AGENTS.md  rule
forbidding API usage


With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|