doc: add an AI contribution policy #35386

willcl-ark commented at 3:14 PM on May 26, 2026: member

This policy, adapted from ripgrep, https://github.com/BurntSushi/ripgrep/blob/f0cec341ab95c25c691ad3d5754d4bd9eedde21f/AI_POLICY.md who in turn adapted it from uv https://github.com/astral-sh/.github/blob/c5187e200db51bfe11d56e13053d29bd3793fdd8/AI_POLICY.md, works as a reasonable and pragmatic AI contribution policy at this point in time.

It codifies roughly how the project is currently operating, it's expectations when Ai is being used, and what we don't wish to see.

Link to the document directly from the new PR and issue helptext.

DrahtBot added the label Docs on May 26, 2026

DrahtBot commented at 3:15 PM on May 26, 2026: contributor

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/35386.

Reviews

See the guideline for information on the review process.

Type	Reviewers
ACK	stickies-v, Sjors, mzumsande, ekzyis
Concept NACK	kanzure
Concept ACK	achow101, l0rinc
Approach ACK	jonatack
Stale ACK	sedited

If your review is incorrectly listed, please copy-paste <code></code> into the comment that the bot should ignore.

Conflicts

Reviewers, this pull request conflicts with the following ones:

#35400 (doc: Remove good_first_issue.yml, Reword "Getting started" section by maflcko)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

willcl-ark commented at 3:17 PM on May 26, 2026: member

Naturally something like this will be a "living document" and may evolve with the current state of tooling, expectations and requirements of the project.

Looking for conceptual review on adding it at all at this point, but I think codifying how we work and what we expect is useful for new contributors.

Other approaches include:

have this live in top level ./AI_POLICY.md, or
have this live over in bitcoin-core/meta
have no codified policies

in doc/AI_POLICY.md:6 in c393b7b255

   0 | @@ -0,0 +1,45 @@
   1 | +# AI Policy
   2 | +
   3 | +Using AI (i.e., LLMs) as tools for coding is welcome. A high bar is held for
   4 | +all contributions to this project. Moreover, the project maintainers remain
   5 | +responsible for any code that is published as part of a release. Contributors
   6 | +are expected to be responsible for any code they publish.

sedited commented at 3:26 PM on May 26, 2026:

I think this should be dropped.

jonatack commented at 3:39 PM on May 26, 2026:

Agree

kanzure commented at 3:54 PM on May 26, 2026:

Contributors are expected to be responsible for any code they publish.

"responsible" is not really explained. What does responsible mean? It should be elaborated or dropped.

willcl-ark commented at 4:00 PM on May 26, 2026:

this is dropped now

in doc/AI_POLICY.md:11 in c393b7b255

   6 | +are expected to be responsible for any code they publish.
   7 | +
   8 | +**AI should not be used to generate comments when communicating with
   9 | +maintainers and other contributors**. Comments are expected to be written by
  10 | +humans. Comments that are believed to be written by AI may be hidden without
  11 | +notice.

sedited commented at 3:26 PM on May 26, 2026:

Could just say "may be moderated"?

willcl-ark commented at 3:59 PM on May 26, 2026:

done

sedited commented at 3:29 PM on May 26, 2026: contributor

Concept ACK

in doc/AI_POLICY.md:3 in c393b7b255

   0 | @@ -0,0 +1,45 @@
   1 | +# AI Policy
   2 | +
   3 | +Using AI (i.e., LLMs) as tools for coding is welcome. A high bar is held for

jonatack commented at 3:34 PM on May 26, 2026:

Perhaps separate the AI use sentence and the rest of this paragraph into two paragraphs, as they are somewhat separate ideas. Optional addition:

Using AI (i.e., LLMs) as tools for coding is welcome, provided that such use adheres to the following policy, adds value, and does not waste the community's time.

A high bar is held for

willcl-ark commented at 3:59 PM on May 26, 2026:

Thanks, seems resonable so I took it.

