Should You Disclose AI-Written Code?

Usually, yes: disclose AI-written code when a project’s contribution guidelines, submission form, or review process asks about it, and be transparent when AI materially shaped a change. Open-source projects do not all have one universal disclosure rule, so check the repository’s current policies and make sure you can explain, test, and take responsibility for every line you submit.

Why disclosure matters in open source

Open-source software is built through collaboration under project-specific rules. A pull request is not only a patch; it is also a claim that the contributor understands the proposed change well enough to describe its purpose, limitations, and evidence. AI tools can help produce code, tests, documentation, or explanations, but their involvement may affect how reviewers assess those claims.

There is no single rule requiring every contributor to disclose every use of an AI tool. Some projects ask for disclosure, some prohibit or limit certain uses, and others have no explicit policy. Requirements can also differ between code contributions and generated documentation, or between an AI suggestion that was substantially rewritten and a patch generated largely from a prompt. The repository’s written guidance takes precedence over assumptions about what is customary elsewhere.

Disclosure is useful even when it is not formally required if AI played a substantial role. It gives maintainers context for reviewing unfamiliar code, checking generated tests, and considering licensing or provenance questions. It also prevents a mismatch between what a contribution appears to claim and how it was produced.

What to check before opening a pull request

Read the repository’s contribution guide, code of conduct, pull-request template, and any policy specifically covering AI-assisted contributions. Check recent maintainer guidance if the written rules are unclear, and ask before submitting when a requirement could affect whether the work is accepted.

• Look for disclosure instructions. A project may ask contributors to identify the tool, describe its role, or confirm that they reviewed generated output.
• Check for restrictions. The project may disallow generated patches, limit AI use to brainstorming or tests, or require maintainers’ approval.
• Follow the contribution process. Sign-off, licensing, formatting, tests, and review requirements still apply regardless of how code was drafted.
• Ask about ambiguity. A brief question in the project’s preferred channel is better than guessing about a rule that could block the contribution.

Do not treat a blank policy as proof that every use is welcome. It means the project has not stated a rule in that location; maintainers still decide whether a contribution meets the project’s standards.

What a useful disclosure says

A useful note is concise and specific. It should explain the tool’s contribution without suggesting that the tool is responsible for the patch or that its output has been independently verified when it has not. There is usually no need to include a full prompt transcript unless the project requests it or the prompts are relevant to reproducing the work.

For example: “I used an AI coding assistant to draft the input-validation helper and initial tests. I reviewed and revised the patch, ran the project’s test suite, and checked the behavior for empty and malformed input.” Adapt that wording to what actually happened and to the repository’s requested format.

If AI was used only for a minor task, such as suggesting a variable name or explaining an error message, follow the project’s policy on whether that needs to be reported. Avoid vague statements such as “AI helped” when maintainers need to know which parts were generated. Conversely, do not overstate the tool’s role: the point is an accurate account, not a ritual disclaimer.

Review and verify the generated code

AI-generated code can look polished while containing incorrect assumptions, missing edge cases, insecure patterns, or tests that merely reproduce the implementation’s own mistake. Review it as untrusted proposed code. The contributor submitting the patch remains responsible for understanding it and responding to review comments.

• Read every changed line and confirm that it fits the project’s architecture, style, and supported environments.
• Check behavior at boundaries, including empty values, invalid input, errors, and relevant platform or version differences.
• Run the project’s documented tests and add focused tests for the behavior the patch changes. Passing tests are evidence, not proof that every case is correct.
• Inspect dependencies, generated files, and copied snippets. Confirm that any new dependency is necessary and acceptable to the project.
• Remove unrelated changes and explain any limitations reviewers should know about.

Do not submit code you cannot explain or maintain. If you cannot establish what a generated function does, reduce it to a smaller change, research the behavior, or leave it out. A human-written patch can also be flawed; AI assistance does not change the ordinary expectation that contributions be correct, reviewable, and maintainable.

Licensing, attribution, and sensitive material

AI use does not automatically settle copyright, license, or attribution questions. Rules and legal outcomes can depend on the material used, the tool, the jurisdiction, and the circumstances. Contributors should not assume that generated output is automatically free of restrictions, nor that every similarity to existing code proves a violation.

Do not feed private repository content, credentials, personal information, or other restricted material into a third-party service unless you are authorized to do so and understand the service’s applicable data terms. Follow the project’s rules for confidential security reports and unpublished work. If output closely resembles code with a known source or license, pause and raise the provenance concern rather than presenting it as original work.

Some projects require a contributor sign-off or another statement about the right to submit a patch. AI assistance does not replace those requirements. If you are unsure whether you can make the required declaration, ask the maintainers or seek appropriate advice before submitting.

Common misunderstandings

“If the project does not ask, disclosure is forbidden.” Not necessarily. Silence is not a ban, but the project’s expectations may be unclear; ask if the use was substantial or raises a review concern.

“A disclosure makes the code acceptable.” It does not. Maintainers can still reject code that fails tests, does not fit project goals, violates policy, or cannot be adequately reviewed.

“AI-generated tests prove AI-generated code works.” Tests can be incomplete or based on the same mistaken assumptions as the implementation. Review the requirements and test meaningful cases independently.

“Every prompt needs to be published.” Usually, what matters is the information the project requests and what reviewers need to assess the patch. Share prompts or transcripts only when required or genuinely useful, and do not expose secrets.

Frequently Asked Questions

Do I have to disclose AI-written code in every open-source pull request?
No universal rule covers every project. Follow the repository’s policy, and consider a clear disclosure when AI materially drafted or changed the contribution, especially if maintainers need that context to review it.

What counts as AI-assisted code?
Projects may define this differently. It can include code or tests drafted by a generative tool, as well as substantial AI-driven edits. Minor uses such as spelling suggestions may be treated differently, so use the project’s definition where one exists.

Should I name the AI tool?
Name it if the project asks or if the detail helps explain the contribution. Otherwise, describing what the tool did may be enough. Do not claim a level of checking or verification that you did not perform.

Can maintainers reject a contribution because AI was used?
A project may set its own contribution rules and review criteria. A patch may be declined under those rules, or for ordinary technical reasons, even when the use was disclosed.

Am I responsible for bugs in code an AI tool generated?
As the person submitting the patch, you should be prepared to explain and support the proposed change. Treat generated output as a draft to inspect and test, not as an authority that transfers responsibility to the tool.

Related

• Best Alternatives to AI SOC Platforms for Small Teams
• Run Open WebUI and Ollama Locally in Docker
• Safe AI Bug Fixes: A Workflow That Protects Working Code