Add "no AI agents" etc. to CONTRIBUTING.md

[samsrabin]

Our Code of Conduct is here but I'm not sure to what extent we can edit that; it seems like a UCAR-mandated thing.

[ekluzek]

Yes, the Code of Conduct (COC) isn't the right place for this. The COC is more on behavior rules on how we interact and treat each other.

The CONTRIBUTING.md file is the right place for this.

[ekluzek]

Sample text that FATES is considering is:

https://github.com/NGEET/fates/pull/1549/files#diff-eca12c0a30e25b4b46522ebf89465a03ba72a03f540796c979137931d8f92055

[ekluzek]

@linniahawkins and @AyaLahlou we want to make sure the text we add here doesn't prevent work like Aya is doing with TransJAX. Aya is doing brilliant work collaborating with people in CESM/CTSM and using the AI as a tool in a highly supervised way. So the contributions aren't just AI agents running amuck, but it's a unique contribution from Aya the human herself. We are adding this language, because we had someone create AI agents that submitted issues and PR's all across ESCOMP repositories, but because it was all AI and little from the human -- it was a detriment rather than a value. So we ended up blocking them in ESCOMP.

So we want to prevent that sort of work, while encouraging the type of work that Aya is doing. And we want to make sure we communicate that well. So we'd love to hear feedback from you both on getting the text right for this purpose.

[linniahawkins]

Hi Erik, thanks for being so thoughtful about the language here. I took a look at the proposed FATES language and it reads to me that LLMs/agents shouldn't be "used to submit pull requests, issues, discussion items". To me, this does not exclude code written with an LLM/agent to be submitted within the PR by a human, is that what's intended? If so, then I think this wording works well.

[ekluzek]

Hi Erik, thanks for being so thoughtful about the language here. I took a look at the proposed FATES language and it reads to me that LLMs/agents shouldn't be "used to submit pull requests, issues, discussion items". To me, this does not exclude code written with an LLM/agent to be submitted within the PR by a human, is that what's intended? If so, then I think this wording works well.

Yes, I think that's well said. In terms of pull requests, issues, and discussion items, we want to make sure we are talking with the human and NOT an AI. There's a thing in the media where an AI submitted to a big project and it was respectfully rejected by the humans -- and the AI responded aggressively (see: https://theshamblog.com/an-ai-agent-published-a-hit-piece-on-me/ for example).

Good code that was written with the help of an LLM/agent can and will be brought in, but we really don't want to waste time arguing with an AI agent.

There are also other reasons to reject code from an AI that's sloppy, and we should add some language around that as well. That might be harder to define though...

[AyaLahlou]

Hi @ekluzek , thanks so much for your consideration here! I agree with @linniahawkins, as long as the restrictions only apply to Github-facing actions, it won't affect my workflow: the AI commits and pushes only to my personal development branch, and I always review the output before submitting a PR myself.
I fully share the concern, though. We do not want AI flooding a project with noise or arguing back 😄 The linked story is unsettling!

[samsrabin]

This is the text that Erik linked above:

Use of AI Agents

AI agents should not be used to submit pull requests, issues, discussion items or other features available on the developer platforms on which the FATES model is officially hosted (i.e. Github), except on a case-by-case basis. Approval to do so should be sought from a core member of the FATES development team. Unapproved submissions will be closed. Repeated unapproved submissions may culminate in the blocking of the submitting user.

I don't think "except on a case-by-case basis" or the request for approval bit make sense to include. Creating a pull request is the easy part; if a person can't do that, there's a different problem that an AI agent won't solve.

At the same time, I'm also not sure that banning agent-submitted issues/PRs is either (a) enforceable, (b) going to have literally any effect, or (c) actually solving the problem even if it did have an effect.

It's not enforceable, really, because unless the issue/PR includes "submitted by [agent]" or similar we won't be able to know one way or the other.

I'm not sure it'd have any effect because I don't think someone doing these drive-by PRs is going to read CONTRIBUTING.md—the whole point is they're just spraying repos willy-nilly.

And if it did make such people write their issues/PRs manually, I'm not sure it'd solve the problem. Because the problem isn't with agent-submitted issues/PRs per se; the problem is with sloppy submissions that we never asked for. Indeed, we've had this problem long before AI tools became common—someone we've never heard of submits a PR for a feature they want, and we have to say, "sorry, the way you've done this is all wrong, please start over with this better structure."

Maybe something like this:

The CTSM core development and maintenance team is small compared to the size of the codebase, user base, and contributor community. We welcome and encourage external contributions, but we request that you coordinate with us before and during development. For example: If you identify an inefficient algorithm and have an idea for a better one, please post an issue so that we can discuss, rather than submitting a PR we need to review with changes that we may not be able to accept. We also request that you submit your own issues and PRs, rather than having an AI agent do so for you—because if it's not worth your time to do that, it's probably not worth our time dealing with the submission.

We can also add an AGENTS.md file and/or whatnot with instructions that AI agents will actually look for, telling them to never submit issues or PRs but instead to prompt their user to do so. I doubt that'll be 100% effective, but I think it'd probably be more effective.