Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
70 changes: 70 additions & 0 deletions content/wiki/llm_policy.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,70 @@
+++
title = "LLM contribution policy for Linebender projects"
+++

Open-source projects are facing an increasing amount of submissions generated in whole or in part by LLMs.

Maintainers tend to strongly dislike them: they require very little effort to create (since a machine is doing all the work) but a lot of effort to review (since LLMs make mistakes that are hard to track down). Because LLMs are good at mimicking high-effort contributors, maintainers often feel pressured to give the benefit of the doubt to the submitter and give a level of feedback that isn't warranted by the effort the submitter made.

Still, LLM agents can produce high-quality code, so we don't want to ban them altogether.

This document outlines Linebender's official policy for LLM contributions, inspired by [this zulip discussion](https://xi.zulipchat.com/#narrow/channel/419691-linebender/topic/AI.20slop.20policy/near/575407715).


## Disclosure

Contributors should disclose their LLM usage ahead of time. Reviewers will *not* be happy if a contributor only admits to using LLMs after being prodded, and will tend to assume the contributor is downplaying their level of AI use.

This above applies even if the reviewer double-checked everything the LLM wrote. In our experience, people overestimate their level of understanding of agent-produced code when the agent had a high level of initiative. "Code you wrote yourself" and "Code you read after the LLM wrote it" do not warrant the same level of scrutiny.

Contributors should also disclose content that wasn't written by an agent, but was a direct result of LLM outputs, notably:

- Code or documentation that was created following an outline, plan or architecture proposed by an LLM.
- Code that was copy-pasted by an AI chat tool (e.g. ChatGPT), even if the code was double-checked or adjusted.

This disclosure should be included in the PR description, so that it appears in the final commit message.

### Copilot-like tools

Tools like Github Copilot or Cursor Tab that do small tab-completion of code you're writing fall in a grey area.

Completing single lines of code or small blocks of boilerplate is fine and doesn't require disclosure.

Completing large blocks of code or entire functions, however, is similar to asking an agent to generate it for you. Writing a comment that says "The following does X" and then hitting tab a few times is almost identical to using an agent.

As a rule of thumb, in Rust, by the time Copilot produces completions with multiple `;` characters, you should treat it as LLM code that requires disclosure.

### Non-generation use of LLM

Using LLMs for debugging, exploration, testing (*not* generating test files) is accepted without disclosure.

### Anti-disclosure

Given the above, declaring that a PR *doesn't* include AI-generated content is redundant and unverifiable. Please don't include such messages unless asked.


## Level of effort

The rule of thumb for all LLM content is "You should not ask someone to read text if reading it would take longer than it took you to create it".

As such, we do not allow LLM bots, PRs that were generated end-to-end by LLMs, or AI-generated PR descriptions (translations are fine with disclosure).

If a PR includes AI-generated content, we fully expect the submitter to review their own PR before asking anyone else to look at it. They should spend as much effort on this self-review as they would on a human-authored PR.

In discussion spaces like Github comments and the Zulip server, please avoid posting AI-generated analyses, even if you vetted them.


## Documentation
Copy link
Copy Markdown
Contributor

@taj-p taj-p Apr 2, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To never use AI for documentation feels a bit strong and leaves no room for nuance.

Yes, I too absolutely abhor AI generated documentation where the author clearly hasn't reviewed it. But, I've also experienced AI-assisted contributions from authors who do properly review it where the output is actually quite good.


Not everyone has a strong command of the English language. Using AI helps bridge the "anxiety gap" between adding documentation and not. We don't want to marginalise this group of people. For example, I would prefer someone who struggles with English to ask AI to improve their grammar and spelling rather than to provide those comments directly in a PR.

Because generating it doesn't cost the contributor anything, they lean towards "more is better", which translates to a worse reading experience.

Phrasing like this is combative and a generalisation. AI consumers would read this as "I am too dumb to know that, sometimes, less is more when it comes to documentation".

I suggest toning it down to make it less judgemental and more impartial; perhaps something like: "We have experienced present day AI models producing low quality and verbose documentation. We expect documentation to uphold the same quality standards as our code. As such, review AI generated documentation with the same scrutiny as AI generated code."

If you're not confident in your documentation skills, writing stub documentation with TODO comments is better than verbose-but-meaningless LLM documentation.

This strategy isn't how we can best help well-meaning contributors grow. It's better for a contributor to have a back-and-forth with an AI to create, what they think is good documentation, and for maintainers to review it. IMO, this is better than requiring maintainers to write documentation after the fact (increasing maintainer burden).

I'm also a bit wary about such judgemental language like "verbose-but-meaningless" - I wouldn't be surprised if a large number of engineers do scrutinise over AI generated documentation as much as AI generated code.

I'm also unsure whether we want to encourage not writing documentation. Sure, leaving documentation to a later PR is fine. But, I kind of expect a work stream introducing non-trivial code to only conclude if documentation has been written.


My feeling is that documentation is no different to code. We have expectations on its quality. We expect you to review it as you would AI generated code. So instead of suggesting those with low confidence in doco write no documentation, it's better to have guidelines that we expect like:

  • Less is more
  • Examples over large blocks of text
  • Add ASCII visualisations for complex flows
  • ...

Perhaps we can add a disclaimer about documentation if we're so worried: If you've written too much documentation that appears AI written, maintainers can request changes without needing to read it.


In general, avoid generating *any* documentation longer than one line with AI. *Never* generate documentation longer than two paragraphs with AI.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I'd maybe relax this rule a bit, for example I have a habit of generating the first iteration of documentation with AI to have a basis to work from, but then trim it down or update it myself until I'm happy with it.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd rather not water down the language too much. The case you're describing is one where I'd at least expect disclosure.


AI-generated documentation tends to be very verbose and redundant. Because generating it doesn't cost the contributor anything, they lean towards "more is better", which translates to a worse reading experience.

If you're not confident in your documentation skills, writing stub documentation with TODO comments is better than verbose-but-meaningless LLM documentation.


## Agent files

We will not merge agentic markdown files.

Some projects may include common agent files in their `.gitignore`.
Loading