[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6887bf6b6de3f_1196810021@dwillia2-mobl4.notmuch>
Date: Mon, 28 Jul 2025 11:20:27 -0700
From: <dan.j.williams@...el.com>
To: Steven Rostedt <rostedt@...dmis.org>, <dan.j.williams@...el.com>
CC: Jakub Kicinski <kuba@...nel.org>, Sasha Levin <sashal@...nel.org>,
<workflows@...r.kernel.org>, <linux-doc@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <kees@...nel.org>,
<konstantin@...uxfoundation.org>, <corbet@....net>, <josh@...htriplett.org>
Subject: Re: [RFC 0/2] Add AI coding assistant configuration to Linux kernel
Steven Rostedt wrote:
> On Fri, 25 Jul 2025 13:34:32 -0700
> <dan.j.williams@...el.com> wrote:
>
> > > This touches on explainability of AI. Perhaps the metadata would be
> > > interesting for XAI research... not sure that's enough to be lugging
> > > those tags in git history.
> >
> > Agree. The "who to blame" is "Author:". They signed DCO they are
> > responsible for debugging what went wrong in any stage of the
> > development of a patch per usual. We have a long history of debugging
> > tool problems without tracking tool versions in git history.
>
> My point of the "who to blame" was not about the author of said code,
> but if two or more developers are using the same AI agent and then some
> patter of bugs appears that is only with that AI agent, then we know
> that the AI agent is likely the culprit and to look for code by other
> developers that used that same AI agent.
>
> It's a way to track down a bug in a tool that is creating code, not
> about moving blame from a developer to the agent itself.
Between fine tuning, the process of doing local training to emphasize /
de-emphasize some weights in the model, and prompt variability, the
signal from a patch trailer is diluted.
If maintainers care about commit text conciseness for humans and
traceability for AI, those competing concerns will conflict above the
"---" line in patches.
Powered by blists - more mailing lists