Submitting code generated with ai

[goeland86]

A recent discord discussion, and the use of Ai-assisted code experiments in relation to 3D printing tooling leads me to believe we should clarify our stance on accepting Ai-generated code.

Specifically the need for publicly available rules about it for future contributions.

The current stance is this :

• ai assisted programming is welcome, provided all the changes made have been demonstrably tested prior to submission by contributors.
• any pr containing Ai-generated code changes shall be clearly labeled as such.
• if there is any doubt about the testing done on the proposed code, the maintainers reserve the right to either test themselves or simply reject the proposed changes. The point is that while current agents are increasingly capable, the current tools are still LLMs, and as such more error prone by misunderstandings or hallucinations that can go unchecked.
• using ai agents to debug or otherwise understand or audit the codebase is unrestricted, as it does not directly impact the resulting functionality or stability of releases provided to users.

I welcome feedback on these fusions, and ultimately the guidelines document that will be submitted as a pr to every open source repository (so not the hardware related ones) maintained by the intelligent-agent community.

[goeland86]

Here is the current propposal policy. I welcome feedback no this:

AI-Assisted Code Contribution Guidelines

Intelligent Agent Organization — Community Policy Proposal

This document proposes guidelines for the use of AI-generated and AI-assisted code across all repositories managed by the Intelligent Agent GitHub organization. It originated from Rebuild issue #66 and is intended to serve as a living document that evolves alongside the tools and the community's experience with them.

---

1. Purpose and Scope

The Intelligent Agent organization maintains open-source projects that directly control 3D printer hardware — including board firmware, Linux OS images, web interfaces, and printer control software. Untested or misunderstood code in these projects can result in real physical consequences: damaged hardware, failed prints, or safety hazards.

These guidelines exist to harness the productivity benefits of AI-assisted development while protecting the quality, stability, and trustworthiness of the software we ship to users.

1.1 What This Policy Covers

This policy applies to all repositories under the intelligent-agent GitHub organization, including but not limited to:

• Rebuild — Linux OS images for Recore
• Reflash — Flasher image and web interface
• Refactor — Linux distro for 3D printers
• Toggle — Printer control software
• Klipper fork — Firmware customizations
• Any future repositories created under the organization that accept external contributions

Note: The Recore repository is excluded from this policy. It exists solely to document an open-schematic hardware product and does not accept external contributions.

1.2 Per-Project Overrides

Individual projects may adopt stricter requirements than those defined here (for example, requiring hardware-level test evidence for safety-critical Klipper changes). Per-project overrides should be documented in that repository's own CONTRIBUTING.md and must meet or exceed this baseline.

Projects may not relax these baseline requirements without explicit approval from the organization maintainers.

---

2. Core Principles

These four principles underpin every rule in this document:

1. Human accountability. The contributor who submits code is fully responsible for it — regardless of how it was produced. You must understand every line you submit as if you had written it yourself.

2. Demonstrate, don't assert. All code changes must be demonstrably tested prior to submission. "It compiled" or "the AI said it works" is not sufficient evidence of testing.

3. Transparency builds trust. AI-assisted contributions must be clearly labeled. This is not a mark of shame — it helps reviewers calibrate their review and helps the community learn which tools and workflows are effective.

4. Protect the user. Our software runs on real hardware in people's workshops. The bar for merged code is that it works reliably, not that it was produced efficiently.

---

3. What Is Permitted

3.1 AI-Assisted Programming — Welcome

Using AI tools (such as GitHub Copilot, Claude, ChatGPT, Cursor, Codeium, or similar) to assist in writing code is welcome, provided:

• All changes have been demonstrably tested by the contributor prior to submission.
• The contributor understands the code well enough to explain what it does, why it's necessary, and how it interacts with the rest of the codebase.
• The pull request is clearly labeled as containing AI-assisted code (see Section 5).

3.2 AI for Understanding and Debugging — Unrestricted

Using AI tools to read, understand, debug, or audit existing code is unrestricted and requires no special labeling. These activities do not directly modify the code that ships to users. Examples include:

• Asking an AI to explain what a function does or how a subsystem works.
• Using AI to help trace a bug or understand a stack trace.
• Having AI review your own code for potential issues before submitting.
• Generating documentation drafts or commit message suggestions.
• Using AI to understand unfamiliar parts of the codebase before contributing.