jonatack commented at 3:37 PM on May 26, 2026: member

Concept ACK. My initial thought is that it would be best to put it in this repo (not in meta) -- either in doc/ as you have done here, or top-level -- and link to it in CONTRIBUTING.md.

in doc/AI_POLICY.md:19 in c393b7b255 outdated

  14 | +own words.
  15 | +
  16 | +If you are opening a pull request, you are expected to be able to explain the
  17 | +proposed changes in your own words. This includes the pull request body and
  18 | +responses to questions. **Do not copy responses from the AI when replying to
  19 | +questions from maintainers and other contributors.**

stickies-v commented at 3:52 PM on May 26, 2026:

I think this should be expanded to require authors to have thoroughly reviewed and understand all proposed code changes, and to make sure the code is at least as good as they would have written it manually. They should not propose any code changes on domains for which they lack sufficient expertise, or keep it to the bare minimum and clearly document/disclose it.

willcl-ark commented at 8:49 AM on May 27, 2026:

Hmmm, this is sort of covered by the next paragraph:

This project requires a human in the loop who understands the work produced by AI.

stickies-v commented at 9:09 AM on May 27, 2026:

It is, but I think this is an important part of what makes AI-powered contributions valuable. I think it's useful to expand a bit so when someone who's genuinely interested in making useful contributions can better understand whether their contribution is meeting that bar.

willcl-ark commented at 9:25 AM on May 27, 2026:

How about:

If you are opening a pull request, you are expected to have thoroughly reviewed
and understand all proposed code changes, and be able to explain the changes in
your own words. This includes the pull request body and responses to questions.
**Do not copy responses from the AI when replying to questions from maintainers
and other contributors.**

stickies-v commented at 10:01 AM on May 27, 2026:

I would still prefer to expand more on the other items I mentioned, but there will be lots of opinions on this pull and I don't think we should spend too much time on it, so this is fine.

stickies-v commented at 3:54 PM on May 26, 2026: contributor

Approach ACK. Agreed to not make it too long, and update over time rather than add any edge case from the beginning.

willcl-ark force-pushed on May 26, 2026

DrahtBot added the label CI failed on May 26, 2026

kanzure commented at 4:04 PM on May 26, 2026: contributor

I am not opposed to writing and including something. I wonder about the efficacy, though.

Most importantly, do not waste the time of the project contributors.

Drive-by contributions by slopmaxxers will continue to happen regardless of what an extra document says.

At some point, it may be wise to consider the responsibility of minimizing spam to be the responsibility of the existing contributor set, rather than new anonymous contributors (who are unknown and unaccountable to each other because they are ephemeral) who may, or may not, read this document.

For example, measures to minimize spam could look like "requiring new users to receive nomination from at least n=1 existing contributors before submitting pull requests", and other variants.

I also submitted an idea for promoting individuals to donate LLM tokens instead of LLM outputs.

previously LLM guidelines were discussed here and here.

I wonder if we might also want to take any inspiration from here? https://github.com/ghostty-org/ghostty/pull/10412

I saw another project that simply disallowed contributions from non-contributors (HN 1, 2). So you'd have to actually work with the contributors before opening issues or pull requests. ghostty disallows issue creation by non-contributors. I don't know what the best strategy is to handle these issues (or do I?).

mzumsande commented at 4:19 PM on May 26, 2026: contributor

I would prefer it if the wording was more aggressive and stated clearly something like: Don't PR LLM-generated code unless you

know the language the code is written in
could have written the code yourself.
understand the existing surrounding code and the effect of the suggested changes.

sedited approved

sedited commented at 4:38 PM on May 26, 2026: contributor

ACK fcdd7facff7b58fdb2c3b88b405996cba02e02ce

DrahtBot requested review from jonatack on May 26, 2026

DrahtBot requested review from stickies-v on May 26, 2026

DrahtBot removed the label CI failed on May 26, 2026

achow101 commented at 6:22 PM on May 26, 2026: member

Concept ACK

