[Nav2] Poll on thoughts of AI bots / copy+paste jobs in repository interactions

Community Groups Navigation
1

Hi all, Your Friendly (to humans) Neighborhood Navigator here

Over the past couple of months, I’ve become inundated with PRs from AI agents and/or users which are copy pasting AI outputs in PR descriptions, code blocks, and so forth. Some seem reasonable on the surface, but others will make subtle changes deep in the code to fix issues that no human would run into and requires hours of careful work on my part. This has reached a near breaking point trying to support the user community to contribute back patches, fixes, their research, and other improvements to the stack.

I’ve recently started to deprioritize or outright close PRs/Issues that are clearly the result of AI (agentic or just copy+paste job) as a virtual non-report to make time for the actual humans that want to participate in the community. The reports are frequently frivolous, their fixes are wrong and time consuming to review, and frankly if the human attached to them can’t bother to do some QA or write up their own thoughts on the matter then why should maintainers waste their time either.

I’m pro- use of AI for where AI is useful, but offloading the entire act of thinking to AI is not good discipline and causes issues for open-source maintainers.

Before I changed some official policy decisions, I wanted to get a sense of what people are feeling about this. If you’d fill in this poll, I’d appreciate it.

You should treat PRs / Issues from AI…

  • As you would any human’s request, no matter the time/cost
  • As humans, until it becomes unreasonable or if the quality or size is unreasonable
  • Outright reject on grounds, if users cannot spend time to QA, why should we?
0 voters

If you have other suggestions, comment below.

Thanks.

Steve

5 Likes
2

I think we are in the process of reinventing software engineering in the new context of AI. Trying to apply the same mechanisms that were designed for human workflows to AI agents is clearly not working – Linux Torvalds has been saying very similar things to what you described.

I voted for the last option (reject if no human did QA) and my justification is simple: anyone who wants it another way can certainly fork and extend at-will, using AI or whatever means they choose. I think the question to ask is:

What’s the value of AI generated code/changes if that same AI is available to everyone?

I think this is really the question that should drive policy decisions like this, and when asked this way I personally always arrive at the same answer: nothing unless a human (i.e., a resource not readily available to everyone) adds some sort of value on top of it.

People may argue that the prompt alone has value and comes from a human. This is true of course, but then that prompt needs to be part of the evaluation of the product (the PR) and it would be absolutely legitimate to reject a PR that is based on a prompt which doesn’t, in itself, provide much value. I believe much stronger values would come from human-QA, as you pointed out.

Now, some people really want to be named “contributors” to an open-source project – something they want to add to their resumes. But people need to recognize that such line-items on a resume lose all value if “anyone can do it”, and trying to cheat on the implicit Turing test of “was this PR created/authored by a human or AI?” is not going to help their reputation.

In sum, perhaps, a caveat is in order: If PRs clearly state which aspect came from AI and how it was prompted and what context and perhaps QA-test facilities were provided and verified, then it might be worth reviewing them.

But my real suggestion to prospective contributors is different: DON’T try to contribute functional code, but DO contribute AI automation code. Meaning: help design the software engineering setup of the future involving AI agents. For instance:

  • Contribute closed-loop engineering and test setups that AI agents can execute.
  • Contribute minimum viable code examples to reproduce bugs you found (with or without AI).

The history of intelligence is one of “going meta”: building models, over models, over models, … In times of AI, we need to understand how AI works (at least to some degree) and how we can use it, not become submissive to it and just “do as it says” (which is the behavior displayed by PR authors who don’t bother understanding their submissions).

(Sorry, this got long.)

3 Likes
3

You just opened Pandora’s Box @smac :slight_smile:

Vibe coded junk - reject to ground and even blacklist the committer.

Having said that, AI is a part of our life now. Its great while handling syntax, styling thoughts, doing straight forward tasks like maintaining CMakeLists.txt, package.xml etc. But when it comes to core algorithms, doing real engineering; if someone is committing a huge chunk of code with tons of comments in it; I’d lean towards rejecting it.

Anything submitted by a human or AI, should be right on point, as concise as possible. If someone is creating a PR and their head is not aching, then it should not be PR at all. I do support AI as a tool, no different than an IDE.

1 Like
4

Just to add some “industry wide” flavor to this discussion, a friend of mine sent me this PyCon 2026 talk from this weekend titled, “AI-Assisted Contributions and Maintainer Load”.

I found this particular slide to strike a happy-medium on opinions on the issue. Hopefully the video will be out in the next week or two.

image
image763×452 42.9 KB

6 Likes