From 7c46f523c677ee2fd02dcf4f0fe3c10b0352a944 Mon Sep 17 00:00:00 2001 From: Olivier FAURE Date: Thu, 2 Apr 2026 17:44:00 +0200 Subject: [PATCH 1/6] Add LLM policy --- content/wiki/llm_policy.md | 68 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 68 insertions(+) create mode 100644 content/wiki/llm_policy.md diff --git a/content/wiki/llm_policy.md b/content/wiki/llm_policy.md new file mode 100644 index 00000000..afc3c5ec --- /dev/null +++ b/content/wiki/llm_policy.md @@ -0,0 +1,68 @@ +# 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 mimmicking 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 band 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 reviewer 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 + +In general, avoid generating *any* documentation longer than one line with AI. *Never* generate documentation longer than two paragraphs with AI. + +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`. From 59904948e4c793eb02a56b7f023a49af6080f476 Mon Sep 17 00:00:00 2001 From: Olivier FAURE Date: Thu, 2 Apr 2026 17:57:52 +0200 Subject: [PATCH 2/6] Fix frontmatter --- content/wiki/llm_policy.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/content/wiki/llm_policy.md b/content/wiki/llm_policy.md index afc3c5ec..d5bbb53f 100644 --- a/content/wiki/llm_policy.md +++ b/content/wiki/llm_policy.md @@ -1,4 +1,6 @@ -# LLM contribution policy for Linebender projects ++++ +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. From 85477012c28c8d4a1f1486423d514db53ab4a67b Mon Sep 17 00:00:00 2001 From: Olivier FAURE Date: Thu, 2 Apr 2026 18:01:37 +0200 Subject: [PATCH 3/6] Fix typos --- content/wiki/llm_policy.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/wiki/llm_policy.md b/content/wiki/llm_policy.md index d5bbb53f..b7c13114 100644 --- a/content/wiki/llm_policy.md +++ b/content/wiki/llm_policy.md @@ -4,16 +4,16 @@ 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 mimmicking 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. +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 band them altogether. +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 reviewer is downplaying their level of AI use. +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. From 22d4cde174cdf228283022f575b1669fcf2ac2f9 Mon Sep 17 00:00:00 2001 From: Olivier FAURE Date: Fri, 8 May 2026 13:07:19 +0200 Subject: [PATCH 4/6] Split paragraphs by sentence. --- content/wiki/llm_policy.md | 25 +++++++++++++++++-------- 1 file changed, 17 insertions(+), 8 deletions(-) diff --git a/content/wiki/llm_policy.md b/content/wiki/llm_policy.md index b7c13114..fd4353a2 100644 --- a/content/wiki/llm_policy.md +++ b/content/wiki/llm_policy.md @@ -4,7 +4,8 @@ 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. +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. @@ -13,9 +14,12 @@ This document outlines Linebender's official policy for LLM contributions, inspi ## 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. +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. +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: @@ -30,7 +34,8 @@ Tools like Github Copilot or Cursor Tab that do small tab-completion of code you 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. +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. @@ -40,7 +45,8 @@ Using LLMs for debugging, exploration, testing (*not* generating test files) is ### 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. +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 @@ -49,16 +55,19 @@ The rule of thumb for all LLM content is "You should not ask someone to read tex 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. +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 -In general, avoid generating *any* documentation longer than one line with AI. *Never* generate documentation longer than two paragraphs with AI. +In general, avoid generating *any* documentation longer than one line with AI. +*Never* generate documentation longer than two paragraphs with AI. -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. +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. From e599a874c8900f4083ba5bad0b5e5676df070baf Mon Sep 17 00:00:00 2001 From: Olivier FAURE Date: Fri, 8 May 2026 15:06:46 +0200 Subject: [PATCH 5/6] Remove section about doc, add section about translation --- content/wiki/llm_policy.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/content/wiki/llm_policy.md b/content/wiki/llm_policy.md index fd4353a2..64a53b38 100644 --- a/content/wiki/llm_policy.md +++ b/content/wiki/llm_policy.md @@ -41,7 +41,7 @@ As a rule of thumb, in Rust, by the time Copilot produces completions with multi ### Non-generation use of LLM -Using LLMs for debugging, exploration, testing (*not* generating test files) is accepted without disclosure. +Using LLMs for debugging, exploration, testing (*not* generating test files), spell-checking and grammar-checking is accepted without disclosure. ### Anti-disclosure @@ -61,15 +61,15 @@ They should spend as much effort on this self-review as they would on a human-au In discussion spaces like Github comments and the Zulip server, please avoid posting AI-generated analyses, even if you vetted them. -## Documentation +## LLMs and non-English speakers -In general, avoid generating *any* documentation longer than one line with AI. -*Never* generate documentation longer than two paragraphs with AI. +Most Linebender contributors don't speak English as their first language, and we understand that contributors might struggle with English and feel anxious about it. -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. +As mentioned above, using AI to check your grammar or find ways to reword a sentence is fine and doesn't require disclosure. -If you're not confident in your documentation skills, writing stub documentation with TODO comments is better than verbose-but-meaningless LLM documentation. +Using AI to translate something you wrote in your native language usually doesn't require disclosure. + +We consider these cases meaningfully different from asking AI to generate text for you from a prompt or having AI auto-generate doc for a code item, both of which require disclosure. ## Agent files From db3aaa0cb9f92244f9bc5b1318258507cc061a62 Mon Sep 17 00:00:00 2001 From: Olivier FAURE Date: Fri, 8 May 2026 15:07:23 +0200 Subject: [PATCH 6/6] Add section about documentation to LLM policy --- content/wiki/llm_policy.md | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/content/wiki/llm_policy.md b/content/wiki/llm_policy.md index 64a53b38..32e2a2dd 100644 --- a/content/wiki/llm_policy.md +++ b/content/wiki/llm_policy.md @@ -61,6 +61,30 @@ They should spend as much effort on this self-review as they would on a human-au In discussion spaces like Github comments and the Zulip server, please avoid posting AI-generated analyses, even if you vetted them. +## Documentation + +In general, avoid generating documentation with AI. + +Documentation is most valuable when it is intentional and concise. +Our users will read our documentation much more often than our code, which means that verbose documentation is much more damaging than verbose code. + +Because generating documentation doesn't cost the contributor anything, generated doc mechanically leans towards verbosity, which translates to a worse reading experience. + +For these reasons, Linebender projects hold documentation to a higher standard than code. + +Two rules of thumb: + +- Avoid generating documentation longer than one line with AI. +- Strongly avoid generating documentation longer than two paragraphs with AI. + +If a submitted change requires a large amount of documentation, and you are uncomfortable with your writing skills, we prefer that you reach out to us and ask for advice rather than submit large amounts of LLM-generated docs. + +In general, we value the process of communicating about documentation and expressing your intent more than we value the final artifact. +If you feel apprehensive about the quality of your docs, we'd encourage you to lean towards "ask us about it" rather than "use more AI". + +If you still want to generate large amounts of documentation and are satisfied with the output, refer to the above sections about disclosure and effort. + + ## LLMs and non-English speakers Most Linebender contributors don't speak English as their first language, and we understand that contributors might struggle with English and feel anxious about it.