Add development standards and AI usage guidelines

CONTRIBUTING.md

@@ -58,3 +58,23 @@ Some of the designs in there are already outdated or still a work in progress. W
 Finamp uses Weblate to manage translations: **https://hosted.weblate.org/engage/finamp/**
 
 Feel free to add new languages if yours isn't there yet. If you have any questions, such as the context of a string, you can ask in the [Translation Discussions](https://github.com/jmshrv/finamp/discussions/categories/translations).
+
+## Development Standards and AI / LLM Usage
+
+1. **Design & Intent:** You should think about the problem you are trying to solve, and what approach you would like to take, before you start coding. Clearly verify and document the problem, the approach chosen, and the justification behind the chosen path. If unsure, discuss with the team.
+
+2. **Verification:** After you have written the code (AI-assisted or not), you should verify the code works as expected. Screenshots and/or videos are good ways to share your test results.
+
+3. **Ownership & Sustainability**: You are responsible for the code you write. Adding a new feature is a long-term commitment. We view contributors as the owners of the features they introduce. We want to keep the codebase healthy, so if a feature becomes unmaintainable, we may need to deprecate or remove it.
+
+4. **AI usage:**
+
+    4-1. **Disclosure & Responsibility:** If a PR was mostly generated by AI, you should include a statement in the PR comment on which tool / model you are using, and confirm that you are responsible for the code. This statement will be recorded in the merge commit message for documentation.
+
+    4-2. **Attribution:** LLM co-authors should not be included in commits. Please remove them before submitting PRs. We want to ensure human contributors receive the credit.
+
+    4-3. **Communications:** LLMs may be used for PR descriptions or comments where appropriate. However, you should be in charge of the PR, and should not be acting as an agent of the LLM. AI output should not be blindly echoed.
+
+5. **Scope & Complexity:** PRs should be scoped and focused. If a PR starts getting too large or include changes across a wide area of code, we may ask you to split the PR into multiple smaller PRs.
+
+6. **Code Quality:** Code quality requirements are judged on a case-by-case basis during review. Poor quality, low effort PRs may be closed without further explanation at the discretion of maintainers.