The Problem Is Not the Code. It Is Provenance.
AI coding assistants have made it easy to produce a pull request that looks finished before anyone understands where it came from. That is the new maintenance problem. Not magic. Not doom. Just provenance.
A maintainer reviewing a normal pull request can ask familiar questions: did the contributor write this, copy it from another project, adapt it from docs, or generate it from a tool? With AI-assisted code, that answer often gets fuzzy. The contributor may not know which training examples influenced the output. The assistant may produce code that resembles public code. The patch may work today but carry assumptions nobody can explain.
That matters because open source is not just a code exchange. It is a trust system. Maintainers need to know that contributors have the right to submit the code, that the code is maintainable, and that someone understands it well enough to fix it later. A green test suite is nice. A green test suite attached to a drive-by blob is less nice.
The right policy is not to treat every use of an AI assistant as contamination. That is unrealistic in 2026. The right policy is to separate AI-assisted development from AI-dumped code. One can fit into a healthy workflow. The other is unpaid janitorial work for maintainers.
A Sane Rule: Assisted Is Allowed, Dumping Is Not
The cleanest project policy is simple: contributors may use AI tools, but they remain fully responsible for the result. If they cannot explain the code, test it, and certify that they have the right to contribute it, it should not be merged.
That sounds obvious, which is why it is useful. Good policies are usually boring. A repository can say:
- AI-assisted code is allowed when the contributor reviews, edits, tests, and understands it.
- AI-generated bulk submissions are not allowed when the contributor cannot explain the design or verify the origin.
- Disclosure is required for meaningful AI assistance, especially new modules, large rewrites, generated tests, or copied-looking snippets.
- The contributor is still the author of record for project purposes and accepts responsibility for licensing, security, and correctness.
- Maintainers may reject code on provenance grounds even if it compiles.
This avoids the fake binary of “ban every assistant” versus “merge whatever the robot says.” Most professional developers already use autocomplete, search, documentation, Stack Overflow, snippets, and internal examples. AI assistants are another source of suggestions. The difference is that they can generate larger chunks with less visible provenance. So the policy needs to make that provenance visible again.
What Contributors Should Disclose
A disclosure does not need to be a confession booth. Nobody needs a 900-word essay about which chatbot suggested a for-loop. The useful version is short and practical.
For a small change, a pull request can say: “Used an AI assistant to draft tests; reviewed and edited manually.” For a larger change, it should be more specific: “Used an AI assistant to prototype the parser structure. Final implementation was rewritten, tested against the existing fixture suite, and checked for similarity to known implementations.”
A good disclosure answers four questions:
- What was generated? Examples: tests, comments, migration script, parser, refactor plan, documentation.
- What was manually reviewed? The contributor should say what they checked, not just that they “looked at it.”
- What evidence exists? Tests, benchmarks, screenshots, links to issues, reproduction steps, or design notes.
- Can the contributor explain it? If a maintainer asks why the code is structured that way, the answer cannot be “the assistant did it.”
This is not about shaming people for using tools. It is about preventing a project from inheriting code with no accountable human attached. The machine does not maintain the repository. People do.
Licensing Still Needs a Human Signature
Many open source projects already rely on contributor promises. The most common lightweight mechanism is the Developer Certificate of Origin, which asks contributors to certify that they have the right to submit the work under the project license. AI assistance does not make that requirement disappear. If anything, it makes the contributor’s certification more important.
The uncomfortable truth is that an AI assistant usually cannot provide a reliable chain of title for a generated snippet. Some developer tools offer public-code matching or reference filters, and those features can help. GitHub, for example, documents options for code suggestions that match public code in its Copilot documentation. But a similarity warning is not the same thing as legal provenance, and the absence of a warning is not a clean bill of health.
That means maintainers should not accept “the AI wrote it” as a licensing answer. The contributor should still be able to certify that the contribution is theirs to submit. If they cannot, the safest answer is boring and correct: do not merge it.
This is especially important for code that implements standard algorithms, protocol handlers, file format parsers, compatibility layers, or anything that looks suspiciously like an existing project. A ten-line helper is rarely the problem. A 700-line subsystem arriving fully formed from a first-time contributor deserves a raised eyebrow. Possibly two.
What Maintainers Should Check Before Merging
Maintainers do not need to become forensic AI detectives. They do need a repeatable review checklist. The goal is to catch the obvious disasters without turning every pull request into litigation cosplay.
- Ask for disclosure on meaningful changes. Add a checkbox to the pull request template: “Did you use an AI coding assistant to generate or substantially modify this code?”
- Require explanation, not vibes. If the contributor cannot explain the implementation, request changes or close the pull request.
- Prefer small patches. AI-assisted work should be easier to review, not harder. Large generated rewrites are where risk hides.
- Demand tests that prove behavior. Generated code often looks plausible. Tests make it earn its keep.
- Watch for alien style. Sudden naming conventions, error handling patterns, dependency choices, or architecture that do not match the project are warning signs.
- Reject unnecessary dependencies. Assistants love adding packages. Maintainers get to live with them forever.
- Use normal security review. Input validation, auth boundaries, secrets handling, deserialization, shell calls, and network access still matter.
The best rule is: if AI assistance makes the maintainer’s job harder, the contributor has not done enough work yet. A pull request should arrive smaller, clearer, and better tested because an assistant helped. If it arrives as a giant tarball of optimism, close it with a polite note and go outside for five minutes.
Where AI Actually Helps in a Healthy Workflow
There are good uses for AI coding tools in open source. They are just not always the flashy ones. An assistant can help draft unit tests, explain a confusing function, propose edge cases, generate fixture data, translate an error message into a reproduction checklist, or sketch a migration plan. Those uses leave the human contributor in control.
The risky pattern is outsourcing judgment. “Write this feature” is a weaker prompt than “list edge cases for this parser” or “suggest tests for this bug.” The first produces code that may or may not fit the project. The second produces material a contributor can verify.
If you use multiple assistants for research, coding, and documentation, it also helps to keep the workflow visible instead of scattered across random browser tabs. Notavello’s AI tools directory is built around that practical reality: people compare tools, use more than one, and need to understand what each is good at before trusting it with real work.
For open source maintainers, the same principle applies at the repository level. Do not ask whether a tool was involved and then stop thinking. Ask whether the contributor used the tool in a way that improved the submission. Better tests? Clearer docs? Smaller patch? Good. Mystery code? No.
A Repository Policy You Can Paste Today
Here is a practical starting point for a project policy. Adjust the strictness based on the size, risk, and license sensitivity of the project.
AI-assisted contributions policy:
- Contributors may use AI coding assistants, but they are fully responsible for all submitted code, documentation, tests, and configuration.
- Contributors must disclose meaningful AI assistance in the pull request description, including what was generated or substantially modified.
- Contributors must be able to explain the submitted code and the design choices behind it.
- Contributors must certify that they have the right to submit the contribution under this project’s license.
- Large generated changes, unexplained rewrites, or submissions with unclear provenance may be rejected even if they pass tests.
- Maintainers may request smaller patches, additional tests, or manual rewrites before review continues.
That policy will not answer every edge case. No policy does. But it gives maintainers something better than vibes and contributors something better than guessing.
The future of AI-assisted open source will not be decided by whether someone used autocomplete with a larger vocabulary. It will be decided by whether projects preserve accountability. Code can be generated quickly now. Trust still has to be earned the slow way.