Guidelines around use of AI are included in Contribution Guidelines

[sparkslabs]

Background

AI can both be a good thing and a bad - often viewed as "AI slop" (rightly or wrongly).

Example issues: A particular issue is when entire sections and subsystems are created and merged without clarity of purpose behind the addition, ownership. GenAI often results in large PRs without detailed discussion as to the specific changes nor why they're made. Since no actual thinking occurs an a GenAI process, you have to reconstruct the logic that led to a piece of code being generated (and whether it fits the team, codebase, project). This can be non-trivial. Large PRs increase the maintenance burden, and AI generated code often lacks context about how a particular decision was reached, and why X was chosen over Y and Z and what process led to that decision. Large PRs also place a high cognitive burden on those merging. This is beyond "does the code do what is expected/designed", and whether it satisfies the higher level goals. There's plenty of other issues - such as copyright. In some countries unless significant change is made to the generated output, it may be illegal to slap an open source license on the code, since in some jurisdictions GenAI output is copyright free/public domain - irrespective of whether it technically derives from an open source project and must adhere to that license. In others the copyright on the output is owned by the person who created and ran the prompt. In others, the copyright ownership is with the person who owns the CPU cycles that generated the GenAI output. Review fatigue is very real.

These issues really represent a cognitive burden that GenAI creates andn places on maintainers. Given that the scarcest resource in a project is the cognitive resource around reviewing and merging content for correctness and fit, this needs to be taken into account. (Most cognitive resource used in a project is used elsewhere)

Opinion

This is incidentally similar to the issue of "small vs large PRs" generally speaking. Small PRs are easier to merge and more often merged by projects. Large PRs are either waived through on reputation/ownership, requested to be broken down into smaller PRs, outright refused, or reviewed on a "reasonable efforts" basis. One of the key things that helps with large PRs is to see the history of thought behind each of the changes. This is less of a problem with large PRs created by people because they naturally checkpoint their code with their thinking along the way before creating a PR.

Discussion to Date

The discussion to date has focussed around whether it's being used, how it's being used, with the consensus being summarised as "you must declare".

Definition of Done

• Basic details of what is and isn't acceptable in terms of use of AI and how relative to contribution to this project
• Has the start of something that can lead to a consensus, but does not need to be a consensus at this point.
• Should explicitly note how much consensus has been reached around this.