in .github/PULL_REQUEST_TEMPLATE.md:6 in fcdd7facff outdated

   0 | @@ -1,12 +1,13 @@
   1 |  <!--
   2 |  *** Please remove the following help text before submitting: ***
   3 |  
   4 | -Pull requests without a rationale and clear improvement may be closed
   5 | -immediately.
   6 | +Pull requests may be closed immediately if they:
   7 | +- do not have a rationale and clear improvement
   8 | +- do not adhere to doc/AI_POLICY.md

maflcko commented at 6:35 PM on May 26, 2026:

meta nit: It would be good if there was a way to show this more prominently on GitHub, when creating a pull request. Otherwise, I don't think most LLM bots (or their operators) will even see this.

willcl-ark commented at 6:46 PM on May 26, 2026:

Yeah it's a bit of a shame that issues on GH get better treatment in this regard; I think you can only add text to the PR body as we have done here.

That is why I put this near the top, but I agree most autonomous LLM bots likely won't see it :( (I guess gh pr create or API has no such help text anywhere at all).

maflcko approved

maflcko commented at 6:37 PM on May 26, 2026: member

lgtm. Not sure how much this will help, but it seems harmless to be hopeful and try anyway

in doc/AI_POLICY.md:24 in fcdd7facff

  19 | +questions from maintainers and other contributors.**
  20 | +
  21 | +This project requires a human in the loop who understands the work produced by
  22 | +AI. **Autonomous agents are not allowed to be used for contributing to this
  23 | +project**. Pull requests that appear in violation of this will be closed,
  24 | +perhaps without notice.

ekzyis commented at 6:55 AM on May 27, 2026:

nit: "will be closed, perhaps without notice" -> "can be closed without notice"

(a bit more standard phrasing)

in doc/AI_POLICY.md:35 in fcdd7facff

  30 | +
  31 | +AI is useful when communicating as a non-native English speaker. If you are
  32 | +using AI to edit your comments for this purpose, please take the time to ensure
  33 | +it reflects your own voice and ideas. If using AI for translation, we recommend
  34 | +writing in your native language and including the AI translation in a quote
  35 | +block.

ekzyis commented at 6:59 AM on May 27, 2026:

nit: would recommend to put native language into a collapsible section

<details> <summary>like this</summary> to avoid unnecessarily long text that most probably can't read </details>

ekzyis commented at 7:16 AM on May 27, 2026: none

Concept ACK

We had a good experience at @stackernews with asking to disclose AI usage, so we don't need to guess, and it sets expectations for review. (If they didn't disclose it, and it turned out to be AI, this gives us another data point how to treat the contributor in the future.)

However, what counts as AI usage (that should be disclosed) is debatable, and I eventually got annoyed answering the question "Did you use AI? If so, how?" myself, so I'm not sure I'd actually recommend adding it here.

Drive-by contributions by slopmaxxers will continue to happen regardless of what an extra document says.

I think documents like these exist so we can point to them when taking action.

willcl-ark commented at 9:16 AM on May 27, 2026: member

I am not opposed to writing and including something. I wonder about the efficacy, though.

I think it's pretty well understonnd that this won't stop these contributions, but as noted below we can at least, when challenged, say that we have this policy in place and we judged this contribution fell foul of it.

Drive-by contributions by slopmaxxers will continue to happen regardless of what an extra document says.

Agreed. This is also why I personally feel that

I would prefer it if the wording was more aggressive and stated clearly something like: Don't PR LLM-generated code unless you

know the language the code is written in

could have written the code yourself.

understand the existing surrounding code and the effect of the suggested changes.

is not worthwhile, despite being perhaps what we ideally woudl want to see.

At some point, it may be wise to consider the responsibility of minimizing spam to be the responsibility of the existing contributor set, rather than new anonymous contributors (who are unknown and unaccountable to each other because they are ephemeral) who may, or may not, read this document.

For example, measures to minimize spam could look like "requiring new users to receive nomination from at least n=1 existing contributors before submitting pull requests", and other variants.

