Contribute

AI policy

AI-assisted development is welcome in Brig. You are responsible for what you submit, the same as for code you write by hand.

AI as a tool #

Brig encourages you to use AI tools, coding agents, automated reasoning, and other software-engineering systems where they are useful. The maintainers are also interested in experiments with frontier models, agentic workflows, automated debugging, testing, code review, and other new ways to build reliable software.

AI is a development tool. Its use does not make a contribution more or less valuable. The quality of the result decides the value.

Use AI as much as you like.

Disclosure #

You do not need to disclose that AI helped to create a contribution. Ordinary AI assistance needs no label, footer, or declaration.

You can describe the models, agents, prompts, workflows, or experiments behind your work when that information is interesting or useful.

If the generation process matters for reproducing or evaluating the contribution, document it. Examples are an AI benchmark, a generated test corpus, and an experiment with autonomous agents.

Responsibility #

Responsibility does not transfer to the model. Maintainers judge a contribution as a contribution to Brig, not as AI output.

When you submit code, documentation, tests, benchmarks, or other material, you take responsibility for it as if you wrote every line.

Before you submit a change:

• Understand what the change is intended to do.
• Review the resulting diff.
• Run the applicable tests and repository gates.
• Verify claims about correctness, performance, compatibility, and security.
• Remove speculative, irrelevant, duplicated, or unnecessary changes.

Do not claim that tests passed, a bug was reproduced, a benchmark improved, or a behavior was verified unless that happened.

"An AI generated it" is neither an excuse for a defect nor evidence that something is correct.

Maintainer attention #

AI can make code cheap to produce. Review is not cheap. Do not use that difference to transfer work to maintainers.

Maintainers can close:

• Large quantities of unreviewed generated code.
• Speculative fixes.
• Issue-farming.
• Mechanical repository-wide rewrites.
• A pull request whose author made little effort to establish correctness.

A contribution must make the project better, not only make the diff larger.

Small, well-understood changes are usually easier to evaluate than broad changes made only because an agent can produce them.

Engineering rules #

All repository rules, architectural decisions, compatibility requirements, and correctness invariants apply equally to AI-assisted and manually written changes.

An easy implementation that an agent finds is not a reason to bypass an architectural boundary.

Changes to durable formats, consistency semantics, protocols, public behavior, or other architectural contracts need the same design consideration and review as any other change.

If the repository requires a specification change, compatibility analysis, or particular test coverage, AI-assisted work must meet that requirement too.

Prefer evidence over confidence. Tests, fault injection, benchmarks, reproductions, and clear reasoning are more useful than an agent's assertion that a change is correct.

Agentic contributions #

Agentic contributions are welcome. Brig development can use interactive assistants and autonomous or unattended agents.

• Give an agent bounded tasks, sufficient repository context, and objective verification criteria.
• Inspect and validate its output before it becomes part of the project.

More autonomy makes verification more important.

Repository-maintained automation can create commits, pull requests, reports, or other operational messages as part of established workflows.

External automation must not flood issues, pull requests, reviews, or discussions.

Maintainer communication #

AI can help you understand review feedback, investigate a problem, or make a response clearer.

Do not use it to generate high-volume or non-responsive discussion.

A reply to review feedback must show that you considered the feedback. When appropriate, it must also show that you inspected or tested the underlying code.

Never invent explanations, measurements, reproductions, citations, or technical conclusions because a model produced plausible text.

Conversation with maintainers is part of the engineering of the change.

Strong verification #

Prefer AI for work whose output you can verify objectively. Examples:

• Finding and fixing bugs.
• Adding regression and property tests.
• Simplifying or deleting unnecessary code.
• Improving error handling.
• Fuzzing and fault-injection work.
• Improving build and CI tooling.
• Identifying performance regressions.
• Improving documentation.
• Analyzing concurrency or failure paths.
• Detecting inconsistencies between implementation and specification.
• Security research and defensive analysis.

Large features are welcome too, but AI does not replace design. For a larger semantic or architectural change, it is more important to establish the design before you generate the implementation.

Security and sensitive data #

Do not expose any of the following to an AI service:

• Secrets.
• Credentials.
• Private telemetry.
• Vulnerability reports under embargo.
• Proprietary code.
• Personal data.

Do not disclose any other information you are not authorized to share.

You are responsible for understanding how the tools you use handle data.

AI-generated code must meet the same security expectations as any other code. Give extra scrutiny to generated:

• Dependency additions.
• Cryptographic code.
• Parsers.
• Authentication logic.
• Unsafe input handling.
• Security-sensitive configuration.

Intellectual property and provenance #

The same intellectual-property and licensing rules apply to every contribution, however it was produced. AI output does not remove provenance or licensing obligations.

Do not submit code, documentation, tests, or other material copied or reproduced from another project unless you have the right to do so. You must meet every applicable license and attribution requirement.

You are responsible for making sure that you have the legal right to contribute the material you submit.

Research #

Research that involves Brig and AI-assisted software engineering is welcome, including:

• Model comparisons and identical-task evaluations.
• Automated bug repair.
• Test generation.
• Agentic development loops.
• Reproducibility studies.
• Code-review experiments.
• Security analysis.
• Failure-injection experiments.
• New approaches to autonomous software engineering.

Research must preserve the same standards of safety, licensing, and repository integrity as ordinary development.

If an experiment produces a useful improvement to Brig, it is welcome as a contribution.