AI-assisted contributions

The intelligent-agent projects accept pull requests written with the help of AI tools. This page sets out the rules, so contributors do not have to guess and maintainers apply the same standard to everyone.

It applies to every open-source software repository maintained by the intelligent-agent community. It does not apply to the hardware repositories.

The short version

AI-generated contributions are allowed. Label them, test them, and stand behind them.

Rules

1. AI-assisted work is welcome

Using an AI tool to write a change is not a reason to reject it. We care about whether a change is correct and tested, not about which editor, generator or assistant produced it.

2. Test it before you submit it

Every change must be demonstrably tested before submission, and the pull request should say how. On this codebase that usually means running it on real hardware, because most of what we ship only fails there.

This is the condition the rest of the policy rests on. Current agents are capable, but they are still language models: they misunderstand, and they invent things that look right. A confident explanation is not evidence. A passing test on a real board is.

3. Label it

Any pull request containing AI-generated code must be clearly labelled as such. Say which parts were generated and what you did to verify them. This is not a mark against the change — it tells a reviewer where to look hardest.

4. Maintainers may verify or decline

Where there is doubt about the testing behind a change, maintainers may test it themselves or decline it. Declining is about missing evidence, not about the use of AI.

5. Reading the code is unrestricted

Using AI agents to debug, explore, understand or audit the codebase is unrestricted. It changes nothing in a release, so it needs no permission and no label.

Labelling a pull request

Add a short note to the description. Something like:

Parts of this change were generated with an AI assistant.
Generated: src/foo.c error handling, and its test.
Tested: flashed to a Recore A8, ran 30 boot cycles, no regressions.

Rationale

Two failure modes are worth naming, because they are what the rules are aimed at.

Untested code that looks finished. Generated code is fluent by construction, so it passes a reading review more easily than hand-written code of the same quality. That makes the reviewer's usual defence weaker, and shifts the burden onto evidence of testing.

Confident wrongness. A model will explain a mechanism it has invented as readily as one that exists. Claims in a pull request description should be traceable to something observed — a log, a measurement, a test run — rather than to an explanation.

Neither is an argument against using the tools. They are an argument for labelling and testing, which is all this policy asks.

Status

Derived from the discussion in Rebuild issue #66. The intent is that this page is the canonical statement, and that a matching guidelines document is submitted to each open-source repository.