I have floated the idea of using somthing like vouch to do this in the past. I don't think we are at that stage here yet though, although volume is steadily increasing.

vouch requires a discussion (we have disabled) to be opened first, where you can ask to open an issue or PR. This frees up issues and PRs a bit from AI spam. If (any) contributor "vouches" for you then the bot will not auto-close your issue. IMO drahtbot is doing a fine job for us on this front now, and it's not necessary currently. We could do things like add vouching to delving/IRC too if we ever went down a similar path.

stickies-v commented at 9:25 AM on May 27, 2026: contributor

is not worthwhile, despite being perhaps what we ideally woudl want to see.

If the only purpose is to stop bots from spamming, then I agree. But if we assume that there continue to be genuine attempts of new contributors to enter the project, I think it remains useful to write documentation that is meant to be useful, not just a thing to point to when someone does something wrong.

willcl-ark commented at 9:31 AM on May 27, 2026: member

is not worthwhile, despite being perhaps what we ideally woudl want to see.

If the only purpose is to stop bots from spamming, then I agree. But if we assume that there continue to be genuine attempts of new contributors to enter the project, I think it remains useful to write documentation that is meant to be useful, not just a thing to point to when someone does something wrong.

as @kanzure said and I agreed with, I don't think an extra document will stop bots from spamming.

I think it remains useful to write documentation that is meant to be useful

The idea of this document is indeed to remain useful, and codify at a high-level how we are currently operating. I'd prefer not to be too prescriptive about it, perhaps #35386 (review) is enough?

willcl-ark marked this as ready for review on May 27, 2026

willcl-ark commented at 9:55 AM on May 27, 2026: member

Undrafting as there seems to be at least some interest in having something here.

stickies-v approved

stickies-v commented at 10:02 AM on May 27, 2026: contributor

ACK fcdd7facff7b58fdb2c3b88b405996cba02e02ce

DrahtBot requested review from ekzyis on May 27, 2026

DrahtBot requested review from achow101 on May 27, 2026

ekzyis commented at 10:57 AM on May 27, 2026: none

ACK fcdd7facff7b58fdb2c3b88b405996cba02e02ce

mzumsande commented at 11:02 AM on May 27, 2026: contributor

I think it's pretty well understonnd that this won't stop these contributions, but as noted below we can at least, when challenged, say that we have this policy in place and we judged this contribution fell foul of it.

Agreed. This is also why I personally feel that (...) is not worthwhile, despite being perhaps what we ideally woudl want to see.

I don't follow this reasoning. Yes, for drive-by spammers it doesn't matter at all what is in the policy, but why is that an argument for the current version and against a stricter one?

I do think it matters what the policy says for other reasons: There are probably lots of well-meaning bitcoiners who are not proficient in C++ or even programming in general, but are clever and may think that LLMs have made it possible for them to contribute to Bitcoin Core in a meaningful way, with PRs they could never have written by themselves in a pre-AI time.

They are also likely to actually read the policy to see whether they are welcome or not. After reading this policy, these people will read through their LLM output until they think they understand it, and open a PR in which they summarize it in their own words.

Whether we want to encourage these kind of contributions is in my opinion the critical question we have to answer as a project.

There are arguments in favor (maybe they get better over time; how else do we find new contributors) and against (they bind scarce reviewer resources and add little value; Bitcoin Core is a security-critical project and not a programming bootcamp).

In any case, I think that the resulting policy should actually reflect what we as a project think about these contributions. I think that the currently proposed policy invites them somewhat.

Sjors commented at 12:49 PM on May 27, 2026: member

Concept ACK

‎doc/AI_POLICY.md‎ at fcdd7facff7b58fdb2c3b88b405996cba02e02ce looks ok, but "Autonomous agents" is a bit ambiguous. I assume the problematic "autonomy" is about opening pull requests, responding to feedback, etc?

