OTIO Logo

Policy on AI Coding Assistants

Last updated 8 days ago byEric Reinecke

Policy on AI Coding Assistants ==============================

  • Revised: 20-Oct-2026

Use of "AI coding assistants" is permitted on this project, with the following guidelines and principles.

Summary of our core values:

  • A human must always be in the loop, and is the responsible party for
    the contents of a PR (including fully understanding and being able
    to explain, defend, and modify it in response to review comments).
  • Humans should interact with the project and community directly, not agents.
  • You are strongly encouraged to disclose what tools you used and how. At a
    minimum, we request an "Assisted-by: TOOL / MODEL" line in the PR description.
  • Don't waste maintainer's time with low quality PRs.

The long version:

Human authorship and interaction with the project#

The human making a PR is considered the author and is fully responsible
for the code they submit.

No PRs should be submitted, reviewed/merged, or deployed without a human
fully in the loop. You may use agents locally to help you write code (and docs, tests, etc.), but you may not use agents to autonomously interact with the project community. Submit your own PRs, write your own discussion comments, respond to community members in your own words, approve or reject code in review using your own brain.

Code autonomously submitted without an identifiable human author and responsible party will be immediately closed, and the account associated with the submission may be banned from future project participation.

DO NOT "vibe code." This term refers to a pure prompt-to-behavior cycle
where the human accepts un-inspected code based on the program behavior alone. We don't want this. Code that must be maintained by the project should be truly understood. Project code is ideally the result of discussion / pair programming between the author and assistant, but even if the machine is doing most of the work, all code should be approved and fully understood by the author prior to PR submission.

Professionalism and quality#

The usual high quality level of PRs should be maintained regardless of tools
used. This includes not only code, but also the design, testing, PR preparation, and the author's ability to explain and defend the code and respond to questions and requests for changes. We never want to hear "but the AI..." as an excuse for anything.

PRs should always be reviewed and approved by someone other
than their author if at all possible. This is especially true of code with machine-generated components, because of the additional risk that the submitter/operator may not fully understand what they did not write themselves. This is part of the reason for AI tool disclosure -- to ensure that another pair of eyes is on it. AI code review may be requested for additional input, but the AI cannot give "approval", nor merge code itself.

Even when using a coding assistant to write the code, you are strongly
encouraged to write your own PR description, in your own words, if for no other reason than to force yourself to understand the code well enough to describe it to others.

Disclosure#

Disclosure is strongly encouraged. Patches that were written with the aid of AI
coding assistants should have, at a minimum, the following line in the PR description body:

text
Assisted-by: TOOL / MODEL

We especially request this when an LLM materially helped with the change (drafted code, helped design the approach, found the bug, suggested the specific fix, etc.). You may omit for any of the reasons listed in the "Exceptions" section below.

If you used the coding assistant in an unusual way that others could learn from, feel free to briefly say how you used the tool. But this is not required and we understand that it's often infeasibly difficult to describe accurately in any detail.

Intellectual Property#

Regardless of how the code came to be -- from your head alone, from a friend, from Stack Overflow, from a blog post, from reading other code bases, or from a coding assistant -- we expect the terms of the DCO and CLA to apply, and for the author to take reasonable care that code is not copied from a source with an incompatible license.

You may find that your confidence about complying with the DCO+CLA depends on:

  • If you provided a detailed specification and how much you edited or guided
    the results yourself.
  • Whether you are modifying or extending existing code versus writing large
    amounts of entirely new code.
  • The degree to which the generated code seems to fit into our structure and
    idiomatic style, and therefore seems unlikely to be copied from elsewhere.
  • Whether your tool has guardrails to prevent answers that are too similar to
    existing code, for example as claimed by Claude and Copilot.

Extractive submissions#

Maintainer time and attention are precious commodities, and use of coding
assistants is not an excuse to submit poor PRs or to externalize costs onto maintainers/reviewers (such as responsibility for understanding, testing, or fixing PRs that the human author does not have a full understanding of).

Maintainers are free to take counter-measures against submitters of sub-par PRs, or other violations of this policy, up to and including banning habitual abusers from future participation in the project.

We discourage use of AI tools to fix GitHub issues labeled as "good first
issue" or for "Dev Days" work. Cultivating and educating new contributors is important, and as such, we do not want people to swoop in and use automated tools to trivially solve tasks that were curated specifically for somebody to actually learn from. We expect each developer to implement at most one "good first issue" per Dev Days occasion, and we encourage you to solve the problem with your own brain to maximize the learning experience.

Exceptions#

This AI tool use policy is not meant to encompass cases such as:

  • "Smart auto-complete", spell-checking, grammar checking, or other uses that
    aren't really contributing substantively to authorship.
  • Purely mechanical assistance and light refactoring, such as moving code
    around or renaming things, enforcing formatting or coding style -- the
    kind of thing that IDEs could do for you even before LLMs.
  • Use of LLMs to explain code or learn about the codebase, answer basic
    programming questions, help with background research, or audit the code
    for bugs that are subsequently confirmed and fixed by people.
  • Language translation for non-fluent English speakers or other accessibility
    accommodations.
  • Trivial or de-minimis fixes such as fixing a typo, obviously wrong variable
    use, etc.
  • Reviewing your own code for mistakes prior to submitting a PR (as long as it
    isn't making substantive fixes for you).

Creative contributions -- out of scope#

This project repository contains code for tools, and their documentation. We don't really directly host any artistically creative work here, so we have not addressed additional policy issues that might come up in such a context.

If you are representing a different project that is using this document for guidance or inspiration for your own policies, please be aware that you may have needs that are not covered by these policies but deserve well-crafted guidance.

References and inspiration#

Our policy has been informed and inspired by the following efforts in other communities:

And here is some food for thought about the wisdom of which tasks to outsource to machines:

Plugin Documentation
Tutorials
Python
Tutorials