[RFC] LLVM AI tool policy: human in the loop

LLVM Project
1

Hey folks, I got a lot of feedback from various meetings on the proposed LLVM AI contribution policy, and I made some significant changes based on that feedback. The current draft proposal focuses on the idea of requiring a human in the loop who understands their contribution well enough to answer questions about it during review. The idea here is that contributors are not allowed to offload the work of validating LLM tool output to maintainers. I’ve mostly removed the Fedora policy in an effort to move from the vague notion of “owning the contribution” to a more explicit “contributors have to review their contributions and be prepared to answer questions about them”. Contributors should never find themselves in the position of saying “I don’t know, an LLM did it”. I felt the change here was significant, and deserved a new thread.

From an informal show of hands at the round table at the US LLVM developer meeting, most contributors (or at least the subset with the resources and interest in attending this round table in person) are interested in using LLM assistance to increase their productivity, and I really do want to enable them to do so, while also making sure we give maintainers a useful policy tool for pushing back against unwanted contributions.

I’ve updated the PR, and I’ve pasted the markdown below as well, but you can also view it on GitHub.

LLVM AI Tool Use Policy

Policy

LLVM’s policy is that contributors can use whatever tools they would like to
craft their contributions, but there must be a human in the loop.
Contributors must read and review all LLM-generated code or text before they
ask other project members to review it. The contributor is always the author
and is fully accountable for their contributions. Contributors should be
sufficiently confident that the contribution is high enough quality that asking
for a review is a good use of scarce maintainer time, and they should be able
to answer questions about their work during review.

We expect that new contributors will be less confident in their contributions,
and our guidance to them is to start with small contributions that they can
fully understand to build confidence. We aspire to be a welcoming community
that helps new contributors grow their expertise, but learning involves taking
small steps, getting feedback, and iterating. Passing maintainer feedback to an
LLM doesn’t help anyone grow, and does not sustain our community.

Contributors are expected to be transparent and label contributions that
contain substantial amounts of tool-generated content. Our policy on
labelling is intended to facilitate reviews, and not to track which parts of
LLVM are generated. Contributors should note tool usage in their pull request
description, commit message, or wherever authorship is normally indicated for
the work. For instance, use a commit message trailer like Assisted-by: . This transparency helps the community develop best practices
and understand the role of these new tools.

An important implication of this policy is that it bans agents that take action
in our digital spaces without human approval, such as the GitHub @claude
agent. Similarly, automated review tools that
publish comments without human review are not allowed. However, an opt-in
review tool that keeps a human in the loop is acceptable under this policy.
As another example, using an LLM to generate documentation, which a contributor
manually reviews for correctness, edits, and then posts as a PR, is an approved
use of tools under this policy.

This policy includes, but is not limited to, the following kinds of
contributions:

  • Code, usually in the form of a pull request
  • RFCs or design proposals
  • Issues or security vulnerabilities
  • Comments and feedback on pull requests

Extractive Contributions

The reason for our “human-in-the-loop” contribution policy is that processing
patches, PRs, RFCs, and comments to LLVM is not free – it takes a lot of
maintainer time and energy to review those contributions! Sending the
unreviewed output of an LLM to open source project maintainers extracts work
from them in the form of design and code review, so we call this kind of
contribution an “extractive contribution”.

Our golden rule is that a contribution should be worth more to the project
than the time it takes to review it. These ideas are captured by this quote
from the book Working in Public by Nadia Eghbal:

"When attention is being appropriated, producers need to weigh the costs and
benefits of the transaction. To assess whether the appropriation of attention
is net-positive, it’s useful to distinguish between extractive and
non-extractive contributions. Extractive contributions are those where the
marginal cost of reviewing and merging that contribution is greater than the
marginal benefit to the project’s producers. In the case of a code
contribution, it might be a pull request that’s too complex or unwieldy to
review, given the potential upside." -- Nadia Eghbal

Prior to the advent of LLMs, open source project maintainers would often review
any and all changes sent to the project simply because posting a change for
review was a sign of interest from a potential long-term contributor. While new
tools enable more development, it shifts effort from the implementor to the
reviewer, and our policy exists to ensure that we value and do not squander
maintainer time.

Reviewing changes from new contributors is part of growing the next generation
of contributors and sustaining the project. We want the LLVM project to be
welcoming and open to aspiring compiler engineers who are willing to invest
time and effort to learn and grow, because growing our contributor base and
recruiting new maintainers helps sustain the project over the long term. Being
open to contributions and liberally granting commit access
is a big part of how LLVM has grown and successfully been adopted all across
the industry. We therefore automatically post a greeting comment to pull
requests from new contributors and encourage maintainers to spend their time to
help new contributors learn.

Handling Violations

If a maintainer judges that a contribution is extractive (i.e. it doesn’t
comply with this policy), they should copy-paste the following response to
request changes, add the extractive label if applicable, and refrain from
further engagement:

This PR appears to be extractive, and requires additional justification for
why it is valuable enough to the project for us to review it. Please see
our developer policy on AI-generated contributions:
http://llvm.org/docs/AIToolPolicy.html

Other reviewers should use the label to prioritize their review time.

The best ways to make a change less extractive and more valuable are to reduce
its size or complexity or to increase its usefulness to the community. These
factors are impossible to weigh objectively, and our project policy leaves this
determination up to the maintainers of the project, i.e. those who are doing
the work of sustaining the project.