Damus also has a useful section: https://github.com/damus-io/damus/blob/master/docs/CONTRIBUTING.md#ai-assisted-contributions

AI-assisted submissions will be treated with the same standards and rigour as any other human-made submissions.

If this is merged, I suggest replacing the canned response with a link to it.

kanzure commented at 4:55 PM on May 27, 2026: contributor

NACK: adding written policy isn't a solution to the given problem. In general I am skeptical of policy documents for various reasons.

I have floated the idea of using something like vouch to do this in the past

Cool idea. It would be a good experiment that could always be turned off after a trial period.

willcl-ark force-pushed on May 27, 2026

in doc/AI_POLICY.md:33 in a2d5af269e

  28 | +It must be accompanied by human commentary explaining the relevance and implications of the context.
  29 | +Do not share long snippets.
  30 | +
  31 | +AI is useful when communicating as a non-native English speaker.
  32 | +If you are using AI to edit your comments for this purpose, please take the time to ensure it reflects your own voice and ideas.
  33 | +If using AI for translation, we recommend writing in your native language and including the AI translation in a quote block.

maflcko commented at 7:25 PM on May 27, 2026:

nit: I think this section can just be removed: I don't think anyone minds if a non-native English speaker makes a typo or grammar issue in a comment. Also, fully non-English speakers that create pull requests or issues here should be so rare that we can let them do whatever they want. (And if they do the wrong thing, just correct it if it happens, or add this section, if there is indication it will be needed, but IIRC there was never a commonly applicable use-case.

willcl-ark commented at 9:42 AM on May 28, 2026:

ok

willcl-ark commented at 7:25 PM on May 27, 2026: member

In any case, I think that the resulting policy should actually reflect what we as a project think about these contributions. I think that the currently proposed policy invites them somewhat.

OK @mzumsande you've persuaded me.

I pushed an updated a2d5af269e29e0533a2422629d445c6516574620 (along with formatting change, so diff looks bigger than it is, sorry).

maflcko approved

maflcko commented at 7:30 PM on May 27, 2026: member

Part of this may overlap with the recently added fa15a8d2d03b0099b97262e47a8cbf685c29dd49, so feel free to remove/compress this a bit, but just a nit.

DrahtBot added the label CI failed on May 27, 2026

Sjors commented at 9:04 AM on May 28, 2026: member

utACK a2d5af269e29e0533a2422629d445c6516574620

(I only looked at the policy text, not the .github integration)

I think this policy is useful for the same reason the code style guideliness are useful. It's about how we maintain high code quality in the project.

Although there's wording about moderation, which I agree with @kanzure can be used against the project by adversial actors, this seems secondary to me. Removing such wording might make the text confusing.

If your editor removes whitespace in unrelated areas of the code, reviewers will often call this out. Excessive churn caused by automated tools, make review more difficult and make it more difficult in the future to use git blame in debugging. This is anologous to LLM use, in that an automated tool, when used incorrectly, can increase review burden and lower code quality.

Some wording in the text does go beyond what I described above:

Comments that are believed to be written by AI may be moderated.

Autonomous agents are not allowed to be used for contributing to this project

I think they set useful expectations, but I don't feel strongly about keeping them.

I could even imagine a legit-ish use case for (limited) automated interaction, e.g. adding a thumbs-up emoji and "taken in commit ..." for every nit I implemented. This is not that different from using a script to generate boilerplate text after each push, see e.g. #19460 (comment). Still, a good default recommendation is to keep a human in the loop before posting anything, because if your bot goes off the rails and produces spam, it's still your responsibility.

DrahtBot requested review from stickies-v on May 28, 2026

DrahtBot requested review from sedited on May 28, 2026

DrahtBot requested review from ekzyis on May 28, 2026

doc: add an AI contribution policy

This policy, adapted from ripgrep, https://github.com/BurntSushi/ripgrep/blob/f0cec341ab95c25c691ad3d5754d4bd9eedde21f/AI_POLICY.md
who in turn adapted it from uv https://github.com/astral-sh/.github/blob/c5187e200db51bfe11d56e13053d29bd3793fdd8/AI_POLICY.md
works as a reasonable and pragmatic AI contribution policy at this point
in time.

