On Wed, 01 Jul 2026 14:35:08 -0400 Jeff Layton wrote: > On Wed, 2026-07-01 at 17:54 +0200, Christian Brauner wrote: > > I remain very confused by our coding assistant contribution guidelines. > > I'm going to be a bit polemic now but this seriously in good faith. > > > > Why precisely do we require all this detailed information about what > > specific coding assistant was used? > > > > I find it very irritating that our git history has effectively started > > to function a bit like a free advertising platform for a bunch of AI > > companies and their proprietary agents and models.
FWIW, this is exactly how I feel. I added a regex to strip these in my git hooks. So at least the net/ history should be ads-free 🤷️ Inexperienced developers who just trust the LLM output, and therefore are the group where the tags would be most useful, tend not to add them. Either because they are ashamed or because they want full credit. This correlation kills the utility of the tag. > > And it reamins unclear to me what exactly we do get out of this detailed > > information: Do we want to run statistical analysis on what agent and > > model is used the most and publish that on LWN at some point? > > > > I acknowledge that my stance is even more radical: imho we would just > > stop it with any disclosure requirements completely. It's useless imho. > > We already see that other than core contributors most people don't care > > and will just not disclose their usage of AI. I think this is entirely > > pointless and worse it brings in undefined legal status as well. It's > > not like recent events of pulling certain models from the face of the > > earth have made this any less concerning. > > > > But fine, if we want to do this can we please just dumb it down to > > > > Assisted-by: LLM > > > > or > > > > Assisted-by: Coding Assistant > > > > or something else. That still gives the "careful review" signal to > > reviewers that want to pay special attention to LLM generated work while > > avoiding this slew of metadata. > > > > Signed-off-by: Christian Brauner (Amutable) <[email protected]> > > --- > > Documentation/process/coding-assistants.rst | 8 ++------ > > 1 file changed, 2 insertions(+), 6 deletions(-) > > > > diff --git a/Documentation/process/coding-assistants.rst > > b/Documentation/process/coding-assistants.rst > > index 899f4459c52d..fe34f3e7e828 100644 > > --- a/Documentation/process/coding-assistants.rst > > +++ b/Documentation/process/coding-assistants.rst > > @@ -43,12 +43,8 @@ When AI tools contribute to kernel development, proper > > attribution > > helps track the evolving role of AI in the development process. > > Contributions should include an Assisted-by tag in the following format:: > > > > - Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2] > > + Assisted-by: LLM [TOOL1] [TOOL2] > > > > -Where: > > - > > -* ``AGENT_NAME`` is the name of the AI tool or framework > > -* ``MODEL_VERSION`` is the specific model version used > > * ``[TOOL1] [TOOL2]`` are optional specialized analysis tools used > > (e.g., coccinelle, sparse, smatch, clang-tidy) > > > > @@ -56,4 +52,4 @@ Basic development tools (git, gcc, make, editors) should > > not be listed. > > > > Example:: > > > > - Assisted-by: Claude:claude-3-opus coccinelle sparse > > + Assisted-by: LLM coccinelle sparse > > > > --- > > base-commit: dc59e4fea9d83f03bad6bddf3fa2e52491777482 > > change-id: 20260701-work-coding-assistants-650ae1202ee0 > > > In general, collecting data for nebulous purposes usually turns out to > be a bad idea. If we're not 100% clear on why we want this data, then > we're probably better off not collecting it at all. > > With that in mind: if we're going to water down the tag, then I say > just remove the requirement altogether. If we later decide that we want > to start collecting more detailed info for some (clear) purpose then we > can revisit the idea. +1 Honestly even tool attribution feels increasingly moot. People vibe code tools and AI-in-the-loop pipelines which they never publish. Open source tools are (hopefully?) used in pre-commit pipelines, so they have the "kbuild bot problem" of problems getting fixed before the code is merged. And we have the same free advertising problem for the rest. It's 100 times more important to drill into people to provide sufficient information in plain English. How was the bug discovered, has it been triggered / proven and how, what is the user impact. I wonder if inventing tags distracts contributors from what really matters.
