AI code in open source: how to publish honestly and not lose trust

On October 24–25, 2026, the moderator of r/opensource announced a strict restriction: projects created with or intended for AI are no longer welcome in this community. This is a specific subreddit rule, not a new license or a ban on open source in general. However, the reason for the conflict is important: maintainers are increasingly receiving large changes from people who cannot explain their own code.

At the same time, other communities have chosen responsible disclosure rather than a ban. Model Context Protocol allows AI assistance if the author explains its use, understands the changes, and has verified the result. Apache Software Foundation recommends noting the tool used in the commit message and separately reminds of licensing risks. Thus, there is no universal rule: before contributing, you must read the policy of the specific project.

Why AI code is rejected

The problem is not about whether it is 'fair' to use a model. For a maintainer, the main currency is review time. A small patch with a reproducible test can be understood. A massive diff without explanation shifts all the work from the author to the reviewer.

Step 1. Check the rules before writing code

Start with CONTRIBUTING.md, pull request template, Code of Conduct, issue tracker, and licenses. Look for words AI, LLM, generated, disclosure, DCO and a CLA. If there is no policy, it is not an automatic permission for autonomous agent contribution. To change the architecture, first open an issue or discussion.

In r/opensource, a new rule concerns posts in specific Reddit communities. A repository may have other rules. Conversely: the fact that a project is promoted in a loyal community does not override the requirements of its own maintainers.

Step 2. Narrow the task down to a verifiable patch

A bad task for an agent: «fix all bugs and make the code modern». A useful task contains a boundary:

Repository: [link]
Issue: [number and exact symptom]
Allowed to change: src/parser.ts, tests/parser.test.ts
Do not change: public API, dependencies, formatting of other files
First, add a test that reproduces the error.
Then, suggest a minimal fix and explain the risks.
Do not create a commit or open a PR without my review.

Such a contract does not guarantee correctness, but it makes the result readable and leaves the decision to the human. For agents with repository access, also apply our secure access checklist: separate branch, minimal permissions, secrets outside of context.

Step 3. Prove that you understand the changes

Before the PR, go through the diff line by line. For each new block, ask yourself:

• What input caused the error?
• Why exactly does this condition fix it?
• Which edge cases are not covered?
• What will happen to compatibility and performance?
• Can I change the patch without re-querying the model?

If the answer to the last question is no, the patch should be simplified or studied more deeply. The MCP policy formulates a similar criterion: the author must understand why the change is needed and confirm that it works.

Step 4. Leave evidence of verification

Don't limit yourself to the model's green response. Run the repository commands in a clean environment. Record the runtime version, the command, the number of tests, and the manual scenario. If a test could not be run, write that down—it is more useful than fabricated confidence.

Verified locally:
- node --version: v24.x
- npm test: passed
- npm run lint: passed
- manual scenario: file with an empty header no longer crashes the parser

Not verified:
- Windows
- performance on files over 100 MB

It is useful to ask AI to perform a code review, but that is a second look, not proof. Our practical guide to AI code review explains how to separate an automated suggestion from a developer's decision.

Step 5. Check licenses, dependencies, and secrets

A generated fragment does not become safe just because you don't know its source. Do not ask the model to «reproduce library code», do not accept long recognizable blocks, and do not add a dependency without checking its license and support status. Apache specifically emphasizes: generated contributions must still comply with the rules for including third-party works.

Before publishing, check the diff for API keys, tokens, private URLs, personal data, and environment files. For a Git repository, it is worth using a secret scanner, but also manually reviewing new configurations and commit history.

Step 6. Disclose the AI's role without theater

Disclosure should help the review, not just contain the word «AI». Name the tool, its role, and what you verified yourself. If the project requires a specific trailer in the commit message, copy the format from the documentation. Apache suggests as a recommended example Generated-by: or Co-authored-by:, but a specific repository may require something else.

Download PR description template (.txt)

## What changed
[one sentence about the problem and the result]

## Verification
- [command]: [actual result]
- [manual scenario]: [actual result]

## AI Usage
Used [tool] for [specific role].
I have reviewed the entire diff, can explain the changes, and am responsible for them.

## Limits
Not verified: [platform/load/scenario].

Step 7. Engage in dialogue as an author

Do not copy the maintainer's comment into the model and do not paste a response without understanding it. First, paraphrase the problem in your own words. If a comment changes the architecture, provide a brief clarification. If a patch is not needed, close the PR without argument. In open source, the right to contribute does not mean the other person has an obligation to accept it.

Pre-pull request checklist

• Read CONTRIBUTING, PR template, and the project's AI policy.
• Issue is agreed upon or the change is truly minor and obvious.
• Diff is minimal; no accidental formatting or new dependencies.
• Every line is clear to the author.
• Tests and manual scenarios were run personally.
• Licenses, secrets, and personal data have been checked.
• The AI's role is disclosed in the format accepted by the project.
• Unverified limits are honestly recorded in the PR.

Frequently Asked Questions

Is AI code banned in open source?

No. There are communities with total bans, projects with disclosure requirements, and repositories without a separate policy. Check the rules of the specific place before working.

Do I need to specify every autocompleted string?

Depends on the project policy. If the rule is unclear, briefly describe the tool's significant role in the PR. Do not invent accuracy that you cannot verify.

Is writing 'generated by ChatGPT' enough?

No. Maintainers need the goal of the change, proof of verification, scope, and an accountable person. Naming a tool without understanding the code does not reduce risk.

Sources

• r/opensource: “Your tokens aren't valuable: No more AI”, 24–25.10.2026 — announcement of specific community rules.
• Model Context Protocol: Contributing — permission for AI assistance with disclosure, understanding, and verification.
• Apache Software Foundation: Generative Tooling Guidance — provenance, licensing requirements, and recommended labeling.
• Apache Magpie: AI contribution policy — example of a project policy with human accountability.