I've been playing with the LLM code assistants, trying to stress them out with the Linux kernel code. So far, I've had success with them writing reasonable unit tests:
https://lore.kernel.org/lkml/20250717085156.work.363-kees@kernel.org/
https://lore.kernel.org/lkml/20250724030233.work.486-kees@kernel.org/
These both saved me some time since it emitted quite a lot of good boundary testing code, but I had to massage them both a bit until I was happy with the coverage. But it was a net win on time spent.

And then I walked it through fixing a buffer overflow. This one didn't save me any time because I had to tell it how to look at the problem. Since it was a shorter/simpler session, I included my exact prompts just for anyone interested in what I did:
https://lore.kernel.org/lkml/20250724080756.work.741-kees@kernel.org/

@kees This looks great and in the same time worrying that people without kernel coding skills (better: without C coding skills) will follow up and use it for their submissions. Happy maintainer times ahead!

@kees Nice. It would be good to have a standardised tag to state that it had been written with/by an AI, even better if there was a standard way to include the prompt in the stored commit message.

@kees When you say you had to help it, does this mean that you got it to fix its first attempt with some more follow-up prompts, or that you manually fixed up the remainder? Intuitively, I would expect that these fixups are similar to the trivial fix and just doing it yourself is faster after the initial LLM-generated code saved you most of the typing. Does this match what you saw?

(Also, as an aside, if a whole new file is AI-generated, why do you claim copyright for it?)

@caoimhin For the KUnit tests I did both. Some things it's faster to do.

E.g. "Please use different padding bytes in each subtest" it'll change them all instantly, and if I did it manually, I'd be going a line at a time and probably mess one up, so it saved like 10 minutes there maybe?

For adding more sanity checks or adjusting the bounds conditions or stuff like that I did directly because it's faster for me to add those than try to coax it out of the LLM: I know precisely what I want and the condition I want to test.

@caoimhin For the buffer overflow fix, I had already gone through the original reporter's analysis, examined the code, and understood what the fix was. I wanted to see how much hand-holding I'd need to do with the LLM from a basic "what's wrong here?" kind of prompt. It needed quite a bit of focusing, but the resulting commit log was more detailed than what I'd write (I tend to be too terse). I did no hand edits (beyond adding the commit tags for Reported/Closess/Fixes), and the prompts were few enough that I could include them in the email.

@caoimhin As far as copyright, it's a legit question, and given the current state of tooling, I'm comfortable that it's more of a strong autocomplete. I don't share copyright with grep, vim, nor Coccinelle. And I think Coccinelle is the closest to the LLMs in the sense that I have to understand my problem and write the best semantic patch syntax I can think of. For the LLM the syntax is the prompting, and I still have to iterate with the tool, do manual edits, etc.

I'm exploring the LLM workflow mainly to understand where it can meaningfully save me time. So far, on average, I'd say it's not a net positive, but it's surprisingly close. And they're still maturing, and I'm still learning how to use them best.

@kees How does the copyright work here? There's still open court cases about how copyright laws apply to LLMs and they are not resolved yet, nevermind how this applies to a GPL codebase.

@ada_magicat It's a reasonable question! My take on my use is here: https://hachyderm.io/@kees/114908907992238394

@krzk Oh, I can't imagine what disasters await anyone using these tools that isn't already a skilled developer. It can figure really basic stuff out but needs a ton of guidance and sanity checking still.

@kees @krzk Unfortunately, it won't stop some people from posting the disaster to the kernel MLs.

@penguin42 The non-deterministic nature of the LLMs makes "reproducible prompts" not practical currently, and my normal sessions usually involve much more than just the prompts, as I'm fixing its mistakes and otherwise changing state out from under it.

As for tags, I'm not sure. Maybe? But I'm not sure how useful that would be. What information would be wanted there, and for what use?

@kees Yeh I understand about the non-repeatability; although when you can capture a prompt it seems useful for others to learn from.
For the tags;; in the for-ai side it seems right to acknowledge a tool that's working well.
In the against-ai it lets people avoid ai-generated code, and in particular it might stop them copying code to a similarly-licensed project that doesn't allow AI generated content.
Either way, it feels a good way to get people to admit they're using it.

@ptesarik @krzk Yeah, it's a concern. My (perhaps naive) expectation is that our existing code review process will keep out bad code. It's not perfect, but neither are human-only submissions.

The problem I've seen in other projects seems to be more heavily landing on the bug report flooding side. "Luckily" Linux doesn't have a standardized bug reporting process. (And our patch submission process is ... awkward.)

@penguin42 Yeah, I'd agree there's benefit in being up front about AI assisted code generation. (And that's why I've been calling it out in these patches.) It does get weird when it's process assistance more than code generation. (e.g. having the LLM do the builds, tracking errors, etc.) It turns into a grey area really quickly. :)

No one wants me adding:
Assisted-by: Calendar, Kanban, vim

We don't have a tag for Coccinelle, syzkaller, or other bigger tools, but we do have an expectation of mentioning them in the commit log.

So, I guess my question is, do we need a *standardized* way to express this? And is it only for LLMs?

@kees @ptesarik @krzk You call it "awkward," I call it "a process with built-in proof of stake measures."

@kees @penguin42 Everyone knows that the trailer for "Assisted-by: vim" is a stray :wq at the bottom of the commit message.