Suggest disclosure via commit message:
0Assisted-by: GitHub Copilot
1Assisted-by: OpenAI GPT-5-Codex
This can be useful information for reviewers, especially when the PR is from a new contributor.
In my experience using Visual Studio Code in agent mode (e.g. on https://github.com/sjors/sv2-tp) it usually picks up and follows this instruction.
Of course anyone who wishes to hide the fact they’re using an LLM can simply modify the commit message.
Suggest disclosure via commit message.
Assisted-by: GitHub Copilot
Assisted-by: OpenAI GPT-5-Codex
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/33662.
See the guideline for information on the review process.
| Type | Reviewers |
|---|---|
| ACK | maflcko, kevkevinpal |
| Concept NACK | l0rinc, dergoegge |
| Concept ACK | m3dwards |
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.
Concept ACK
nit: The instruction could tell the LLM to add itself rather than the current literal instruction of adding the two hardcoded values. Perhaps they are clever enough to figure out what’s being asked.
I’m not sure I understand - why would we do anything like this? The LLM is just a tool, it would be weird to say: “suggestions by: clang-tidy” or “IDE used: CLion” or “Assisted-by: The C++ Programming Language: Special Edition”.
Maybe the problem is committing something here that’s “substantially generated with automated assistance” - in the same sense as we would discourage copy-pasting something here from StackOverflow without tailoring it to our needs.
So that’s a concept NACK from me.
’m not sure I understand - why would we do anything like this? The LLM is just a tool, it would be weird to say: “suggestions by: clang-tidy”
I think the goal is just to tag obvious obvious hallucinated “one-shot” vibe commits. Anyone using an llm as a tool, just as a way to implement what they understand and could implement fully themselves, can trivially remove the tag from the commit message. Though, it should be harmless to leave it in. Generally, we do mention when a change is motivated by clang-tidy, or refer to the cppreference website, or the C++ standard, so this additional information should not be harmful.
0@@ -0,0 +1,10 @@
1+# Guidance for Automated Agents
2+
3+## Commit attribution
4+
5+Include the following trailers on commits substantially generated with automated assistance:
@m3dwards wrote:
nit: The instruction could tell the LLM to add itself rather than the current literal instruction of adding the two hardcoded values. Perhaps they are clever enough to figure out what’s being asked.
I tried with Claude Sonnet 4.5 and it just dropped the second line.
lgtm ACK 08cf213ec7e671dd4162d4ae4d0d20810547a444
Seems harmless to add and could be useful information when it is present.
Why not simply create a label to flag them if their behavior is causing offense? What’s the purpose of disclosure, particularly if it’s an inadvertent one the user didn’t intend or consent to?
From my perspective, this suggestion seems to assume that LLMs would detect the agent’s file and automatically include commits or canaries derived from it, which risks unintentional disclosure.
Realistically, though, no one’s going to sift through a wall of LLM-generated “vibe” commits to check disclosure tags.
Would this introduce a reputational risk for the user? If so, would that be considered a positive or negative outcome? And in such a case, should the user be banned or otherwise disqualified?
Assisted-by: GitHub Copilot Assisted-by: OpenAI GPT-5-Codex
which risks unintentional disclosure.
Realistically, though, no one’s going to sift through a wall of LLM-generated “vibe” commits to check disclosure tags.
I’d say this is one of the use-cases to cover. If someone does not want to disclose their vibe-coding, but they fail to read their own submission of code (and the corresponding commit messages), the error is on their part. The requirement for pull request authors to understand their own changes is documented in essence in the pre-existing contributing guideline https://github.com/bitcoin/bitcoin?tab=contributing-ov-file#readme. Though, the contribution guidelines already exist today and are not changed by this pull request.
And in such a case, should the user be banned or otherwise disqualified?
My understanding is that LLM contributions, where the developer fully understands them, and could have fully authored them exactly the same way are not disqualified. However, when the author can not demonstrate understanding and the licensing questions are unclear (https://github.com/bitcoin/bitcoin?tab=contributing-ov-file#copyright), it is possible that a pull request is closed. Though, this is already happening today and this pull request does not change the policy around that.
However there should be some thought put into the subject of where the limit is with regards to other possibly-hostile prompt injection
I’d say using agents to amend the prompt is well-understood and well-docuemented. I think the change here is harmless and mildly useful. Though, if it doesn’t work in the future, it can be removed again and it is probably not worth to bend over backwards to achieve undocumented prompt injection.
5+Include the following trailers on commits substantially generated with automated assistance:
6+
7+```
8+Assisted-by: GitHub Copilot
9+Assisted-by: OpenAI GPT-5-Codex
10+```
I think that the reason why Claude Sonnet 4.5 dropped the second line can be fixed with something like this (backticks broke the GH suggestion so I changed to quotes)
0Include the following trailers on commits substantially generated with automated assistance adapting to whatever agent you are.
1
2For example for GitHub Copilot:
3
4> Assisted-by: GitHub Copilot
5
6For example for Claude Code:
7
8> Assisted-by: Claude Code
agents.md locally?
Two arguments against this change that I find worth pondering a bit about: @fanquake wrote:
Would conflict with anyone using a .gitignored
agents.mdlocally?
I haven’t checked if there’s an existing solution for that.
Update: there’s some discussion about that:
One other concern I have is that this is essentially a change that is meant to be subversive to a developer’s tools or development environment.
I could take that argument even further: let’s say an anonymous developer uses the LLM to slightly tweak their wording and coding style as a defence against stylometric analysis. They accidentally forget to remove the attribution. An adversary could then look at the commit timestamp and subpoena the LLM company for logs, possibly identifying them. @kanzure I don’t agree with this:
One of the norms ought to be minimizing the waste of time of the project’s contributors. Whether such a waste is achieved by LLM (or not) does not matter.
It does matter, because a reviewer may not realise at first glance what they’re dealing with and waste their time on serious review. Then only after some time goes by do they realise it’s nonsensical code. When you see that a new contributor used an LLM, you can have your guard up.
It’s true that after getting burned a few times as a reviewer, you’ll adapt and learn to recognise such code. But a little help in the form of attribution is useful. @maflcko wrote:
My understanding is that LLM contributions, where the developer fully understands them, and could have fully authored them exactly the same way are not disqualified.
I agree. Even when being initially guarded as a reviewer, the code may turn out to be perfectly fine.
If this is/becomes an established convention, I think it’s fine to have an agents.md. I’m interested to see what other ways this can help - my cursory reading suggests this can aid agents in understanding dos and donts of the repo, codebase organization, documentation hints, etc. But I’m not really interested in encouraging more contributions that are authored this way.
My current reaction is that this will “catch” very few people who don’t want to disclose. In my experience, you’d really need to be asleep at the wheel to miss something like this, but maybe I’m not vibing properly. I’d propose we auto-close stuff with this tag, otherwise I think it’s unlikely this will save us that much time, so concept -0.
…When you see that a new contributor used an LLM, you can have your guard up.
Wouldn’t it make sense to add those tags to all commits, regardless of whether assistance was used, to help encourage more thorough and attentive reviews? It seems important that reviewers stay thoughtful and cautious with all changes, no matter the level of assistance, the authors’s reputation, or their role in the project
ACK 08cf213
Doesn’t hurt to add and it could useful when we do see the Co-author as an llm
subpoena
Would be trivial to address by just using a more general tag like assisted-by-llm. I don’t think we care about the exact model and parameters, and on which cloud provider (or locally) it was run?
Concept NACK
While I agree that drive by LLM PRs are very annoying and this might make them easier to spot, Drahtbot is already fairly good at catching them through heuristics.
This would also be annoying for anyone using LLMs who has there own agents file.
Closing for now due to controversy. This should be a trivial and harmless change, but apparently it is not, so there is little value in lengthening the discussion further.
Please leave a comment if you want this to be re-opened.
Drahtbot is already fairly good at catching them through heuristics.
I only recently learned that we already auto-close many of these, so the ones that reviewers see are just a few leftovers.
Thanks for everyones feedback.