How to Be an Open Source Hero: Contributing AI-Generated Code with Care

• Be transparent. Disclose how AI contributed to your pull request and link process context when you can.
• Own the code. Treat AI like a junior collaborator. You remain accountable for tests, edge cases, and explanations.
• Set expectations. Maintainers should add an AI section to CONTRIBUTING.md with concrete examples.
• Right-size disclosure. Trivial autocomplete does not need disclosure. Meaningful generation, debugging, docs, or design help does.
• Normalize good habits. Celebrate high quality, well disclosed AI-assisted contributions.

This guide is for contributors and maintainers with basic familiarity with GitHub pull requests and review workflows.

Disclose your tools and how you used them

Put this near the top of your pull request description. Be specific about scope.

• Minimal: “Claude Code assisted with this implementation.”
• Better: “Used ChatGPT to understand the codebase. Implemented the solution manually.”
• Best: “Cursor suggested this approach, see linked chat history saved in SpecStory. I adapted it to the project conventions and added tests.”

Show your process when possible

Export your chat from Cursor, Claude Code, or your IDE assistant and link it in the pull request. SpecStory can capture session context so reviewers see how you arrived at the solution. That context shortens review cycles because maintainers can follow your reasoning.

Own quality and understanding

AI is not a substitute for your judgment.

• Review every line and remove placeholders or TODOs.
• Write tests for edge cases, not just the happy path. Add a regression test if you fixed a bug.
• Explain the why. If you cannot describe a change in your own words, including data structures, complexity, and failure modes, it is not ready.

A simple disclosure block you can copy into your PR

### AI Assistance Disclosure
- Tools: <Cursor (Claude), ChatGPT, Copilot>
- Scope: <generated initial algorithm; I rewrote IO layer; wrote all tests manually>
- Context: <link to exported chat from SpecStory or your IDE>
- Review: I validated logic, added edge-case tests, and confirmed style conventions.

Set expectations in CONTRIBUTING.MD

Add an AI Assistance section: require disclosure, explain why it matters, and include examples of good PR blurbs (from Minimal → Best). Consider linking to a PR template checkbox: “Have you disclosed AI assistance and provided links to your process if applicable?”

Mitchell Hashimoto’s Ghostty project is a useful reference for normalizing disclosure as a courtesy to reviewers and for calibrating review depth based on the contributor’s explanation.

Suggested snippet:

## AI Assistance
If you used AI tools for this contribution, disclose them in your pull request and briefly describe scope
(docs only, debugging, partial code generation, or similar). Link process notes or chat exports when available.
Trivial autocomplete does not require disclosure.

Review with care and efficiency

• Watch for style drift, over generic comments, or over complicated functions. These are common signs of low effort code generation.
• If something feels off, ask the contributor to explain a specific block and the tests that cover it.
• It is acceptable to reject contributions that create more burden than value. Be clear about what would make it acceptable next time.

Build healthy norms

Treat disclosure as routine, not shameful. Encourage contributors to share how they used AI, highlight great examples in release notes, and maintain a short “Responsible AI in this repo” page with preferred prompting tips and domain context links (so assistants perform better).

Disclosure should be required when AI meaningfully shaped the pull request, including:

• Generating or rewriting non trivial code
• Explaining architecture, suggesting design choices, or helping with debugging
• Writing significant documentation or comments

Disclosure is not required for:

• Editor autocomplete, syntax fixes, or mechanical renames
• Small line level completions that do not change logic

Contributor pull request blurbs

• Minimal: “Claude Code assisted with this implementation.”
• Better: “Used ChatGPT to understand the codebase. Implemented the solution manually.”
• Best: “Cursor suggested this approach, see linked chat history saved in SpecStory. I modified it to fit our use case and added tests.”

Maintainer checklist**

• [ ] AI disclosure present, or marked not applicable
• [ ] Contributor can explain complex blocks in their own words
• [ ] Tests cover edge cases and regressions
• [ ] Style and conventions match the repository
• [ ] Documentation updated where behavior changes

Treat AI like a junior developer. Let it propose ideas, but you supervise, simplify, and verify. Remember there is a human maintainer on the other side of your pull request with limited time. Projects can harness AI-assisted contributions by sharing prompting tips that work well, offering short project overviews, and highlighting great pull requests as models for others.

AI is not replacing open source contributors. It is giving them new ways to participate. Sustainable collaboration depends on transparency, respect, and careful review. Tools like SpecStory preserve not only code, but also the reasoning behind it, which makes reviews faster and more instructive for everyone.

Use AI as an assistant, not a shortcut. Be clear about when and how you used it, check the quality yourself, and remember there are people on the other side of your pull request. That is how you help projects thrive.