It codifies roughly how the project is currently operating, and it's
expectations when Ai is being used, and what we don't wish to see.

Link to the document directly from the new PR and issues helptext.

8e88ccd0ef

willcl-ark force-pushed on May 28, 2026

stickies-v commented at 10:01 AM on May 28, 2026: contributor

re-ACK 8e88ccd0efef473f0ae4d634c9691b595963cc21

DrahtBot requested review from Sjors on May 28, 2026

DrahtBot removed the label CI failed on May 28, 2026

Sjors commented at 11:24 AM on May 28, 2026: member

re-ACK 8e88ccd0efef473f0ae4d634c9691b595963cc21

Since my last view: dropped comment about translation

ajtowns commented at 1:07 PM on May 28, 2026: contributor

Concept =0

Saying PRs should be high-quality, and thoroughly understood by the proposer (as opposed to their dev tools) and similar should stand the test of time and not need much modification IMO, but also doesn't really depend on whether AI was used.

Naturally something like this will be a "living document" and may evolve with the current state of tooling, expectations and requirements of the project.

AI tooling is changing rapidly; if this document is going to change equally rapidly, then it's probably a waste of time to have it -- more time will be lost by people trying to stay current with it than saved by it.

Is the intended audience for this document moderators (who might otherwise not feel authorised to moderate such contributions), contributors (who might figure out better ways to be helpful) or LLMs (who might perhaps trigger an alignment constraint and refuse to generate annoying PRs in the first place)? I'm a bit doubtful the latter two groups will get much value from it.

Autonomous agents are not allowed to be used for contributing to this project.

FWIW, I hope to violate that policy sooner or later (eg, "/goal figure out a way to reliably reproduce this potential issue and write a test case for it, and file a PR on my local git instance"). I think the meaning this is intending to get across is fundamentally a repeat of "AI should not be used to generate comments when communicating with maintainers and other contributors." Though I've also already violated that, too, IMO for the better (#34444).

willcl-ark commented at 1:42 PM on May 28, 2026: member

Some wording in the text does go beyond what I described above:
Comments that are believed to be written by AI may be moderated.

Autonomous agents are not allowed to be used for contributing to this project
I think they set useful expectations, but I don't feel strongly about keeping them.

Perhaps this could be clarified more.

The intent here as I see it is not to prohibit contributors from using agents in their own developement and testing workflow, that seems normal and likely to increase.

The line I think we want to draw is against agent-originated contributions; finding something to work on, working on it, and submitting it as a PR. i.e. no "human in the loop". Autonomous agents can find infinite amounts of "useful" work to submit in this way. So long as there is still a human who:

https://github.com/bitcoin/bitcoin/blob/8e88ccd0efef473f0ae4d634c9691b595963cc21/doc/AI_POLICY.md?plain=1#L15-L17

...then this may be acceptable.

A rephrasing could perhaps be more along the lines of "Pull requests should not be opened and driven by by autonomous agents. A human should choose the work, understand the change, and be responsible for the contribution"?

Is the intended audience for this document moderators (who might otherwise not feel authorised to moderate such contributions)

IMO this is the main driver here. We won't change the behaviour of LLMs/autonomous agents, or contributors, with a policy document.

mzumsande commented at 4:13 PM on May 28, 2026: contributor

ACK 8e88ccd0efef473f0ae4d634c9691b595963cc21

DrahtBot added the label Needs rebase on May 28, 2026

DrahtBot commented at 5:38 PM on May 28, 2026: contributor

🐙 This pull request conflicts with the target branch and needs rebase.

in doc/AI_POLICY.md:21 in 8e88ccd0ef

  16 | +- could have written the code yourself
  17 | +- understand the existing surrounding code and the effect of the suggested changes
  18 | +
  19 | +You must also be able to explain the pull request changes in your own words.
  20 | +This includes the pull request body and responses to questions.
  21 | +**Do not copy responses from the AI when replying to questions from maintainers and other contributors.**

