When AI Starts Flooding Projects with Pull Requests

Introduction

AI coding tools have made it easier for newcomers to inspect unfamiliar repositories and propose changes. They have also made it easier to produce contributions that look substantial without requiring the contributor to understand the project deeply. Neil Alexander, a maintainer of an open-source project, has publicly criticized people who use AI to generate low-value pull requests, issues, and security reports mainly to strengthen their résumés.

His complaint is not a rejection of AI-assisted development. The problem is what happens when generated material is submitted without being checked, tested, or understood by the person who opened the contribution.

A noticeable change in contribution patterns

According to Alexander’s observations, the last year has brought several changes in how external contributors interact with the project:

• Pull requests now appear far more often than issues;
• issues frequently include elaborate AI-generated analysis;
• security reports have become more common;
• those reports often arrive with AI-generated repair suggestions;
• some submissions appear optimized for leaving a visible contribution record rather than solving a confirmed problem.

None of these signs proves that a contribution is useless. AI can help locate relevant code, summarize unfamiliar logic, organize reproduction steps, and suggest possible fixes. The difficulty begins when those suggestions are treated as finished work. A generated patch that has not been run or reviewed does not reduce the maintainer’s workload. It creates another item that must be triaged from the beginning.

Why polished output can still be harmful

Open-source work depends on context. A security report may overlook an existing safeguard. A proposed fix may conflict with compatibility requirements. A refactoring patch may be technically valid but inconsistent with the project’s design or maintenance priorities.

Maintainers therefore have to determine whether the reported problem is real, whether the change is necessary, whether the tests are adequate, and whether the patch fits the project. If AI-generated submissions arrive in large numbers, maintainers are effectively asked to perform the basic investigation that the contributor should have completed first.

That cost matters particularly in volunteer-led projects. A contribution is not free simply because the contributor can generate it quickly. Review time, follow-up questions, testing, and possible regression analysis all remain part of the project’s workload.

There is also an incentive problem. If the number of pull requests becomes a proxy for skill, contributors may optimize for submission volume instead of usefulness. The project then becomes a source of résumé entries, while maintainers become an unpaid filtering layer for automated output.

What responsible AI-assisted contribution looks like

Using AI is not automatically a sign of poor contribution. A healthier standard is to treat AI as an assistant, not as a way to transfer responsibility. Contributors should be able to reproduce the reported issue, explain why the change is needed, describe what the patch does, and report which tests they actually ran. If AI played a substantial role, transparency about that assistance can also make later communication more efficient.

Projects can respond with clearer contribution guidelines, pull-request templates, and security-reporting procedures. Requiring reproduction steps, test results, affected versions, and manual verification will make low-context submissions easier to identify. Maintainers should also feel free to close repetitive or unverifiable contributions; keeping a project open does not mean accepting every generated artifact.

The broader question is not whether open source should allow AI. It is whether contributions still rest on understanding, verification, and accountability. AI can help more people enter open source, but generated text does not become valuable collaboration automatically. A smaller number of carefully checked contributions will usually demonstrate more skill than a large collection of unverified patches.

Source: OSChina