If a contributor responds but doesn’t make their change meaningfully less
extractive, maintainers should escalate to the relevant moderation or admin
team for the space (GitHub, Discourse, Discord, etc) to lock the conversation.

Copyright

Artificial intelligence systems raise many questions around copyright that have
yet to be answered. Our policy on AI tools is similar to our copyright policy:
Contributors are responsible for ensuring that they have the right to
contribute code under the terms of our license, typically meaning that either
they, their employer, or their collaborators hold the copyright. Using AI tools
to regenerate copyrighted material does not remove the copyright, and
contributors are responsible for ensuring that such material does not appear in
their contributions. Contributions found to violate this policy will be removed
just like any other offending contribution.

Examples

Here are some examples of contributions that demonstrate how to apply
the principles of this policy:

  • This PR contains a proof from Alive2, which is a strong signal of
    value and correctness.
  • This generated documentation was reviewed for correctness by a
    human before being posted.

References

Our policy was informed by experiences in other communities:

6 Likes
[RFC] LLVM AI tool policy: start small, no slop
[RFC] AI-assisted Bazel Fixer Bot
LLVM Weekly - #625, December 22nd 2025
2

Hi Reid,

I understand and generally agree with the sentiment that prompted this proposal, but I think maybe your current policy is too restrictive and you are throwing out the baby with the bathwater. In particular I can imagine cases where we might want to make exceptions to the general policy, e.g. for AI tools that are designed to handle a small, restricted, and easily automatable set of maintenance-type changes. I think this policy should include a well-defined path for obtaining exceptions to the general rule (that a human must be in the loop before a PR can be posted).

An example of such a path might be:

  • Post an RFC detailing what problem the proposed AI agent will solve and how it will solve it.

  • Get approval for the RFC

  • Have a short testing period, where humans must check their proposed changes before allowing them to be posted upstream, and must comment in the PR both that the original content came from AI, and whether or not the human needed to update the original content.

  • Final review by small committee (possibly one of the area leads teams) on whether or not the AI is generating acceptable quality PRs; grants the exception (or not).

Note that’s just a rough outline, and would probably need refinement. Just my 2 cents.

1 Like
3

Thank you, this feels like it take a lot of the feedback into account. one aspect that I don’t see covered here but I have had trouble with is that results from LLMs tend to be very very verbose. Often they feel like giant walls of text. There is important and useful information there but I have to put a lot more work into getting it. It is not that anything is necessarily incorrect or wrong but a human would have said in a few sentences and still conveyed the important information.

It feels very hard to push back on this because it feels to some degree subjective (but I know it when I see it) but if a serious amounts of reviews became that much more verbose it would be a large cost in reviewer time. I will feel highly unmotivated to review PRs/issues that are walls of text. Especially if (as I often am) making hard trade-offs on my time.

There is some degree on irony here, in that I am often pushing folks on PRs to provide more and more detailed information but as the meme’s often say “not like that”.

6 Likes
4

Not sure if it’s explicit from the current wording but I assume the intention for “human in the loop” is that the human won’t just forward questions to LLM and post its answers as if they are their own instead of just going “I don’t know, an LLM did it” either (because it’s essentially the same as the latter but wastes way more reviewer time).

5

I don’t agree with this characterization. The problem we have today is not that we have a lot of LLM-based tools we desperately need to integrate into our automation. Instead, I think the problem is that reviewers struggle with a wave of LLM output coming as contributions, where contributors don’t have enough understanding of their PRs. Policy that Reid drafted in this thread is a great step towards addressing that later problem.

We’ve been months into AI policy discussions, and I don’t think that hypothetical future LLM automation is worth delaying much needed changes any longer.

6

Yeah, agreed. If we eventually do find that we want to carve out some sort of exception for some tool, we can just update the policy at that point.

7

I don’t see why this is incompatible with that. A policy introduced by this RFC can be overridden by a future RFC, including one for a specific case that would like an exception.

2 Likes
8

While I am fully convinced that we will end up needing well-defined path for exceptions to this policy, which I why I brought it up, if everyone else would prefer to skip that for now, I can live with the policy going in as is. With the full expectation that we will need to update it in the future to define a principled way to obtain exceptions. :slight_smile:

9

I thought some more about why crafting an AI policy for an open source project is so hard, and why so many projects are struggling with it. For a large open source project like LLVM or Linux, a large share of the contributors are working at corporations – and a large majority of corporations have adopted AI coding-assistants org-wide, many of them seeing material benefits from the adoption. It would be natural to question whether the same productivity gain can be replicated in an open source project like ours. The interest in drafting a policy may also come from the perspective of being welcoming to new contributors – a lot of young people today are playing with coding-assistants prior to joining industry. My earlier position was that it wouldn’t be useful in LLVM, from personal experience, but I’m probably old-fashioned and biased.

The core issue is that the people writing code in corporations are very different from the general public – rouge entities misusing AI in corporations can be let go, but the general public is the wild west. Several open source projects are burdened with a flood of AI-generated bug reports, and huge AI-generated PRs. I think that, due to the inherent nature of this technology, it will always be a corporate thing, and is perhaps a poor fit for an open source project – I know this is somewhat defeatist, but I really don’t know what kind of safeguards will protect us and our valuable time.

1 Like