How to Ethically Disclose AI-Assisted Code in Open Source Projects (Without Getting Gatekept)

The Open Source Backlash

Open-source maintainers are exhausted. Over the last year, a wave of low-effort, AI-generated Pull Requests (PRs) has flooded GitHub. Maintainers who volunteer their spare time are suddenly stuck triaging hundreds of half-baked commits that look plausible on the surface but fail catastrophically in production.

Because of this, many projects are hitting the panic button. Some have banned AI-generated contributions entirely; others treat any hint of machine assistance with extreme suspicion.

This leaves ethical builders in a tough spot. If you use a tool like /platforms/claude to help you refactor a tricky utility function or write comprehensive unit tests, should you disclose it? If you do, will the maintainers instantly close your PR without reading it? If you do not, are you violating the unspoken trust of the community?

Let's unpack how to navigate this line honestly, protect your reputation, and keep open-source collaboration healthy.

Defining the Spectrum of AI Assistance

We need to stop talking about "AI-generated code" as a single, monolithic category. There is a massive difference between tab-completing a boring loop and letting an LLM generate a whole feature branch.

To figure out when and how to disclose, we can break AI usage down into three distinct tiers:

Tier 1: Inline Autocomplete (The Modern Spellcheck) This is your standard GitHub Copilot or Supermaven tab-completion. It suggests the next line of code, helps you close your brackets, or pre-fills boilerplate object keys.

• Do you need to disclose? No. This is the modern equivalent of an IDE's autocomplete or a linter. It does not change the architectural intent of your code.

Tier 2: Targeted Synthesis (The Smart Pair-Programmer) You copy a specific, self-contained function into a chat interface and ask for an optimized version, or you use a tool to generate a suite of unit tests based on your hand-written logic.

• Do you need to disclose? Yes, ideally. While the logic is yours, the execution was heavily assisted. A brief mention in your PR description keeps things transparent.

Tier 3: Complete Generation (The Agentic Commit) You feed an entire issue description into an agentic workflow, let it run in a sandbox, and submit the resulting multi-file diff with minimal modification.

• Do you need to disclose? Absolutely. This is a machine-authored contribution. Failing to label this clearly is a breach of developer trust.

The Danger of Stealth AI

Why are maintainers so sensitive about this? It is not just about snobbery; it is about risk management.

When a human writes code, they carry a mental model of how the system works. When a machine writes code, it mimics patterns without understanding constraints. Machine-generated code is prone to subtle, hallucinated edge cases that can look incredibly convincing to a reviewer who is skim-reading.

If you submit code without disclosing that it was synthesized by an LLM, you are effectively tricking the maintainer into skipping the deep verification that machine-authored code requires. If your commit introduces a silent memory leak or a security vulnerability, you have burned that project's trust—and your reputation—permanently.

How to Write a PR Disclosure That Maintainers Respect

Disclosure does not have to mean apologizing. If you have used AI responsibly, own it. Show the maintainer that you did not just copy-paste slop, but that you thoroughly reviewed and tested the output.

Here is a template for an ethical, constructive PR disclosure:

`markdown ### What this PR does This PR optimizes our markdown parser by rewriting the nested regex loops into a state machine.

AI Disclosure * **Tool used:** Claude 3.5 Sonnet * **How it was used:** I drafted the initial state machine logic, then used Claude to optimize the transition table and generate the edge-case unit tests in `tests/parser_spec.rs`. * **My verification:** I have manually reviewed every generated line, run the benchmark suite (results below show a 14% speedup), and confirmed there are no unexpected allocations. ```

By structured disclosure like this, you show the maintainer three things: 1. You are honest. 2. You understand the code you are submitting. 3. You have done the hard work of verifying and testing it, rather than dumping raw output on them to debug.

If you need help craftings prompts that produce cleaner, more reviewable code in the first place, take a look at our /prompts for developer workflows.

The Golden Rule of AI Contributions

If you take only one rule away from this guide, let it be this:

If you do not fully understand the code the AI generated, do not submit it.

Do not use open-source projects as a free QA department for your AI experiments. If you cannot explain every line of your pull request during a code review, you have no business committing it to a shared repository.

Keep your standards high, be loud and clear about your tools, and respect the human beings on the other side of the screen. That is how we keep open source open.