jonatack commented at 7:36 PM on May 28, 2026:

nit, can simplify

**Do not copy responses from the AI when replying to questions from reviewers.**

l0rinc commented at 3:29 PM on May 30, 2026:

You're absolutely right!

in doc/AI_POLICY.md:23 in 8e88ccd0ef

  18 | +
  19 | +You must also be able to explain the pull request changes in your own words.
  20 | +This includes the pull request body and responses to questions.
  21 | +**Do not copy responses from the AI when replying to questions from maintainers and other contributors.**
  22 | +
  23 | +This project requires a human in the loop who understands the work produced by AI.

jonatack commented at 7:37 PM on May 28, 2026:

nit, clarify that the human referred to here is the author

This project requires a human author in the loop who understands the work produced by AI.

jonatack commented at 7:41 PM on May 28, 2026: member

Approach ACK. I'm sympathetic to the Concept ~0 comment as well, and presume this text is as much something for mods/admins to point to than anything else.

maflcko commented at 8:37 AM on May 29, 2026: member

I have floated the idea of using something like vouch to do this in the past

Cool idea. It would be a good experiment that could always be turned off after a trial period.

I wouldn't recommend doing anything fancy here with new rules and vocabulary. A trivial system could just check if a new pull request was opened by a new contributor. If yes, it will be auto-closed with the message "Thx, but new contributions will be manually re-opened on a case-by-case basis, to limit spam" (or so). A closed pull request can still be concept ack/nack'd by reviewers if they want, and can be re-opened at any time.

Note that issues are already fine, because DrahtBot correctly closes all the spam ones (ref: #35366 (comment))

Not sure how controversial that is, so I don't want to push this, but it would be trivial to implement with a one-line if check.

ekzyis commented at 6:44 PM on May 29, 2026: none

ACK 8e88ccd0efef473f0ae4d634c9691b595963cc21

DrahtBot requested review from jonatack on May 29, 2026

in doc/AI_POLICY.md:11 in 8e88ccd0ef

   6 | +
   7 | +**AI should not be used to generate comments when communicating with maintainers and other contributors**.
   8 | +Comments are expected to be written by humans.
   9 | +Comments that are believed to be written by AI may be moderated.
  10 | +
  11 | +If you are opening an issue, you should be able to describe the problem in your own words.

l0rinc commented at 3:28 PM on May 30, 2026:

I'd say the bar is higher: you should be able to recreate the change without AI assistance too, not just a general "describe the problem", but understand each line of the solution.

in doc/AI_POLICY.md:19 in 8e88ccd0ef

  14 | +
  15 | +- know the language the code is written in
  16 | +- could have written the code yourself
  17 | +- understand the existing surrounding code and the effect of the suggested changes
  18 | +
  19 | +You must also be able to explain the pull request changes in your own words.

l0rinc commented at 3:29 PM on May 30, 2026:

This was already stated above

in doc/AI_POLICY.md:29 in 8e88ccd0ef

  24 | +**Autonomous agents are not allowed to be used for contributing to this project**.
  25 | +Pull requests that appear in violation of this will be closed, perhaps without notice.
  26 | +
  27 | +If you wish to include context from an interaction with AI in your comments, it must be in a quote block (e.g., using `>`) and disclosed as such.
  28 | +It must be accompanied by human commentary explaining the relevance and implications of the context.
  29 | +Do not share long snippets.

l0rinc commented at 3:30 PM on May 30, 2026:

This line doesn't seem AI related. I often inlude very long patches, that's why we have:

<details><summary>Collapsible sections</summary>

very
very
very
very
very
very
very
very
very
very
very
very
very
very
very
very
very
very
log text

</details>

l0rinc approved

l0rinc commented at 3:31 PM on May 30, 2026: contributor

Concept ACK