I asked a fellow package maintainer to disclose AI usage in a packaging commit message and pointed them to the AI-Assisted Contributions Policy.
They asked if they should put Assisted-by: generic LLM chatbot (literally) in there. My opinion is that they should not; they should be more specific and put e.g. Assisted-By: Claude Opus 4.6 in there.
I understood that example as a placeholder, not verbatim text that should be copy-pasted.
Could we maybe replace the example section in the AI policy with:
Assisted-By: Torment Nexus
Assisted-By: Claude Opus 4.6
Assisted-By: ChatGPT-5
Assisted-By: Gemini
Assisted-By: Cursor 2.0.38 with gpt-5
This was debated couple of times, but afaik we couldn’t decide on what is the best way here. I intentionally added both the generic and the specific example, trying to highlight that both variants should be allowed.
The main reasons to allow generic version is that
there is no real naming standard for the tools
it might be considered an advertisement
we don’t have a need(at least for now) to have the specifics
it might be sensitive information (theoretically), and if we are not using it for anything, why collect it?
I’m told the assisted-by commit message is actually showing up in the larger ecosystem in places as a bifurcation in common practices and guidance.
The linux kernel uses the assisted-by metadata in the commit messages with specifics.
Kubernetes explicitly disallows the assisted-by commit messages because of the product marketing concerns. They require you to provide the information in the PR description.
If we had a forge PR driven commit process for everything, we could adopt the Kubernetes approach, but I’m pretty sure we don’t, so we can’t.
I’m fine with the generic commit message tag as I think the generic tag serves our intended purposes with regard to transparency of AI use as part of contributor workflows. As a first order we just need to see the rate of adoption of this technology as a assistance tool.
Don’t get me wrong, I would LOVE to see assisted-by tags showing contributors were using local language models like gregkh does in the upstream kernel. Seeing use of gregkh_clanker_t1000 and its derivatives become widespread would be …fascinating for me personally. But that gets into product marketing territory pretty quickly..because I’m biased towards local language model use as a long term approach to using the technology. And my bias is a type of product marketing advocacy.
On that can we have a suggested generic that indicates local language model (the other LLM)?
I’d rather know where a contribution is coming from (i.e., which tools and/or models) and have a proper historical record, even if we have to accept commit message marketing. But I do really like this part of the Kubernetes policy:
When responding to review comments, you must do so without relying on AI tools. Reviewers want to engage directly with you, not with generated responses. If you do not engage directly with reviewers, the PR will be closed.
Is that something we’d want to wordsmith and adopt? We could soften the language a bit and also change it to reference package review requests in Fedora in addition to pull requests.
Human review deserves a human response. Just as human concerns described here deserve human responses.
What I think is a reasonable possible future is an opt-in AI review workflow that can be enabled for PR driven contribution workflows that take place before a human reviewer is tagged in at all. That is something people interested in Ai workloads can iterate on by enhancing that synthetic reviewer with skills and then agents can talk to agents in that workflow.
But once a human reviewer is requested and enters the discussion, the human contributor needs to respond human to human.
I think having that opt-in AI workflow helps set expectations for everyone. You want to do things agentically… opt-in to the AI reviewer before tagging in the human reviewer.
Exactly my thoughts. But if the policy was approved under the impression that we don’t want this, I won’t blame the example. I assumed the example is a placeholder.
I’m curious—why does the actual model/tool matter?
My impression of the AI usage policy was to flag that AI tools had been used to other contributors—all allow others looking at the work to be vigilant etc.
What information does the actual model/tool give us?
It seems that Anthropic (and likely others) forbid training a model on their output in their ToS (as discussed this morning on HN ), and so knowing which models is used to generate a patch/text might matter to some people in order to avoid breaching Anthropic ToS.
Or if a judge find there is liability for copyright infringement when using a model output and find that the model creator is liable and not the user. As far as I know, this is not the case in the US, but I also read that Section 230 that protect service providers might not be applicable to AI output, so it might not be far fetched to imagine copyright liability to fall on the provider side if anything change ).
Again, that’s just hypothetical reasons, but I think knowing what model version was used might matter in the future, hence why it is better to record that.
Yeh, the way I understood it—it’s the person using the model’s responsibility to ensure they follow the ToC etc., not ours (where they are contributing the outputs)?
Tbh: even though we (and lots of open source repositories on GitHub etc.) require people to declare AI usage, there’s no way to really verify this. There is also no way to verify that the model stated is really the model used. So, the onus for all this is on the person using the models already.
If the idea is to gather who is using what (it isn’t from my understanding, is it?), I don’t think this is going to be high quality data.
Officially, the reason given is the EU AI Act and its article 50 about transparency. Unofficially, I think Anthropic also want to avoid training models on their own output, since it result in models collapse, and maybe use that as a way to detect distillation.
And while the details of the watermark system are not public, there is enough literature on potential methods that make me think that they can embed enough information to get the model, the version and more (if you want more details, that’s the one I looked at, but there is a lot more published since 2023).
Given that Anthropic also announced that they would provide a way to detect the watermark, I think we should assume that anyone could get the information in a near future. So adding that as plain text or not would just change whether we can get the info with git grep or not.
And while code seems much harder to watermark with the existing methods, because there is more semantic constraints, I think it might be embeddable in the commit messages (the longer, the better).
I expect others big players to either follow or already do it (eg, Google with SynthID). As the watermarking is done by tweaking the inference engine, I expect people running local models to not be impacted. But I also expect local models to be a minority in the foreseeable future.
So if the goal is to reduce legal risks, dropping the metadata might not be sufficient.
those watermarks are likely not compatible with coding languages as they will likely be UTF-8 control sequences. I don’t expect the watermarks to survive in the context of contributed code. They likely survive in use cases like student essays.
Any… normative coding hygiene rules that would mandate ascii encoding likely strips the watermarks they are planning on doing to code text.
That being said… once we know how to detect the watermarks we have the option to detect watermarks and make decisions based on their existence.
For example we may want to say certain contexts… like this category in discussions… or the devel mailinglist… are for human discussion only.. and we can use the watermarks as a way to spot check that the likelihood that discussion is human generated. We might find the watermarks are a helpful tool for moderators in the explictly human discussion areas.
But the state of the art GenAI watermarking in 2026 does not use control sequences. The LLM operator divide the vocabulary in 2 random lists (green and red), and push the model to use more often tokens from the green one than the red one. Then you just have to check the output to see there is more token from the green list than expected (eg, if you select something at random, it should be close to 50/50). The article “A Watermark for Large Language Models” has all the gory and mathy details.
And while it seems impractical for code because you can’t really make 2 lists without risking having “If” in the green or red list and breaking the detection (because that’s based on stats, and code is more constrained), there is a few workarounds.
For example, “Marking Code Without Breaking It: Code Watermarking for Detecting LLM-Generated Code” was published 6 months ago. The article explain that they do the whole/green/red system on tokens (in the language parsing meaning one, not the LLM one) that have no or low impact on the code such as comments, temporary variable names, error messages, etc.
Another earlier (2024) paper on the same topic, “Who Wrote this Code? Watermarking for Code Generation”, present a method where the operator selectively apply watermarking only when there is enough entropy. My understanding is that if the model has to choose between a for loop or a while loop, or between if a > b or if b < a, this could be part of the red/green list.
I do not know what Anthropic is using, but if this was control sequences, it would have been found 1h after the announce by using vim and xxd. 5 minutes to search " :%!xxd ", and 55 minutes to exit vim, per usual.
variable names and error messages tend to have conventions in existing collaborative codebases. Anything that starts as AI probably won’t. I don’t think this sort of watermarking can survive anything that has established coding convention linting but we’ll see.
If there are detectable watermarks in code and Anthropic tells us how to detect them.. that would be very interesting to tie into commonly used language linters as a feature of the linters to warn about as something to clean up.