Add an official LLM policy

[kaascevich]

Lately, we've been having more PRs coming in that are either wholly generated by LLMs or incorporate LLM-produced code. We've been discussing this internally for a while now and figured we should probably let the rest of the community have a say in the matter.

The core contributors (@stackotter, @bbrk24, @MiaKoring, and @kaascevich) are all leaning towards at least a partial ban on LLM-generated code, since we've observed how huge, low-quality PRs tend to cause maintainer burnout in other projects (many with far more resources at their disposal than SwiftCrossUI). This is still open for discussion -- while we probably won't continue to allow wholly vibe-coded PRs, our policy could allow for smaller-scale LLM use, such as those in the style of Xcode's AI autocomplete.

It's still up in the air how we want to express an LLM policy in writing, or whether we should continue allowing non-code-related uses of LLMs (particularly machine translation) in issues and PRs.

Prior Art

• Zig's short and sweet no-LLM policy

[JoshBashed]

Will this only impact scui or will it include sbun? If it includes sbun, I definitely have some thoughts on this topic.

[kaascevich]

Will this only impact scui or will it include sbun? If it includes sbun, I definitely have some thoughts on this topic.

The specific policy we come up with in this issue will only affect SCUI, though if we end up needing an LLM policy for sbun we'll probably just copy it from here. (Which I guess is a roundabout way of saying "yeah, most likely".)

[JoshBashed]

I STRONGLY disagree to any ban, partial or otherwise. I think this direction is backwards and not helpful.

The problem being described isn't really LLMs: it's low-quality (slop) PRs that waste reviewer time. Slop PRs existed before LLMs, but I do agree that LLMs definitely resulted in more of them. Going back to the main point, I don't agree that banning LLMs is the right direction because the I think that LLMs, acknowledging their short comings, can increase productivity and contribute properly if guided correctly.

The maintainer of curl's thoughts (Daniel Stenberg) are worth reading. His main points are that: we would need to define what LLM code is, it would be hard to prove if someone is using an LLM for their contributions, people wouldn't know (resulting in people submitting PRs with LLM-generated code), and that "If we can't tell the difference, why do we need the ban again?"

The only "slop" PR i was able to find was #528.

I think the main issue is low quality PRs. This is a solvable problem.

• Tools like CodeRabbit (free for OSS) catch quality issues (no tests, broken builds, style violations, hallucinated APIs) and suggest fixes before a human maintainer does a review.

[MiaKoring]

To keep this issue up to date, here are some problems I have with LLM usage on code as previously stated on Discord:

These are not universal issues, but way more common with LLMs

• (healthy amount of) Pride of Ownership
  If you contribute something, you also are the first person that might be asked if there’s an issue with it or a question about it later. LLM usage tends to reduce that feeling and also how well people know the code they are contributing, even without it necessarily being bad
• PRs can be low effort without necessarily being bad. Reviews should take a reasonable amount of effort in relation to the implementation effort.
• Reviews not only ensure a certain minimum quality in the codebase, but are also an investment in the contributor. At least I do not want to effectively have conversation with an LLM, it being proxied through a human or not. Reviews should improve the quality of contributed code over time as well as the Developer. We all enjoy writing code more than reviewing it. In my opinion its not worth it for contributions with heavy LLM usage. Detection thing aside