3.3 AI-Generated Tests — Permitted With Review

AI-generated test cases are permitted and can be a productive use of these tools, but the contributor must verify that the tests are meaningful (not just testing that the code does what it does) and that they actually exercise the intended behavior.

---

4. What Is Required

4.1 Testing

All AI-assisted code changes must be demonstrably tested by the contributor prior to submission. However, contributors are not required to include a test report with every pull request. What is required is that the contributor has done the testing and can provide evidence of it if asked.

If a maintainer has questions about whether a change has been adequately tested, they may request a description of the testing performed before the PR is considered for merging. Contributors should be prepared to describe what they tested, how they tested it, and on what environment — at a level of detail appropriate to the change:

Change Type	What a Maintainer Might Ask For
Configuration / build scripts	Confirmation of a successful build and boot, target environment details
Klipper / firmware changes	Description of hardware testing performed, number of cycles, any failures observed
Web interface (Reflash, Toggle)	Browser and environment tested in, description or screenshots of behavior
Python / application logic	What tests were run (unit, integration, manual), edge cases considered
Documentation only	Confirmation that technical accuracy was verified; no runtime testing needed

---

References and Further Reading

This policy was informed by guidelines and discussions from across the open-source community:

• Apache Software Foundation — Generative Tooling Guidance
• OpenInfra Foundation — Policy for AI Generated Content
• EFF — Policy on LLM-Assisted Contributions to Open-Source Projects
• Red Hat — Accelerating Open Source Development with AI
• Open Source AI Contribution Policies (community-maintained list)

---

This document is a proposal for community discussion. It is not yet in effect. Feedback is welcome via Rebuild issue #66.

# AI-Assisted Code Contribution Guidelines

Intelligent Agent Organization — Community Policy Proposal

