Our AI policy vs code of conduct and vs reality

[rnk]

Since this thread started, I filled out the LLVM dev meeting roundtable form and proposed a round table on this topic. I know not everyone participating on this thread is going, but it will be another opportunity to discuss this further in a month, take notes, and post those results.

To summarize feedback I’m getting so far:

• Multiple folks have asked me to be more concise. I don’t want to drop the rationale, but I want to lead with concise, practical process steps that help maintainers stop slop, because we have problems right now.
• Several folks want to ban these tools full stop, but there is a sizeable contingent that wants something moderate, but practically defensible.
• Tie the new policy back to the general quality bar.

Here I’m using “slop” to mean “unwanted AI-generated content” as defined by Simon Willison. I’m starting to think it would be more practical to phrase this as an anti-slop policy. The word “unwanted” here does the work of capturing our subjective judgements on the value of a contribution.

@JonChesterfield

It is an exciting new world. I hadn’t realised people were feeding responses to comments through llms, or that engineers were writing internal emails through them. That seems absurd to me.

LLMs are very good at corp-speak, so yes, I have heard of engineers using them to write internal emails for management.

@JonChesterfield

I rely heavily on the coherency of prose as a proxy for the coherency of thought behind it. That heuristic is dead under this model. I don’t know how to adapt to a setting where both code and discussion are coherently written nonsense.

Does anyone have advice for how to work on this project under the llm model?

These are tough questions. We do live in a new world.

@slinder1

To clarify I’m most concerned about the pattern of someone simply proxying review concerns through the same LLM they used to write code they don’t understand. I think we should do all we reasonably can to avoid reviewers wasting their limited time interacting almost directly with an LLM without their consent.

This is exactly the kind of behavior the policy draft is meant to prevent. If someone uploads slop, gets a warning, and responds to the warning with more slop, we should lock the PR.

@slinder1

A good commit message largely regurgitates what the patch already does. A great commit message gives you the context for why it does what it does. Part of that context may include the tools used to create it, why they were chosen, tradeoffs, etc.

Scott’s point is broader than what I quoted above, but I agree I would like to encourage folks to share prompts for large changes, and share the kinds of concerns. There’s tons of prior art for pasting sed scripts into commit messages used to rewrite LLVM IR test cases, or invocations of Python scripts committed to the repo indicating how mass edits were performed. Our existing developer policy on commit message writing asks the contributor to emphasize the why of the change.

@klausler

How would a contributor of LLM-generated code be able to know that the code was not the result of training on codebases from which code copying would be unacceptable?

I think the copyright aspect of the policy is somewhat obsolete at this point. I wrote it in an earlier era when LLMs would splat out comments from original Doom source code (or at least I had that in mind, I was probably already behind the state of the art). Most of the LLMs use recitation checkers these days to avoid obvious instances of reproducing content from their training sets, so the point is kind of moot. There are deeper questions here about copyright and IP, but you’ll have to talk to legal counsel about that.

The most important part of the policy is what the project will do when someone identifies copyright infringement, which is that we’ll remove the infringing content, and that’s a pretty unsurprising outcome.