AI has made it easier to produce a patch. It has not made it easier to know whether that patch belongs in a project.
That difference matters more than the demo videos admit.
A pull request is not just a blob of code. It is a request for another human to spend attention on your idea, your assumptions, your tests, and your understanding of the project. When the code is AI-assisted, that review burden can get heavier, not lighter, because the patch may look tidy while still missing context, intent, or a quiet edge case hiding under the floorboards.
That does not make AI-assisted contributions bad. It means the standard has to shift.
The new rule should be boring and fair: if AI helped produce the patch, bring more proof with it.
The bottleneck moved from writing to verifying
For years, open source depended on the drive-by pull request. Someone hit a bug, fixed it, and sent the improvement upstream. Done well, that model is one of the best parts of software: a shared project gets better because one person scratched a real itch and left the place cleaner.
AI changes the economics. A contributor can now generate a patch, an issue, a refactor, a test suite, or a security report faster than a maintainer can evaluate it. That speed is useful when the contributor understands the work. It becomes a problem when the tool produces something plausible and the human sender has not done the verification.
That is the asymmetry: generation got cheap, but review stayed expensive.
GitHub’s own look at open source in 2026 describes the double edge clearly. AI has helped more people participate, understand codebases, and draft changes, but it has also created more noise: low-quality issues and pull requests that increase review volume without increasing project value. The painful part is not that newcomers are using tools. The painful part is that maintainers have to spend scarce time sorting useful work from confident-looking debris.
And maintainers were not exactly lounging around before this. Shocking, I know. The volunteer labor fairy remains stubbornly fictional.
The healthiest projects are not just banning AI
The better examples are not blanket anti-AI policies. They are accountability policies.
LLVM’s AI tool policy is a good model. It allows contributors to use tools, but says there must be a human in the loop. Contributors are expected to read and review generated code or text before asking someone else to review it. They remain the author. They are accountable for the work. They should be able to answer questions about it. LLVM also asks contributors to be transparent when substantial tool-generated content is involved, including with an Assisted-by: trailer when that fits the project’s workflow.
WordPress takes a similar line in its AI guidelines. AI tools are assistants, not contributors. If you submit the patch, you own the patch. WordPress asks for meaningful disclosure when AI was used, warns against large unreviewed generated code dumps, and reminds contributors that disclosure is not a negative signal. It helps reviewers understand how to evaluate the change.
That last part is important. Disclosure should not be treated like a confession booth. It should be treated like useful metadata.
A maintainer does not need theater. They need to know what they are looking at.
“AI slop” is shorthand, not a strategy
The term “AI slop” exists because people needed a label for low-quality generated material that looks more finished than it is. It can be accurate. It can also become lazy.
If every AI-assisted contribution gets dismissed as slop, the community loses useful contributors. If every generated patch gets treated as equally review-worthy, maintainers get buried. Neither path is healthy.
The better distinction is proof.
A weak AI-assisted contribution says: “Here is a patch. I think it works.”
A useful AI-assisted contribution says:
- here is the problem I reproduced;
- here is the smallest change I could make;
- here is why this approach fits the project;
- here are the tests I ran;
- here is what I did not verify;
- here is where AI helped;
- here is why this is worth maintainer time.
That is not bureaucracy for its own sake. That is how a contributor turns generated output into reviewable work.
Security reports show the same failure mode
This problem is even sharper in security work.
Seth Larson, who helps triage security reports for CPython, pip, urllib3, Requests, and other projects, wrote about an uptick in low-quality and LLM-hallucinated security reports. The nasty part is that these reports can look legitimate at first glance, which means maintainers still have to spend time proving that they are wrong.
That is not free. Security triage is stressful, private, and often handled by a small number of trusted people. A bad report does not just waste a few minutes. It can pull skilled maintainers away from real work, increase burnout, and make them more skeptical of legitimate reports.
The lesson applies beyond security: plausible language is not evidence.
If a report or patch was AI-assisted, the contributor should do the human part before sending it upstream. Reproduce the issue. Read the code. Confirm the API exists. Run the test. Reduce the claim. Bring the receipts.
AI can help, but mature codebases are not toy benchmarks
It is tempting to treat AI coding as pure speed. Sometimes it is. For small scripts, scaffolding, tests, docs, and familiar patterns, these tools can be genuinely useful.
But mature open-source projects are not blank files waiting for vibes. They have history, conventions, compatibility promises, weird edge cases, old design tradeoffs, and maintainers who remember why the obvious fix failed in 2017.
That is why the productivity story is mixed. METR’s 2025 study of experienced developers working on real issues in large open-source repositories found that allowing AI tools made participants take longer on the studied tasks, even though developers expected speedups. That does not prove AI slows down every developer everywhere. It does puncture the lazy assumption that more generation automatically means more progress.
CyganLabs has made this point before in AI Coding Works Best When You Own the Maintenance: speed only helps if someone still owns the result. The same rule applies to open source. A contributor who sends a patch is not just offering text. They are asking the project to accept future maintenance.
A better contribution standard for the AI era
If you use AI to contribute to an open-source project, the goal is not to hide it. The goal is to make the maintainer’s job easier.
A good AI-assisted pull request should usually include:
- a small, focused diff;
- a plain-language explanation of the problem;
- reproduction steps, if it fixes a bug;
- tests or a clear explanation of why tests were not included;
- notes on compatibility, security, or performance risks;
- links to the issue, discussion, or docs that motivated the change;
- disclosure when AI meaningfully helped;
- a clear statement of what the contributor personally reviewed.
This is not anti-newcomer. It is the opposite. It gives new contributors a path that respects the project and improves their odds of being taken seriously.
The worst version of AI contribution is extractive: the tool generates output, the contributor forwards it, and the maintainer is left to determine whether the idea, implementation, and tests are real. The best version is collaborative: the tool helps the contributor learn, narrow the problem, write tests, and show up with something a maintainer can evaluate without spelunking through a cave of maybe.
Lovely cave, probably generated in one shot. Still damp.
Maintainers are allowed to protect their attention
Projects are going to keep adding rules around AI-assisted work. That is not gatekeeping by default. It is maintenance.
Some projects will require disclosure. Some will reject large generated diffs. Some will ask for proof before reviewing. Some will limit automated agents that act in project spaces without human approval. That is reasonable, especially for projects with security, compiler, infrastructure, or ecosystem-level risk.
We already accept this principle in other operational contexts. In AI Agents Need Guardrails Before They Touch Production, the point is not that agents are useless. It is that authority needs boundaries. Open-source review has the same shape. A tool can help produce work, but a human still has to own what crosses the boundary.
The polite version is simple: do not hand maintainers homework disguised as help.
The useful future is proof-oriented
AI-assisted development is not going away. It should not. These tools can help people learn codebases, write better tests, explain unfamiliar systems, and contribute sooner than they otherwise could.
But contribution is not output. Contribution is understood, verified, useful work offered to a shared project.
That means the social contract needs an update. If AI lowers the cost of creating patches, contributors should raise the quality of the evidence that travels with them. The projects that survive this wave will not be the ones that pretend AI does not exist. They will be the ones that make the review bargain explicit.
Small diffs. Clear intent. Real tests. Honest disclosure. Human accountability.
Not glamorous. Extremely effective. Open source has always run on that kind of boring magic.