This document proposes guidelines for the use of AI-generated and AI-assisted code across all repositories managed by the [Intelligent Agent](https://github.com/intelligent-agent) GitHub organization. It originated from [Rebuild issue #66](#66) and is intended to serve as a living document that evolves alongside the tools and the community's experience with them.

---

1. Purpose and Scope

The Intelligent Agent organization maintains open-source projects that directly control 3D printer hardware — including board firmware, Linux OS images, web interfaces, and printer control software. Untested or misunderstood code in these projects can result in real physical consequences: damaged hardware, failed prints, or safety hazards.

These guidelines exist to harness the productivity benefits of AI-assisted development while protecting the quality, stability, and trustworthiness of the software we ship to users.

1.1 What This Policy Covers

This policy applies to all repositories under the intelligent-agent GitHub organization, including but not limited to:

• Rebuild — Linux OS images for Recore
• Reflash — Flasher image and web interface
• Refactor — Linux distro for 3D printers
• Toggle — Printer control software
• Klipper fork — Firmware customizations
• Any future repositories created under the organization that accept external contributions

Note: The Recore repository is excluded from this policy. It exists solely to document an open-schematic hardware product and does not accept external contributions.

1.2 Per-Project Overrides

Individual projects may adopt stricter requirements than those defined here (for example, requiring hardware-level test evidence for safety-critical Klipper changes). Per-project overrides should be documented in that repository's own CONTRIBUTING.md and must meet or exceed this baseline.

Projects may not relax these baseline requirements without explicit approval from the organization maintainers.

---

2. Core Principles

These four principles underpin every rule in this document:

1. Human accountability. The contributor who submits code is fully responsible for it — regardless of how it was produced. You must understand every line you submit as if you had written it yourself.

2. Demonstrate, don't assert. All code changes must be demonstrably tested prior to submission. "It compiled" or "the AI said it works" is not sufficient evidence of testing.

3. Transparency builds trust. AI-assisted contributions must be clearly labeled. This is not a mark of shame — it helps reviewers calibrate their review and helps the community learn which tools and workflows are effective.

4. Protect the user. Our software runs on real hardware in people's workshops. The bar for merged code is that it works reliably, not that it was produced efficiently.

---

3. What Is Permitted

3.1 AI-Assisted Programming — Welcome

Using AI tools (such as GitHub Copilot, Claude, ChatGPT, Cursor, Codeium, or similar) to assist in writing code is welcome, provided:

• All changes have been demonstrably tested by the contributor prior to submission.
• The contributor understands the code well enough to explain what it does, why it's necessary, and how it interacts with the rest of the codebase.
• The pull request is clearly labeled as containing AI-assisted code (see [Section 5](Enhance/create image path #5-labeling-ai-assisted-contributions)).

3.2 AI for Understanding and Debugging — Unrestricted

Using AI tools to read, understand, debug, or audit existing code is unrestricted and requires no special labeling. These activities do not directly modify the code that ships to users. Examples include:

• Asking an AI to explain what a function does or how a subsystem works.
• Using AI to help trace a bug or understand a stack trace.
• Having AI review your own code for potential issues before submitting.
• Generating documentation drafts or commit message suggestions.
• Using AI to understand unfamiliar parts of the codebase before contributing.

3.3 AI-Generated Tests — Permitted With Review

AI-generated test cases are permitted and can be a productive use of these tools, but the contributor must verify that the tests are meaningful (not just testing that the code does what it does) and that they actually exercise the intended behavior.

---

4. What Is Required

4.1 Testing

All AI-assisted code changes must be demonstrably tested by the contributor prior to submission. However, contributors are not required to include a test report with every pull request. What is required is that the contributor has done the testing and can provide evidence of it if asked.

If a maintainer has questions about whether a change has been adequately tested, they may request a description of the testing performed before the PR is considered for merging. Contributors should be prepared to describe what they tested, how they tested it, and on what environment — at a level of detail appropriate to the change:

Change Type	What a Maintainer Might Ask For
Configuration / build scripts	Confirmation of a successful build and boot, target environment details
Klipper / firmware changes	Description of hardware testing performed, number of cycles, any failures observed
Web interface (Reflash, Toggle)	Browser and environment tested in, description or screenshots of behavior
Python / application logic	What tests were run (unit, integration, manual), edge cases considered
Documentation only	Confirmation that technical accuracy was verified; no runtime testing needed

The point is not to create bureaucracy — it's to ensure that someone has actually run the code before asking maintainers to review it.

4.2 Understanding

Contributors must be able to explain the code they submit. If a maintainer asks "why did you do it this way?" or "what happens if this input is null?", the answer cannot be "I don't know, the AI wrote it."

If you used AI to generate code and parts of it are unclear to you, take the time to understand them before submitting — or remove them. AI tools are excellent for learning how code works; use them for that purpose.

4.3 Maintainer Discretion

If there is any doubt about the adequacy of testing or the contributor's understanding of proposed changes, maintainers reserve the right to:

• Request additional testing or explanation.
• Test the changes themselves before merging.
• Reject the pull request outright.

This is not punitive. Our projects run on real hardware, and maintainers are the last line of defense before code reaches users. Contributors should expect — and welcome — thorough review.

---

5. Labeling AI-Assisted Contributions

Any pull request containing AI-generated code changes must be clearly labeled as such. This section presents labeling options for community discussion. The organization should adopt one or more of the following conventions:

Option A: GitHub PR Label

Create an ai-assisted label (and optionally an ai-generated label for predominantly AI-written code) on each repository. Contributors apply the appropriate label when opening their PR.

Pros: Visible at a glance in PR lists; easy to filter and track.
Cons: Requires label setup on each repo; contributors can forget to apply it.

Option B: Commit Message Trailers

Include a trailer in commit messages indicating AI tool usage, following the convention established by the Apache Software Foundation and adopted by the OpenInfra Foundation:

fix: resolve homing sequence timeout on dual-extruder setups

Corrected the timeout calculation to account for sequential
homing of both extruders rather than assuming parallel motion.

Tested on hardware with dual extruder config, 50 homing cycles
with no failures.

Assisted-By: Claude (Anthropic)

For code that was predominantly generated (rather than assisted) by AI:

Generated-By: GitHub Copilot

Pros: Embedded in git history permanently; follows emerging industry convention; machine-parseable.
Cons: Easy to forget; harder to enforce; not visible in PR list view.

Option C: PR Description Section

Include a standardized section in the pull request description:

## AI Disclosure
- **Tools used:** Claude (via Cursor), GitHub Copilot
- **Scope:** Initial implementation of the timeout calculation was AI-generated;
  I rewrote the edge case handling and wrote all tests manually.
- **Testing:** Described above.

Pros: Provides the most context for reviewers; flexible.
Cons: Requires discipline; no structured data for automated tooling.

Option D: Combined Approach

Use PR labels for visibility and commit trailers for permanent attribution in git history. Optionally include the PR description section for nuanced context on larger changes.

What Doesn't Need Labeling

Trivial AI usage — such as IDE autocomplete suggestions, AI-assisted typo fixes, or using AI to look up API syntax — does not require disclosure. The threshold is: if the AI meaningfully shaped the logic, structure, or approach of the code, label it.

---

6. Licensing Considerations

Contributors are responsible for ensuring that AI-generated output is compatible with the license of the project they are contributing to. In particular:

• Verify that the terms of service of your AI tool do not impose restrictions on the output that conflict with the project's open-source license.
• Be aware that AI tools may reproduce code from their training data. If you recognize or suspect that generated code originates from a specific project, check its license compatibility.
• If your AI tool offers features that flag output resembling known code or training data, enable them.

The contributor's sign-off on a pull request constitutes their assertion that they have the right to submit the contribution under the project's license, including any AI-generated portions.

---

7. What Maintainers Should Watch For

AI-generated code often has recognizable characteristics. Maintainers reviewing PRs labeled as AI-assisted (or suspected to be) should pay particular attention to:

• Plausible but incorrect logic — code that reads well but handles edge cases incorrectly, especially around hardware timing, serial communication, or concurrent operations.
• Hallucinated APIs or options — references to functions, configuration options, or Klipper G-code commands that don't actually exist.
• Over-engineered solutions — unnecessarily complex code where a simpler approach would suffice, often a sign the contributor accepted AI output without simplifying it.
• Style drift — code that doesn't match the conventions of the surrounding codebase (naming, structure, error handling patterns).
• Missing error handling — AI tools often produce "happy path" code that doesn't handle the failure modes critical in hardware-controlling software.
• Overly generic comments — comments that describe what the code does (which is already visible) rather than why, or comments that read like AI-generated documentation.

If something feels off, ask the contributor to explain a specific block and describe the tests that cover it. It is entirely acceptable to reject contributions that create more review burden than value. When doing so, be clear about what would make a resubmission acceptable.

---

8. Autonomous AI Agents and Bulk Contributions

Fully autonomous AI agent submissions (i.e., PRs opened by bots or agents without meaningful human review) are not accepted. A human contributor must review, test, and take responsibility for every submission.

Pull requests that appear to be bulk AI-generated content submitted with minimal human oversight will be closed. Repeated submissions of this nature may result in the contributor being asked to stop.

---

9. Evolving This Policy

AI tooling is advancing rapidly. What is impractical or unreliable today may be standard practice within a year. This policy will be reviewed periodically and updated to reflect:

• Changes in AI tool capabilities and reliability.
• Community experience with AI-assisted contributions (what worked, what didn't).
• Developments in open-source licensing and legal guidance around AI-generated code.
• Emerging industry conventions and best practices.

Community members are encouraged to open issues or discussions to propose changes to this policy. Significant changes will be discussed openly before adoption.

---

10. Summary

Activity	Status	Labeling Required?
Using AI to understand / debug / audit code	✅ Unrestricted	No
Using AI to assist in writing code	✅ Welcome	Yes
Using AI to generate test cases	✅ Permitted	Yes, if substantial
Submitting AI-assisted code without testing	❌ Not accepted	N/A
Submitting code you don't understand	❌ Not accepted	N/A
Fully autonomous AI agent PRs	❌ Not accepted	N/A

---

References and Further Reading

This policy was informed by guidelines and discussions from across the open-source community:

• [Apache Software Foundation — Generative Tooling Guidance](https://www.apache.org/legal/generative-tooling.html)
• [OpenInfra Foundation — Policy for AI Generated Content](https://openinfra.org/legal/ai-policy/)
• [EFF — Policy on LLM-Assisted Contributions to Open-Source Projects](https://www.eff.org/deeplinks/2026/02/effs-policy-llm-assisted-contributions-our-open-source-projects)
• [Red Hat — Accelerating Open Source Development with AI](https://www.redhat.com/en/blog/accelerating-open-source-development-ai)
• [Open Source AI Contribution Policies (community-maintained list)](https://github.com/melissawm/open-source-ai-contribution-policies)

---