<!--- This file has been generated from an external template. Please do not modify it directly. -->
<!--- Changes should be contributed to https://github.com/munich-quantum-toolkit/templates. -->

# AI Usage Guidelines

We acknowledge that AI tools (Large Language Models, code completion engines like GitHub Copilot, etc.) have become helpful assistants for many developers.
We allow the use of these tools to assist with contributions, provided that their use is transparent, responsible, and that a **human remains in the loop** at all times.

This guide outlines our policy on AI-assisted contributions to ensure code quality, maintainability, and legal compliance.

## Core Principles

### 1. You are Responsible

**You are responsible for every line of code you submit.**

Regardless of whether code was written by you or generated by an AI tool, you are the author and are fully accountable for the contribution. You must:

- Fully understand the code you are submitting.
- Be able to explain the reasoning behind the code and how it interacts with the rest of the codebase.
- Verify that the code is correct, efficient, and follows our coding standards.

**Do not blindly copy-paste AI-generated code.** If you cannot explain it, do not submit it.

### 2. Human in the Loop

> **Autonomous contributions from AI agents are not allowed.**

When using AI tools, you must be the driver.
The AI is the assistant.

- **Review:** You must read and review all AI-generated code or text before submitting it.
- **Edit:** AI-generated code often requires significant editing to meet project standards and correctness.
- **Verify:** Ensure the code actually solves the problem and doesn't introduce subtle bugs or security vulnerabilities.

### 3. Communication

**Do not use AI tools to generate issue descriptions, pull request comments, or code reviews.**

We value your personal input and communication.
LLMs are notoriously unreliable and can produce "smart-sounding" but incorrect or irrelevant claims ("hallucinations").
Phrase your communications in your own words.
It is more important that we can follow your reasoning than that the text sounds "perfect".

### 4. Transparency and Disclosure

Transparency helps the community understand the role of these tools and develop best practices.

**We encourage you to disclose any AI assistance.**
This helps us understand how these tools are being used and identify potential issues.
You can disclose this information in the following ways:

- **Commit Messages**: Add a trailer to your commit message in the form `Assisted-by: [Model Name] via [Tool Name]` (example: `Assisted-by: Claude Sonnet 4.6 via GitHub Copilot`)
- **PR Description**: Mention the tool (name and version) and how it was used in the PR description.

### 5. Licensing and Copyright

You are responsible for ensuring that your contribution does not violate any third-party licenses or copyrights.

- **Originality**: Your submission must be your own original work of authorship.
- **Training Data**: Be aware that some AI tools may generate code that is substantially similar to their training data. You must ensure that you have the right to contribute the generated code under [our license](https://github.com/munich-quantum-toolkit/bench/blob/main/LICENSE.md).

## Extractive Contributions

Processing pull requests and comments for MQT Bench requires significant maintainer time and energy.
Sending unreviewed AI output to open-source projects shifts the burden of verifying correctness from the contributor to the maintainer.
We classify such contributions as "extractive" because they consume more community resources than they provide in value.

Our **golden rule** is that a contribution should be valuable enough to justify the review effort.
Nadia Eghbal captures this concept in her book _[Working in Public](https://press.stripe.com/working-in-public)_:

> "When attention is being appropriated, producers need to weigh the costs and benefits of the transaction. To assess whether the appropriation of attention is net-positive, it's useful to distinguish between _extractive_ and _non-extractive_ contributions. Extractive contributions are those where the marginal cost of reviewing and merging that contribution is greater than the marginal benefit to the project's producers. In the case of a code contribution, it might be a pull request that's too complex or unwieldy to review, given the potential upside." — Nadia Eghbal

Before AI tools became widespread, open-source project maintainers would often review all changes sent to the project simply because submitting a pull request was a sign of interest from a potential long-term contributor.
However, AI tools now allow the rapid generation of large volumes of code, which can easily overwhelm maintainers if submitted without careful review.
Our policy exists to ensure that maintainer time is spent on high-quality interactions rather than debugging AI-generated code.

### Sustainable Open Source

The Munich Quantum Toolkit (MQT) is committed to remaining free, open-source, and permissively licensed.
We want to build a welcoming community where aspiring quantum software engineers can learn and grow.
Reviewing contributions is a key part of this mentorship.

However, to keep the project sustainable, we must prioritize non-extractive contributions.
By thoroughly reviewing and understanding your AI-assisted code before submission, you ensure that your contribution is a net positive for the project.
This helps us maintain a healthy ecosystem where both the software and its contributors can thrive.

## Prohibited Uses

- **"Good First Issues"**: Do not use AI tools to solve issues labeled as "good first issue". These are intended as learning opportunities for new contributors. Automating them defeats the purpose.
- **Spam**: Do not use AI to generate low-quality or repetitive comments/reviews ("AI Slop").
- **Unreviewed Code**: Submitting code that you, as a human, have not reviewed and tested yourself.

## Summary

We want to foster a welcoming community where developers can learn and grow. AI tools can be great for productivity, but they should not replace critical thinking or the learning process.
If a maintainer judges that a contribution relies too heavily on unverified AI generation or lacks sufficient human understanding ("extractive contribution"), we may request that you revise it or close the PR.

---

Parts of this guide were inspired by or adapted from the contribution guidelines of

- [Astral],
- [Qiskit],
- [LLVM], including the sources therein, such as [Fedora Council Policy Proposal: Policy on AI-Assisted Contributions (fetched 2026-03-12)][fedora], which is licensed under the [Creative Commons Attribution 4.0 International License][cca].

with the help of Gemini 3 Pro (Preview). The links above serve as attribution.

[Astral]: https://github.com/astral-sh/uv/blob/c89a78ec085077f6344b0439ddf07fdad7336310/CONTRIBUTING.md
[Qiskit]: https://github.com/Qiskit/qiskit/blob/cd8701690723d3d9602fac63fe0bd7ea618799be/CONTRIBUTING.md#use-of-ai-tools
[LLVM]: https://github.com/llvm/llvm-project/blob/9b6391f9c439c9926e8587b7b940e9a1e98a7819/llvm/docs/AIToolPolicy.md
[fedora]: https://communityblog.fedoraproject.org/council-policy-proposal-policy-on-ai-assisted-contributions/
[cca]: https://creativecommons.org/licenses/by/4.0/
